Jellyfin Server Config Reset on Updates (TrueNAS Jellyfin App)

For context, I am running:

OS: TrueNAS Scale CE (v25.04.), with jellyfin installed via the trueNAS built-in app store (which uses the official jellyfin docker hub image, afaik)
Jellyfin TrueNAS App Version: v1.2.5
Jellyfin Server/Web/Build Version: v10.10.7
Jellyfin Client(s) Used: Mozilla Firefox Web Client, Android Phone Jellyfin App, Jellyfin for Mac App.

(The Jellyfin app is served to clients remotely behind nginx reverse proxy TrueNAS app, as well as accessed locally when at home)

Hiya! I’ve been a mostly very happy admin of a jellyfin server over the past few months :3.

However, quite a few times, updating jellyfin via the trueNAS app store has seemed to break my server, either by:

  1. resetting my config (unable to log in to old server name, upon reconnecting via unchanged URL, has a different server name/no users/no plugins etc.)

  2. breaking paths to media, rendering no media available (whilst config is preserved)

  3. … or both.

This was most recently the case when updating from the trueNAS TrueNAS App Version v1.1.24 → v1.2.5. As far as I know, the Jellyfin Server/Web/Build Version (v10.10.7) was unchanged in this update, indicating it may be a trueNAS app bundling/related issue.

Whilst problem (2.) is fairly easily fixed by re-linking the media paths in admin webUI, (1.) and (3.) cause me significant issues.

This is because whenever my config is reset, upon accessing the jellyfin webUI, my old server (& accompanying server name) is presented as an option to select. However, when selecting it to “connect” to it, it says it cannot be accessed at this time.

So, upon clicking “add new server”, & putting in the server’s (unchanged) IP/URL, one of two things happens:

  • I’m presented with the login page, where I can log in with my pre-existing admin account and I’m back in, but the server name is changed (to something like 8o3587g357hgg834h7) and settings (plugins, users, metadata etc.) reset.

  • I am prompted to re-set up the server using the wizard, as if a fresh install, before reaching the same end state as the previous scenario.

Previously, these problems had been fixed by either:

  1. Recursively re-assigning the owner & group permissions for Jellyfin’s /config and /data datasets on my TrueNAS to “apps” (which is the GUID & UID that the Jellyfin app uses), and restarting the server. (this was despite the owner/group perms of these datasets never changing from being listed as “apps” in both the TrueNAS GUI & on the OS’s CLI)

  2. Rolling back to a previous working snapshot of the Jellyfin config, and restarting the server.

However, upon the most recent update of the Jellyfin TrueNAS App (v1.1.24 → v1.2.5), neither of the above solutions have worked. The closest I’ve got was updating to v1.2.5, restoring to a known working /config snapshot (of the app when it was back on v1.1.24), and the server rebooting & being accessible… before breaking & having no content or config after 10min/another reboot.

Would anyone be able to help out with this? I’ve rolled back to the last known working version of the Jellyfin TrueNAS App, v1.1.24 (which uses Jellyfin Server/Web/Build Version: v10.10.7) for now, but I don’t want to go without patching this (as is public-facing) for too long.

Endless thanks, and let me know if I can provide any more info/specific logs to help diagnose this!

Just a quick question because you haven’t mentioned it explicitly:
Do you use hostpaths or iXVolume for the jellyfin config?
Because that sounds a lot like iXVolume…

1 Like

I have set the jellyfin app to use a hostpath for config (/mnt/rei/configs/jellyfin)… but it doesn’t contain any obvious config files like a master metadata file.

However… upon further digging into my folder structure on the underlying OS, despite selecting “host path” to store config in the GUI, Jellyfin (and all trueNAS-installed apps) also seem to have additional config files stored in /mnt/.ix-apps/app_configs… (these files are all owned by root, and don’t show up in the normal TrueNAS GUI).

(Relevant) folder tree structure:

!! the below devices/datasets/folders are accessed within the /mnt/ dir !!

/rei (main SSD)
 └── configs       // where I've set config files to be stored in the GUI
    └── jellyfin
        ├── config
        │   └── users
        ├── data
        │   ├── ScheduledTasks
        │   ├── keyframes
        │   ├── playlists
        │   └── subtitles
        ├── images
        │   └── resized-images
        ├── log
        ├── metadata
        │   ├── People
        │   ├── Studio
        │   └── library
        ├── omdb
        ├── plugins
        │   ├── Open Subtitles_20.0.0.0
        │   ├── Playback Reporting_16.0.0.0
        │   ├── TheTVDB_19.0.0.0
        │   └── configurations
        ├── root
        │   └── default
        ├── transcodes
        └── attachments

