My DS920+ once ate an entire Saturday morning over a Jellyfin container that refused to come up. It would flip to "running" for about two seconds, then drop back to "stopped" in Container Manager, over and over, like it was mocking me.
The fix took ninety seconds once I actually looked at the logs. Everything before that was me guessing.
That is the pattern with almost every dead container on a Synology NAS. The box already knows exactly what went wrong. It writes the reason to a log file and stamps an exit code on the container, and most people never open either one. So let us walk through the checks in the order I actually run them, from fastest to most annoying.
Read the exit code first
Before you touch a single setting, open Container Manager, go to the Container tab, and click your dead container. Look at the Details pane for the exit code. This one number narrows the problem down enormously.
A container that exits with code 0 stopped cleanly, which usually means the program finished and had nothing left to do. That is normal for a one-shot task and a bug for a long-running app.
Code 1 is a generic application error, code 137 means the process was killed (almost always out of memory or a manual stop), and code 139 is a segmentation fault inside the app itself. Code 126 or 127 points at a broken command or entrypoint, which usually means the image is wrong or the path inside it does not exist.
Open the container logs
The logs are where the real answer lives, and Synology makes them easy to reach. Click the container, open the Log tab, and read the last ten or fifteen lines from the bottom up.
You are hunting for the final message before the container died. Ninety percent of the time it is written in plain English.
The first time I hit the Jellyfin loop, the last log line said "Permission denied" on its config folder. That single line told me it was a file ownership problem, not a Docker problem at all. Common ones you will see include "bind: address already in use" (a port conflict), "no such file or directory" (a bad volume path), and "invalid environment variable" (a typo in your config).
If the log is completely empty, the container is dying before the app even prints anything, which points at the entrypoint, the image, or a mount that failed. Keep reading.
Fix the port conflict
Port conflicts are the single most common reason a container refuses to start on a NAS, because DSM itself is greedy with ports. If your log says "address already in use" or the container flaps immediately on start, this is almost certainly it.
DSM reserves a long list of ports for its own services. Port 5000 and 5001 are the DSM web interface. Port 80 and 443 are taken the moment you enable Web Station or a reverse proxy. Ports 6690, 5432 in some setups, and a scattering of others belong to Synology packages.
The fix is to change the host-side port, not the container-side one. In the container settings under Port Settings, the left number is the host port and the right number is the container port.
| App | Default port | Safe host port to try |
|---|---|---|
| Jellyfin | 8096 | 8096 (rarely conflicts) |
| A web app on 80 | 80 | 8080 or 8081 |
| Anything on 443 | 443 | 8443 |
| Portainer | 9000 | 9000 or 9443 |
Leave the container port on the right alone. Change only the host port on the left, apply, and start the container again.
Check folder permissions and volume paths
This is the one that got me, and it gets almost everyone eventually. Most Linux container images expect to run as a specific user, commonly the PUID and PGID pair 1026 and 100 on Synology, and if the folder you mounted does not allow that user to write, the app crashes on boot.
Go to File Station, find the shared folder you mapped into the container, right-click it, open Properties, and check Permissions. The container's user needs read and write access to the config and data folders.
A mistake I see constantly is mapping a volume to a path that does not exist yet. Docker will happily create an empty folder owned by root, and then the app inside cannot write to it. Create the folder first in File Station, then point the container at it.
While you are there, double-check the volume mapping itself. The host path on the left must be a real folder like /docker/jellyfin/config, and the mount path on the right must match what the app documentation expects, often /config. A swapped or misspelled path produces a container that starts and dies instantly.
Rule out memory and image problems
If the exit code was 137 and the log is short or empty, you are likely out of RAM. Open Resource Monitor in DSM and watch memory while you start the container. If it spikes to 100 percent and the container dies, either add a memory limit that is realistic, close other packages, or upgrade the RAM if your model supports it.
An 8 GB stick for a DS920+ runs around 40 to 60 dollars and solves a surprising number of "won't start" complaints in one shot.
Image trouble is the other suspect here. If you pulled an image for the wrong architecture, an ARM image on an Intel NAS or the reverse, the container can fail with an exec format error. Delete the image, confirm your NAS CPU type in Control Panel under Info Center, and pull the correct tag. The official Docker logs command reference is worth a bookmark if you end up on the command line.
When nothing in the GUI helps
Sometimes Container Manager gives you nothing useful and you need the raw output. SSH into the NAS, enabled under Control Panel, Terminal and SNMP, and run sudo docker logs your-container-name for the full history, or sudo docker inspect your-container-name to see every setting Docker actually applied.
The inspect output is verbose but honest. It shows the exact mounts, ports, and environment variables in effect, which often reveals the typo that the GUI was hiding from you.
If you recently updated DSM or Container Manager, a corrupted container definition can also cause silent failures. Deleting just the container (never the image or the config folder) and recreating it from the same settings clears a surprising amount of weirdness. Synology's own Container Manager documentation covers the recreate workflow step by step.
Your ninety-second checklist
When a container dies on you, work this order and you will find the cause fast almost every time.
- Read the exit code in the Details pane.
- Read the last lines of the Log tab.
- Check for a port conflict and change the host port if needed.
- Verify the mounted folders exist and are writable by the container user.
- Watch memory in Resource Monitor for code 137.
- Confirm the image matches your NAS architecture.
The container always leaves a trail. Once you get in the habit of reading the exit code and the log before you change anything, the restart loop stops being a mystery and becomes a two-line diagnosis. My Saturday mornings are a lot quieter now.
Frequently asked questions
Why does my Synology Docker container keep restarting every few seconds?
A container that flaps between running and stopped is crashing on startup and being restarted by its restart policy. Open the Log tab and read the last line before each restart; it usually names the problem, most often a port conflict or a permission error on a mounted folder. Fix the root cause rather than changing the restart policy.
What does exit code 137 mean on a Synology container?
Exit code 137 means the container process was killed, and on a NAS that almost always means it ran out of memory. Watch Resource Monitor while the container starts; if RAM hits 100 percent, close other packages, set a realistic memory limit, or add more RAM. It can also appear after a manual stop, but a repeating 137 on boot is nearly always memory.
Which ports does DSM already use that break my container?
DSM reserves 5000 and 5001 for its web interface, and 80 and 443 the moment you enable Web Station or a reverse proxy. Port 6690 and several package-specific ports are also taken. If your container wants any of these, change the host-side port in Port Settings to something free like 8080 or 8443.
The container log is completely empty, what now?
An empty log means the app died before it printed anything, which points at the entrypoint, the image, or a failed mount rather than the app itself. Check that your volume paths point to folders that actually exist, and confirm the image matches your NAS CPU architecture. SSH in and run sudo docker inspect on the container to see the exact settings Docker applied.
How do I find my Synology PUID and PGID for container permissions?
Most Synology setups use PUID 1026 and PGID 100 for the first admin-level user, but this varies. SSH into the NAS and run the id command as your user to see the exact numbers. Set those values in the container's environment variables and make sure the mapped folders grant that user read and write access in File Station.
