My Jellyfin container sat on version 10.7 for the better part of a year on a QNAP TS-453D because I was scared of exactly one thing: clicking the wrong button and losing my library setup. That fear is common, and it is not irrational. Container Station makes updating look like a single friendly button, and sometimes it is, but the way it handles recreation can absolutely delete your settings if your volumes are not mapped the way you assumed.
So let me walk you through how this actually works, the safe path, and the traps that catch people.
Why containers do not update themselves
A Docker container is a running copy of an image, and images are frozen at a version. When the developer publishes a new build, your existing container keeps running the old code forever. Nothing on the QNAP nudges it forward.
That is a security problem more than a feature problem. An outdated Nextcloud or a two-year-old reverse proxy is a genuine door left open, and the fix is always the same shape: pull the newer image, then recreate the container from it.
The word recreate is where people get nervous, and rightly so.
Step 1: Find out what version you are actually on
Open Container Station, go to the Containers tab, and click your container. On the Overview panel you will see the image name and tag, something like lscr.io/linuxserver/jellyfin:latest.
Here is the catch that trips up half the people I help. A tag of latest does not mean you have the latest version. It means that when the image was first pulled, it grabbed whatever was current then. The tag is a label, not a live feed.
So a container tagged latest can be eighteen months stale. Do not trust the word.
Step 2: Back up your config folder
Before touching anything, copy the shared folder that holds your container config. In File Station, find the folder you mapped (people commonly use something like /Container/jellyfin/config) and duplicate it, or run a quick copy job to another share.
This takes two minutes and it is the single thing that turns a scary update into a boring one. If the recreate goes sideways, you point the new container back at the untouched original and you are exactly where you started.
Step 3: Pull the new image
Go to the Images tab in Container Station. Find your image in the list, and use the pull or update action (in newer builds it is a small download icon next to the image; in older QTS it lives under a Pull button up top where you re-enter the image name and tag).
Type the exact same name and tag you already have, for example linuxserver/jellyfin:latest, and pull. Container Station downloads the newer layers and updates what that tag points to locally.
You will now have two things: the running container (still old) and a freshly pulled image (new). They are not connected yet.
Step 4: Recreate the container from the new image
This is the actual update. In modern Container Station 3, click your container, open the menu, and choose Recreate. It rebuilds the container using the new image while reusing the same volume mappings, ports, and environment you already set.
On older Container Station 2 there is no clean recreate button, so you do it by hand: stop and delete the old container (this does not touch your mapped folders), then click Create and select the newly pulled image, carefully re-entering the same volume mappings and ports from your Step 2 notes.
Give it a minute. The container starts, the app reads its config from your mapped folder, and your library, users, and settings are all still there.
Where people lose data (and how to not be them)
Nearly every horror story I read on the forums comes down to one root cause: the config was never mapped to a shared folder in the first place. The person configured everything through the app, the data lived inside the container, and recreate wiped it.
You can check in seconds. Click your container, open the volume or storage section, and confirm the app's config path points to a real folder on your NAS.
| Volume mapping looks like | What happens on recreate |
|---|---|
| /Container/app/config → /config | Safe. Config lives on the NAS and survives. |
| Only an unnamed or anonymous volume | Risky. May be discarded, config can vanish. |
| No mapping for config at all | Data is inside the container. Recreate deletes it. |
If you find you are in the bottom row, do not update yet. Fix the mapping first by adding a proper folder path, then let the app rewrite its config there.
Pinning versions so updates stay predictable
I stopped using latest for anything important. Instead I pin a real version tag, like jellyfin:10.9.11, and I update on my own schedule by pulling the next specific tag.
The payoff is huge. You know exactly what you are running, you can read the release notes before jumping, and you never get surprised by a major version that changes how the config works. The official Docker documentation is worth a skim if you want to understand tags and image layers more deeply.
Pinning turns updating from a gamble into a decision.
A quick recovery checklist if an update breaks something
- Stop the new container. Do not delete it yet, the logs are useful.
- Read the container log in Container Station. Nine times out of ten the error names a missing setting or a database that needs a manual migration step.
- If the app will not start at all, recreate again but point the config volume to your Step 2 backup copy.
- Check the app developer's release notes for breaking changes. Major version jumps sometimes need a one-time schema upgrade.
- If all else fails, pull the specific older version tag you were on and recreate from that. This is exactly why pinning helps.
The first time I did a clean recreate on that TS-453D, the whole thing took four minutes and nothing broke. All the dread was about a risk that a two-minute folder copy completely removes.
Do this monthly and it becomes a non-event
Set yourself a reminder, maybe the first Saturday of the month, to pull and recreate your handful of containers. Once your volumes are mapped correctly, the routine is pull, recreate, glance at the log, done.
Outdated containers are one of the most common ways a home NAS ends up exposed, and QNAP has taken enough public heat over security that keeping your apps current genuinely matters. Ten minutes a month, and you are running current, patched code with your settings fully intact.
Frequently asked questions
Does recreating a container in Container Station delete my data?
Only data stored inside the container itself is deleted. Anything mapped to a QNAP shared folder (like a config or media volume) survives untouched. Before you update, confirm your app's config path points to a real folder on the NAS, not an anonymous volume.
Why does my container say latest but still run an old version?
The latest tag is just a label attached when the image was first pulled. It does not track new releases. To actually get the newest build you have to go to the Images tab and pull the tag again, which downloads the current version and updates what latest points to locally.
What is the difference between Pull and Recreate?
Pull downloads the newer image to your NAS but changes nothing about the running container. Recreate rebuilds the container from that new image while reusing your existing volumes, ports, and settings. You almost always do Pull first, then Recreate.
How do I update a container on older Container Station 2 without a Recreate button?
Pull the image again, then stop and delete the old container. Deleting the container does not touch your mapped folders. Finally, click Create, pick the newly pulled image, and re-enter the same volume mappings and ports you noted down beforehand.
How often should I update my QNAP containers?
A monthly pass is a reasonable rhythm for a home setup. Outdated containers are a common security exposure, so pick a fixed day, pull and recreate your handful of apps, and glance at the logs. Once volumes are mapped correctly it takes about ten minutes.