/.ix-apps
├── app_configs           
│   └── jellyfin      // where trueNAS stores other app config files, apparently...
│       └── versions
│           ├── 1.1.16
│           ├── 1.1.17
│           ├── 1.1.19
│           ├── 1.1.20
│           ├── 1.1.21
│           ├── 1.1.22
│           ├── 1.1.23
│           └── 1.1.24 (**current version**)
│               ├── README.md
│               ├── app.yaml
│               ├── ix_values.yaml
│               ├── migrations
│               ├── questions.yaml
│               ├── templates
│               └── user_config.yaml
└── truenas_catalog
    ├── ix-dev
    │   └── community
    │       └── jellyfin
    └── trains
        └── community
            └── jellyfin

/tank (main HDD)
 ├── data
     └── media      // where jellyfin accesses my media

This does make sense but may introduce another layer of complexity…
For example, here’s what’s in /mnt/.ix-apps/app_configs/jellyfin/versions/1.1.24/user_config.yaml (showing my current setup - as I rolled back to the last working TrueNAS App version 1.1.24 as mentioned previously. This file includes version numbers, last updated date, etc.):

ix_certificate_authorities: {}
ix_certificates: {}
ix_context:
  app_metadata:
    app_version: 10.10.7
    capabilities: []
    categories:
      - media
    changelog_url: https://github.com/jellyfin/jellyfin/releases
    date_added: '2024-07-30'
    description: Jellyfin is a Free Software Media System that puts you in control of managing and streaming your media.
    home: https://jellyfin.org/
    icon: https://media.sys.truenas.net/apps/jellyfin/icons/icon.svg
    keywords:
      - entertainment
      - movies
      - series
      - tv
      - media
      - streaming
    last_update: '2025-04-10 16:44:43'
    lib_version: 2.1.16
    maintainers:
      - email: dev@ixsystems.com
        name: truenas
        url: https://www.truenas.com/
    name: jellyfin
    run_as_context:
      - description: Jellyfin runs as any non-root user.
        gid: 568
        group_name: jellyfin
        uid: 568
        user_name: jellyfin
    screenshots:
      - https://media.sys.truenas.net/apps/jellyfin/screenshots/screenshot1.png
      - https://media.sys.truenas.net/apps/jellyfin/screenshots/screenshot2.png
    sources:
      - https://hub.docker.com/r/jellyfin/jellyfin
      - https://jellyfin.org/
    title: Jellyfin
    train: community
    version: 1.1.24
  app_name: jellyfin
  is_install: false
  is_rollback: false
  is_update: true
  is_upgrade: false
  operation: UPDATE
  scale_version: TrueNAS-25.04.1
  upgrade_metadata: {}
ix_volumes: {}
jellyfin:
  additional_envs: []
  publish_server_url: ''
labels: []
network:
  discovery_port:
    bind_mode: ''
  enable_https: false
  host_network: false
  web_port: 8096
release_name: jellyfin
resources:
  gpus:
    kfd_device_exists: false
    nvidia_gpu_selection: {}
    use_all_gpus: true
  limits:
    cpus: 5
    memory: 16036
run_as:
  group: 568
  user: 568
storage:
  additional_storage:
    - host_path_config:
        acl_enable: false
        path: /mnt/tank/data
      mount_path: /data
      read_only: false
      type: host_path
  cache:
    host_path_config:
      acl_enable: false
      path: /mnt/rei/configs/jellyfin
    type: host_path
  config:
    host_path_config:
      acl_enable: false
      path: /mnt/rei/configs/jellyfin
    type: host_path
  transcodes:
    host_path_config:
      acl_enable: false
      path: /mnt/rei/configs/jellyfin
    type: host_path

Notably, to answer your Q: the host path config is set at bottom of this .yaml file:

  config:
    host_path_config:
      acl_enable: false
      path: /mnt/rei/configs/jellyfin
    type: host_path

I hope this helps :)). This was set up using the fairly standard, recommended Jellyfin install process on TrueNAS (for details, see ServersAtHome’s latest video/guide - can’t include links here unfortunately!)

could you also post screenshots of the storage section of the config screen when you edit the jellyfin app?
I still suspect that either your hostpath mapping is wrong or your app is still using ixVolume for whatever reason.

Here you are :blush:

Jellyfin Config Paths:

Permissions:

so you’ve mapped the config, transcode and cache directory all to the same path?
I suspect that this is your problem. I’d try to create separate child datasets inside the jellyfin dataset for config, cache and transcode. If it’s possible i’d probably try to set the transcode to a ram disk.

