So, after upgrading to 25.04, Jellyfin “broke” I can’t login to it or do anything. So I uninstalled it to re-install it. No joy. It won’t do that at all.
Where is this stored in SSH where I could manually remove it so that a re-install might function?
apps are stored in a hidden dataset on your apps pool called .ix-apps
In SSH where do I find this? I’ve looked under /mnt and most of the folders… is this just hunting? If I can just manually wipe out Jellyfin config files, I should be able to reinstall successfully
since its prefaced with a . the folder is hidden you can show it with ls -a if i remember correctly
What makes you believe this is the problem?
What, specifically (with exact error messages), happens when you try?
If something caused the jellyfin server to appear different to your browser it may fail to connect with the error message " Unable to connect to the selected server". For example, this can happen when you update from TrueNAS 24.04 to something higher due to the swap from Kubernetes to Docker changing how the container is identified in the app stack.
While it’s too late for you a good starting step would have been to clear the cookies & cached files in your browser for the site in question.
Yes, it really can help in this case. Maybe it will help someone else reading this.
So after upgrade from Electric Eel to Fangtooth (which has been flawless) my Jellyfin stopped logging in from TVs. Asking for a username/password, which for the life of me I can’t remember, I decided clean install and reconfigure. But trying to delete I get this:
[EBUSY] Failed to delete dataset: cannot destroy ‘Office/ix-applications/releases/jellyfin/volumes/ix_volumes/cache’: dataset is busy cannot destroy snapshot Office/ix-apps/app_mounts/jellyfin/cache@ix-applications-backup-system-update–2024-10-22_16:04:32: snapshot is cloned cannot destroy ‘Office/ix-applications/releases/jellyfin/volumes/ix_volumes/transcodes’: dataset is busy cannot destroy snapshot Office/ix-apps/app_mounts/jellyfin/transcodes@ix-applications-backup-system-update–2024-10-22_16:04:32: snapshot is cloned cannot destroy ‘Office/ix-applications/releases/jellyfin/volumes/ix_volumes/config’: dataset is busy cannot destroy snapshot Office/ix-apps/app_mounts/jellyfin/config@ix-applications-backup-system-update–2024-10-22_16:04:32: snapshot is cloned cannot unmount ‘/mnt/.ix-apps/app_mounts/jellyfin’: pool or dataset is busy
I don’t know how it’s busy it isn’t running on any PC or TV anywhere right now… therefore I was looking at wiping out the jellyfin folder and starting fresh that way.
First things first, the time stamp of that log entry is curious, is this a new log entry or one from 6 months ago?
Second, one thing that can prevent removal is if you are currently “in” that folder in a ssh or shell session. For example, if you cd’d to “/mnt/.ix-apps/app_mounts/jellyfin” to look at the contents.
The log is from today. I don’t know why it is putting in last October, that is strange… and adds to the problem. I’m not in the folder via SSH/etc.
I chose “force remove” when I deleted, and was able to “re-install” however, it seems to remember the old configuration (with password and information I don’t remember at all) so that doesn’t help me at all. Unless there is a way for me to edit a file that just changes the login username/password
That is not a time stamp for the log entry, that is the date of the snapshot, just FYI.
Office/ix-apps/app_mounts/jellyfin/cache@ix-applications-backup-system-update–2024-10-22_16:04:32
Oh, quite right, that was not a line break, it was a continuation of the previous line.
@Christopher_Reeves, or anyone viewing this, not sure if this will help, and I hope this is not the same solution for you. In the following links I had a very similar issue after a long chain of events, most of the issues caused by me.
After replicating a dataset to a new pool, then an OS upgrade, and promoting cloned snapshots I ultimately had to destroy the pool and rebuild but, I was able to save a lot of data with an SMB ZIP file of the dataset I wanted to save.
Replication would have been the best option but, my replication target had encryption when my source did not and threw a wrench in to the wheels.
Here are the links to the posts:
Again, not sure if any of this will assist but I hope it may as it is very similar to what I experienced. Hopefully you can get this resolved without a major rework.
