Possible to keep auto logging in from clients after full server reinstall?

[raulo1985]

Weird, I finally gave up trying to find the specific files that would allow preserving auto log in after restoring them. Weird thing is that I just did a full backup and restore from both directories (/etc/jellyfin and /var/lib/jellyfin) and some of my clients do auto log in, but two of them don’t. One is JMP installed on a Windows 10 notebook, the other one is a LG Smart TV with the official app (not sure if this has something to do with the client itself, since a full backup/restore should make the clients believe they are logging in to the same server, regardless of the client. I may be wrong, though).

Things that I’ve noticed:

1) With full backup, all my iOS clients auto log in without issues.

2) Both the WebOS app and JMP don’t auto log in.

3) When there’s a new server with new ID, the clients trying to log in show a screen to select from the available servers (ergo, they don’t auto log in, as expected because of the new ID).

4) With full backup/restore (and double checked the permissions), the WebOS and JMP don’t auto log in, but they behave differently than trying to connect to a new server with new unique ID. If I restore only the database and the device.txt files, they get stuck at logging in. They don’t show available servers, in fact they both show part of the main GUI (not the libraries, just a couple of logos I added with css), so I guess by doing that the clients can go “further” in the logging in process (but get stuck for some reason. They keep loading forever, the only way to log in is to reinstall the client and connect to the server from scratch).

5) With the WebOS app and JMP, when doing a full back up and restore, they connect to the server, but they get to the log in page (with the correct users). If the client chooses a user and enters the password, it logs in without issues. That’s the closest I have gotten to auto log in with WebOS app and JMP after a full server reinstall (and with full Jellyfin backups). I don’t know if this is normal behavior, but I would have thought that, while preserving the ID and tokens, there would be no reason for them to not auto log in. And you say that all your clients do auto log in (I’m assuming that includes JMP and/or WebOS app), so I must be doing something wrong.

6) On a side note (maybe it’s helpful info), the other day I cleaned up the devices section and accidentally deleted the LG Smart TV. I thought that deleting that entry wouldn’t make a difference, and that the next time the TV tried to log in it would do so without problems. It wasn’t the case, and it behaved exactly the same as when I did a “partial” backup/restore (device.txt and database), it got stuck at loading forever and could only log in manually. Since the behavior was exactly the same as when trying to auto log in with JMP and WebOS app after a backup of just the device.txt and database files, I thought it would be worth mentioning it (since that I always thought that the devices section was made only for order reasons, but that it didn’t have an impact on functionality. But as soon as I deleted the LG TV entry, it couldn’t auto log in and kept on loading forever until I logged in manually).

So, bottom line is that the closest I’ve come with JMP/WebOS app to auto log in after full server reinstall is by doing a full backup and restore, but that gets me to the log in page. So I have to select the user and enter the password anyway. Better than before, but still not a real auto log in (and I don’t know why). What am I missing? Both clients obviously recognize the server since it shows the log in page (and lets you log in if the correct password is provided), but something is missing for them to remember the user and password to auto log in without intervention.

Any thoughts would be appreciated. Thanks again


————————————————————————

UPDATE: I went to basics and installed everything from scratch (both OS and JF, tried with latest stable and unstable with their corresponding repos), and restored a full backup (/etc/jellyfin and /var/lib/jellyfin).

Behavior:

- With iOS clients (I’ve tried only with iPhones), they auto login as if it was the same server. No issues there.

- WebOS: it goes to the login page, but it first shows you the page that you see when you first start a fresh JF installation. It’s a little misleading, because if you follow the process, you get to the point where you create the admin, and when you do it shows you an error message. You can’t get past that screen. What you have to do is go backwards, and then you get to the log in screen with the correct users available. No auto login, though.

- JMP: exactly the same as WebOS app, exact same behavior.

Sadly, I don’t use the iOS app too much, but WebOS and JMP are used by relatives on a daily basis. It’s not that difficult to get past it, you only have to go back, select your user, enter your password, and you log in. But I’m looking for a way for them not having to do anything if I upgrade from scratch, so they don’t even notice that something changed. Weird thing is is that with the iOS app, it works, it recognizes it as the same server and also auto logs in. Not so much with JMP and WebOS app though. I don’t know why, with a full backup/restore the clients shouldn’t even be able to notice it’s a new installation (at least that’s what I thought). I’m clearly missing something.

