Adding a Docker container that survives updates
written after Jellyfin lost everything, Sep 2026
If losing it would annoy you, bind-mount it. An anonymous volume is what you
get by default when nothing overrides the image — and it's the one mount type that
silently evaporates when a container is recreated.
Layout — definition and data together, one dir per service
/volume1/docker/<service>/
├── docker-compose.yml # the definition
├── .env # secrets only, chmod 600
├── config/ # bind-mounted
└── data/ # bind-mounted
Template
services:
myapp:
image: vendor/myapp:latest
container_name: myapp
restart: always
volumes:
- /volume1/docker/myapp/config:/config # anything stateful
- /volume1/docker/myapp/data:/data
- /volume1/media:/media:ro # read-only where possible
environment:
- TZ=Europe/Zurich
- APP_PASSWORD=${APP_PASSWORD} # from .env, never inline
Traps worth knowing
- Don't mix Container Manager and CLI compose on the same container. DSM keeps its own definition and silently reasserts it — a
compose up can look like it worked while only restarting the old container. Pick one owner.
- If a container already exists in Container Manager, delete it there first, then
docker rm it too — CM releases its record but leaves the container behind, and compose then fails on the name conflict.
- Never
docker compose down -v — the -v deletes volumes. The other common way to lose everything.
- Secrets belong in
.env at chmod 600, never inline in the compose file, and never reused across services.
Updating
cd /volume1/docker/<service>
sudo docker compose pull && sudo docker compose up -d
Verifying — don't trust, check
A matching server/instance ID is not proof. Once config has been copied into a
bind mount, both locations hold the same ID — so it tells you nothing. Check for
new writes instead.
# 1. is it actually a bind mount?
sudo docker inspect <name> --format '{{json .Mounts}}' | grep -o '"Destination":"/config"[^}]*'
# want "Type":"bind"
# 2. does the bind-mounted dir receive fresh writes after a restart?
ls -la /volume1/docker/<service>/config/log/
# 3. the real test — recreate, then confirm nothing reset
sudo docker compose pull && sudo docker compose up -d