Hmmm, okay - thank you for that. I could’ve sworn upon my first install i separated them out (have done so for Immich, etc.), but maybe not…

In terms of re-doing this whilst preserving my existing server config/settings/re-importing it if i do a fresh install with the updated version… any tips?

Do you know whether just creating new, separate datasets (owned by apps) within the /mnt/rei/configs/jellyfin dataset, and setting them as the corresponding host paths for jellyfin in the TrueNAS UI will move the existing install files nicely, or create duplicates? As there are already folders pre-populated (see image) with the various types of config files (transcodes, cache, and config) due to all being lumped into one dataset…

(side note: i see you can now select setting transcoding to tmpfs in there, so i’ll also do that… i swear this wasn’t an option when i last set it up, haha. 48GB of RAM should be good, right? :rofl:)

If it created the folder by itself then you should be good. My assumption was that, if all three directories are mappted to /jellyfin, that it may conflict with each other and overwrite/delete stuff.

Thanks, I’ll try that when I’m home!

If all goes wrong - is there a way to re-import server config (pre-existing users + creds, watchtime data for shows, iGPU passthrough + transcoding settings, etc.) over to a new jellyfin install? Thinking perhaps a fresh install may be on the cards since a lot has changed since I initially set it up in the early development stage. The only bits I really care about are those, I haven’t set much else up but have issued a bunch of user accounts. :slight_smile:

Tysm for all your help ~

I don’t know of any buildin backup solution, but jellyfin has an article on their website:

Thanks - I found that one too, and have read both that and the system paths one.

Here’s what my plan is (and how tonight went):

  1. Shut down Jellyfin v1.1.24 after taking a config backup (via scp of the entire /mnt/rei/configs/jellyfin (recursively, with permissions retained via the -rp flags.
  2. Created new, empty datasets (owned by apps) within the /mnt/rei/configs/jellyfin dataset:
    /mnt/rei/configs/jellyfin/jellycache
    /mnt/rei/configs/jellyfin/jellyconfig
  3. Left the previously auto-created “config” & “cache” folders that jelyfin was using before alone. Recursively re-applied apps as owner to all datasets & folders within /mnt/rei/configs/jellyfin via the TrueNAS GUI.
  4. Set the new config and cache Host Paths to the newly created datasets jellycache and jellyconfig. Changed transcode path to tmps (20000Mi). Restarted Jellyfin v1.1.24.
  5. Upon reloading, same situation. Was presented with all the following servers, and could not log in to any of them. Further, when clicking “Add Server” and re-entering the local IP, was presented with login screen (indicating it found it) but none of my pre-existing credentials worked.

  6. Tried updating to Jellyfin v1.2.5, and then restarting it. Same issue.
  7. Went in and looked at the new files populated within the new datasets jellycache and jellyconfig. Seemed to be all default files - so i don’t think any of my pre-existing config was moved/copied over when I changed the host paths in step 4 after all.
  8. Reverted back to last known working version & snapshot of jellyfin to maintain uptime, and re-set host-paths to the same, original /mnt/rei/configs/jellyfin dataset. Upon relaunching, everything loaded up again like normal.

My plan going forward is to (now I know the config and caches folders at least contain the server specific info & can be restored from) update to the latest jellyfin & attempt to copy over the contents of these into the new datasets jellycache and jellyconfig, and then delete the old config and cache folders. Then set jellyfin to use jellycache and jellyconfig as host paths once more. And if that works, then update to the new version.

& if not? Cry a little bit, probably. And then set it up again from scratch :rofl:

Sounds like a solid plan (especially the crying part :joy:)
Sorry i wasn’t a bigger help :cry:

I just checked mine today and It also went kaput and restarted the jellyfin.db, checked the db with sqlite and did not show any config. I think I lost it (Mega F). Next time will do snapshots before updating to have something to actually roll back.

Experiencing the same thing, the 1.2.5 package seems to reset the whole jellyfin dataset I have. Only solution I have is to restore snapshots.

What does you snapshot tasks looks like? I just set mine yestarday to avoid future losses. Retention of 7days and daily snapshots of each app configuration dataset. What is lost is lost T_T missing my old conf already

This kind of behavior is simply something you need to get used to if you’re going to use the community apps. It’s very common: the devs change some little thing, like changing some path, and it totally breaks your config. This is why I gave up on the community apps, installed Dockge, and then installed everything else using custom yaml files pointing to linuxserver.io builds.

@dwolsten - Honestly, that’s where I was heading too. Would you mind sharing your YAML files/any templates you’ve found for them? I’m sure I can craft my own, but may be useful for the thread and it’s completeness :))