[raulo1985]

Deleted. Sorry, double post, my mistake.

[raulo1985]

The problem is that the Jellyfin server generates a unique ID.  When you reinstall from scratch it generates another unique ID and the clients don't like that.  You should be backing up /var/lib/jellyfin and /etc/jellyfin and restoring those directories and resetting the file permissions.  This will preserve the unique ID.

Here is what I did to backup and restore my Jellyfin completely.

Code:

mkdir -p /path/to/backup/drive/jellyfin
cd /path/to/backup/drive/jellyfin
mkdir jellyfinEtc jellyfinVar jellyfinCache
sudo rsync -a -p --progress /etc/jellyfin jellyfinEtc/
sudo rsync -a -p --progress /var/lib/jellyfin jellyfinVar/
sudo rsync -a -p --progress /var/cache/jellyfin jellyfinCache/

NOT putting a slash at the end of the SOURCE path is important.  Without the slash rsync will pull the entire directory, including hidden files and folders.  If you put a /* at the end of the source path it would not grab hidden folders and files.

To simulate a fresh OS install

Code:

sudo apt purge jellyfin*

To reinstall

Code:

curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash

To restore

Code:

sudo systemctl stop jellyfin
cd /etc
sudo rsync -a -p --progress /path/to/backup/drive/jellyfin/jellyfinEtc/jellyfin .
cd /var/lib
sudo rsync -a -p --progress /path/to/backup/drive/jellyfin/jellyfinVar/jellyfin .
cd /var/cache
sudo rsync -a -p --progress /path/to/backup/drive/jellyfin/jellyfinCache/jellyfin .
sudo chown -R jellyfin /var/lib/jellyfin /var/cache/jellyfin /etc/jellyfin
sudo systemctl start jellyfin

None of my clients had to re-login.

Hi. As mentioned in my previous post, I did the exact same things as you did, but at least with JMP and WebOS app (not touched, same settings and everything. Only the server was reinstalled from scratch) when I restored /etc/jellyfin and /var/lib/jellyfin the clients take me to the server page that’s shown when you first start it after a full reinstall. And you can get to the point where you create the admin account, but you can’t get past that because it shows an error message when you try. And obviously is not necessary to do so either, as users including admin were indeed restored.

If I’m on that page and go backwards, then I get to the screen with the correct users, and can log in after entering the corresponding password. But no auto log in. On the other hand, with the iOS official app it does auto log in, as if nothing had changed on the server side (which is what I want to accomplish with all the clients. Or at least with JMP and WebOS app, because those are the ones my relatives use on a daily basis).

The only thing I did differently than you is that I didn’t backup and restore the cache directory. Is it important for this purpose? I wouldn’t have thought that backing up and restoring that directory was important (in my mind, cache almost always can be deleted without issues). The other part of the process was done like you did (backing up and restoring the etc and var directories and setting up the permissions), but the behavior by doing so, in my case is, at best, getting to the log in page.

So far everything I’ve done gets me to the log in page, or sometimes it gets stuck (loading sign that lasts forever). Not even a full backup of etc and var JF directories manages to accomplish auto log in.

Do you have any ideas / suggestions? It appears that at least the server is being recognized: when you start from scratch without backing anything up, all the clients show you the available servers at the pointed IP address, now at least they recognize it’s the same server and shows you the existing users for logging in. So I believe the ID is preserved, and also the log in credentials (if I select a user and enter the password, it does log in). But somehow, even though with a full backup I thought the clients should see the new server as if it was the same as the last one (not even noticing it’s a new one), they still don’t auto log in (with JMP and WebOS. With iOS app, no issues, and I don’t have other devices to test with other clients).

Unless it has something to do with the cache directory (not backed up), I’m running out of ideas. I really don’t know why they don’t auto log in after a full etc and var JF directories restore (specially now, knowing that you took the same steps than I did and none of your clients asked you to manually log in after a fresh server install). If also restoring the cache directory doesn’t do the trick, then I officially don’t have a clue and don’t even know how to find out.

So any suggestion would be appreciated. Having to remote desktop and also phone my relatives to guide them for them to log in again with their clients is a lot more complex than what it should be (guiding my dad by phone to log in again with his LG Smart TV is painfully complicated. And the same goes to my mother with her Windows 10 notebook with JMP. Tech is really not their thing), so being free from those steps would be really nice for my setup and use case (and also would allow me to reinstall the server from scratch whenever I want, without my relatives having to do anything or even noticing that the server was reinstalled). It should be possible (in fact it is, as it worked for you), but clearly I’m missing something. If it’s not the cache directory, any idea of what I could try next?

[Efficient_Good_5784]

Any reason you're not at least preserving the old Jellyfin config folder?
Do you need to clear out your Jellyfin settings when you clear everything off of your computer?

I'm using containers for my Jellyfin server, and when I update Jellyfin, all I have to do is download the new image and link it a copy of the old config folder.
After that, the container starts and all my clients work as before with no re-logging in needed.

Also, the cache folder shouldn't matter here for your issue.

[raulo1985]

Any reason you're not at least preserving the old Jellyfin config folder?
Do you need to clear out your Jellyfin settings when you clear everything off of your computer?

I'm using containers for my Jellyfin server, and when I update Jellyfin, all I have to do is download the new image and link it a copy of the old config folder.
After that, the container starts and all my clients work as before with no re-logging in needed.

Also, the cache folder shouldn't matter here for your issue.

Thanks for your reply. Sorry, but what do you mean by preserving the old Jellyfin config folder? You mean the one that was in the .config folder? I understand that Jellyfin doesn’t use it anymore (and I don’t see it either), and that all the config files are now located in the etc and var folders. So I thought that backing up and restoring those two folders, there weren’t other folders that need restoring.

At first I just wanted to preserve the server ID and tokens with the hopes of the clients logging in automatically, but starting with all the server settings at their defaults. When I do a clean install, I’ve always liked to setup everything from its defaults, including creating the libraries, users, etc. That’s why I first tried restoring only the device.txt and database files (ID and tokens), but it didn’t work. So I gave up on the idea of setting everything up from its defaults and just do a full restore (so the clients don’t have to log in manually), but to my surprise the behavior is the one I mentioned before: it gets to the log in page, passwords and users are preserved, but they don’t auto log in (except the iOS official app).

So, in my book and to my knowledge, by backing up the etc and var folders, I’m indeed doing a full backup. Or is there another folder I’m missing that I should backup and restore?

[Efficient_Good_5784]

Thanks for your reply. Sorry, but what do you mean by preserving the old Jellyfin config folder? You mean the one that was in the .config folder? I understand that Jellyfin doesn’t use it anymore (and I don’t see it either), and that all the config files are now located in the etc and var folders. So I thought that backing up and restoring those two folders, there weren’t other folders that need restoring.

It's a bit different when you're dealing with containers. Jellyfin will create a config folder and use that for all configuration.

In your case, you should preserve both /var/lib/jellyfin & /etc/jellyfin.

You should have your server restored by backing up those two directories and adding them back on the new install.

[raulo1985]

Thanks for your reply. Sorry, but what do you mean by preserving the old Jellyfin config folder? You mean the one that was in the .config folder? I understand that Jellyfin doesn’t use it anymore (and I don’t see it either), and that all the config files are now located in the etc and var folders. So I thought that backing up and restoring those two folders, there weren’t other folders that need restoring.

It's a bit different when you're dealing with containers. Jellyfin will create a config folder and use that for all configuration.

In your case, you should preserve both /var/lib/jellyfin & /etc/jellyfin.

You should have your server restored by backing up those two directories and adding them back on the new install.

Thanks again. The thing is, that’s exactly what I did when I gave up on the idea of just preserving the ID and tokens. I backed up and restore those two folders (and set permissions correctly), but for some reason web based clients (like JMP) still see the reinstalled server as a different one apparently (although they do get to the log in page so I guess they recognize the server, but no auto log in).

Like I said, after restoring those two folders, the clients get to the log in page, users are correct and passwords too, and all the info and settings are preserved, but they just don't auto log in. If a full restore of those two folders didn’t work for auto log in after a fresh server install, I’m officially running out of ideas.