Every week someone deletes a misbehaving container on their NAS and deletes six months of app data with it — data they believed was on the NAS. It was: inside a temporary layer that Docker throws away. This guide explains where container data actually lives, and the one mapping habit that makes it live in a real folder instead.
A container is built to be disposable. You are supposed to be able to delete it and recreate it in minutes — that is the whole point of the design. But an app's data — its database, its settings, your uploads — must never be disposable. Docker solves this with volumes: instructions that say when the app writes to this path inside the container, actually write to that real folder on the NAS. On a Synology, that real folder should be a subfolder of a shared folder — usually the one everyone names docker. Get this right once and every container you run becomes safe to delete, update and recreate.
When an app inside a container saves a file, one of two things happens. If nobody told it otherwise, the file lands in the container's own writable layer — a private scratch space that exists only while that container exists. Delete the container, during an update or a cleanup, and the layer is deleted with it. No recycle bin, no recovery.
If the app's data path is mapped, the same save lands in a real folder on your volume — visible in File Station, included in backups, untouched when the container is deleted. Recreating the container with the same mapping brings the app back exactly as it was, because from the app's point of view nothing was ever lost.
In Container Manager you set mappings when creating a container, under its volume settings. Each line pairs two paths.
/volume1/docker/jellyfin/config./config. This comes from the app's own documentation — it is not a guess, and every serious image publishes it.A typical compose-style mapping for a media app, showing the pattern:
/volume1/docker/jellyfin/config : /config and /volume1/media : /media — settings in the docker folder, media read from the media share.
One shared folder, one subfolder per app, boring forever:
docker/portainer, docker/jellyfin, docker/downloads — app name, nothing clever.This layout pays off on the worst day: when a container must be rebuilt from nothing, its whole world is one known folder.
The most common reason a freshly mapped container refuses to start is not the mapping — it is who the app runs as. Many images run as a specific user ID and group ID (often set through PUID and PGID settings in the app's instructions), and if that identity cannot write to your folder, the app crashes, sometimes silently.
Already running an app that stores data inside its container? It can usually be rescued: stop the container, use File Station or the app's own export feature to copy its data out to a proper folder, then recreate the container with the mapping in place and confirm the app sees its old data. Do it calmly, one app at a time, and keep the old container stopped — not deleted — until the new one proves itself. The deletion test from the first-container guide is your acceptance check.
The full Docker on Synology NAS installation, shown live on a real NAS from package install to a running container.
▶️ Watch Full VideoIf the data was stored inside the container's own layer and no volume was mapped, deleting the container deleted the data with it, and there is no recycle bin for it. Your only routes back are a backup of the NAS or the app's own cloud copy if it had one. This is exactly why data must be mapped to a shared folder from the first run.
A mapping points the container at a real folder you choose on the NAS — visible in File Station and easy to back up. A named volume is storage Docker manages in its own hidden area; it survives container deletion too, but you cannot see or copy the files with normal NAS tools. On a Synology, folder mappings are the clearer, safer habit.
They can, and sometimes should — a downloads app and a media app often share a media folder by design. But two apps writing to the same settings or database folder is asking for corruption. Share data folders deliberately, keep each app's own config folder private to that app.