Map the three storage roles
A Jellyfin installation can read media from one location while its database and working files live elsewhere. The official guidance says to mount Samba/NFS media in the operating system and keep the Jellyfin database local rather than on network storage. Draw a path map for the installation you actually run: original media, server data and configuration, and temporary or generated output.
For each role, record the host location, the path the server sees, the running account and the intended read or write permission. A container's internal path is not automatically a host path. Use these records to explain the setup before changing permissions, moving a database or adding another share. This guide addresses storage you administer, not access to a third party's content catalogue.
Prove availability without using the library as a test bed
Choose a harmless owned sample and verify that the server's account can read its intended media location. Separately verify any directory that genuinely requires server writes. Giving every location broad write permission because one temporary directory failed makes the path map less useful and increases the amount of material that can be changed accidentally.
Record what happens after a planned restart: when the operating system makes the share available and when Jellyfin begins work. A familiar directory name may exist even when the expected filesystem is absent, so check the mounted storage itself. Do not make a library scan the first or only proof that a remote filesystem is ready.
Budget working storage for the actual job
Temporary transcoding and generated material can consume space independently of the original collection. Treat free space as a measured resource rather than assuming a small system disk is sufficient because the media lives on a large external drive. Record the configured location, available capacity and the cleanup behaviour documented for the installed version.
Use an acceptance exercise appropriate to normal use, such as one authorised video that your client actually needs transcoded. Observe storage consumption and release locally if you conduct that exercise, and label the result with the media, client and settings. No hardware or playback measurements were performed for this guide, so it supplies a method rather than a capacity or concurrency guarantee.
Keep recovery and path changes coordinated
Before moving storage, preserve the server data and the previous mapping. Change one role at a time where possible, then verify the sample, database availability and ordinary library navigation. An apparently empty library after a move can be a path or mount issue; avoid immediately cleaning it as if the original media had intentionally been removed.
Keep the completed path map with the server recovery notes. Include a clear owner for the share and a check for missing storage before scheduled maintenance. Revisit it after a container volume change, operating-system reinstall or new disk. The goal is a server whose storage dependencies can be diagnosed precisely, with original media and recovery copies retained through the transition.
Questions answered
Can I treat a container path as the location to back up on the host?
First identify the volume mapping. The same storage can have different host and container paths.
Why review temporary storage when my media drive has free space?
Temporary and generated output can use a different filesystem. Check the configured working location and its capacity separately.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.