Synology Docker: Container Manager, Ports, and the Permissions Trap

Docker on a Synology NAS runs through Container Manager, the DSM 7.2 replacement for the old Docker package, and it only works on x86 models — ARM units like the DS223j cannot run it at all.

That hardware constraint is the first thing to check, because no amount of configuration fixes it. After that, the two things that consume everyone’s first evening are DSM’s reserved ports and the permissions on shared folders, both of which fail in ways that do not name the actual problem.

Table of contents

• Check the model first
• Set up the folders before the first container
• The port conflicts nobody warns you about
• The permissions trap
• Compose through the Project interface
• What a NAS is and is not good at
• How this fits the rest of the stack
• FAQ

Check the model first

Container Manager requires an Intel or AMD processor. Synology’s ARM-based models — the DS223j, DS124, DS223, and the rest of the value line — do not appear in Package Center with it, and there is no workaround.

Find your CPU in Control Panel → Info Center. Anything reading Intel Celeron, Pentium, Core, AMD Ryzen, or AMD Embedded will work. Anything reading Realtek or Marvell will not.

Memory matters more than people expect. The 2GB that ships in entry-level x86 units is enough for two or three light containers alongside DSM itself, and not enough for a database plus an application plus DSM’s own indexing. Most of these models take a RAM upgrade, and it is the single best thing you can do for a NAS you intend to run containers on.

Install Container Manager from Package Center. On DSM 7.2 and later it replaces the package formerly called Docker; on DSM 7.0 and 7.1 the old Docker package is what you get, and the concepts below are unchanged.

Set up the folders before the first container

Do this first and the rest goes smoothly. Container Manager creates a shared folder called docker on install. Give each container its own subdirectory under it.

/volume1/docker/
  paperless/
    data/
    media/
  postgres/
    data/
  compose/
    paperless.yml

Two reasons this matters. Containers that write into their own writable layer lose everything when the image is updated — the same trap as any Docker host. And a flat layout where several containers share one directory turns into a mess the first time you want to back up or move just one of them.

Exclude the docker shared folder from the DSM indexing service. Universal Search indexing a database’s data directory produces constant disk activity and no useful search results.

The port conflicts nobody warns you about

DSM occupies a long list of ports on the host, and mapping a container onto one of them fails with a generic bind error that does not mention DSM.

• 5000 / 5001 — DSM’s own web interface. This is the one everyone hits, because 5000 is also the default for a lot of self-hosted software.
• 80 / 443 — Web Station and reverse proxy, if either is enabled.
• 22 — SSH, when enabled.
• 139 / 445 — SMB file sharing.
• 111 / 2049 — NFS.
• 3260 — iSCSI.
• 6690 — Synology Drive.

Check before mapping rather than after failing:

sudo netstat -tulpn | grep :8080

The practical convention: map container ports into the 8000-9000 range on the host and leave DSM’s defaults alone. Changing DSM’s own ports to free up 5000 is possible and is a good way to lock yourself out of the management interface.

    ports:
      - "8081:80"      # host 8081 -> container 80

The permissions trap

This is the one that produces the most confusing failures. A container starts, immediately exits, and the log says permission denied on a path that plainly exists and is plainly writable in File Station.

The cause: the process inside the container runs as some numeric UID — often 1000, sometimes 999 for database images — and Synology’s shared folders are owned by DSM users with entirely different UIDs. The container’s user has no rights to the mounted directory.

Find the UID and GID of your DSM user over SSH:

id yourusername
# uid=1026(yourusername) gid=100(users) groups=100(users),101(administrators)

Then tell the container to run as that user:

services:
  app:
    image: some/image
    user: "1026:100"
    volumes:
      - /volume1/docker/app/data:/data

Many images support PUID and PGID environment variables instead, which is cleaner because the container’s entrypoint fixes ownership at startup:

    environment:
      - PUID=1026
      - PGID=100
      - TZ=Europe/London

Set the ownership on the host to match and the problem disappears for good:

sudo chown -R 1026:100 /volume1/docker/app

Resist chmod -R 777. It makes the error go away and leaves a directory that every process on the NAS can write to, which on a device holding your backups is a poor trade.

Compose through the Project interface

Container Manager’s Project feature is a Compose front end, and it is much better than clicking through the container creation wizard for anything with more than one service.

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      PGDATA: /var/lib/postgresql/data/pgdata
    volumes:
      - /volume1/docker/paperless/db:/var/lib/postgresql/data
    restart: unless-stopped

  app:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    depends_on:
      - db
    ports:
      - "8010:8000"
    environment:
      PAPERLESS_DBHOST: db
      PAPERLESS_SECRET_KEY: ${SECRET_KEY}
    volumes:
      - /volume1/docker/paperless/data:/usr/src/paperless/data
      - /volume1/docker/paperless/media:/usr/src/paperless/media
    restart: unless-stopped

Services on the same project reach each other by service name — the app connects to db, not to the NAS IP address. Only the ports you actually need from outside get mapped to the host.

Keep secrets in a .env file next to the compose file rather than inline. Container Manager reads it, and it keeps credentials out of the YAML you might paste into a forum post when asking for help.

restart: unless-stopped is what brings containers back after a DSM update reboots the NAS. Without it, an overnight update leaves everything down until you notice.

What a NAS is and is not good at

A Synology running containers is genuinely good for things that serve your own network: media, document management, home automation, backup targets, internal tools. The hardware is already on, the storage is already redundant, and nothing is billed monthly.

It is a poor fit for anything the public internet needs to reach reliably. A home connection has an asymmetric uplink and an IP address that changes. Consumer hardware has one power supply and no failover. Exposing DSM or a container to the internet through port forwarding puts a device holding all your files directly in the path of automated scanning, and Synology units have been targeted by ransomware campaigns for exactly that reason.

The split that works: internal services on the NAS, public services on infrastructure built to be public. When something you host at home starts having real users, moving it to RunxBuild gets it a route, TLS, deploy logs, and a runtime that does not share a power supply with your family photos — while the NAS keeps doing what it is good at.

How this fits the rest of the stack

A NAS trades a monthly bill for hardware you maintain and an uplink you do not control. When a project needs to be genuinely reachable, the RunxBuild hosting calculator shows what the runtime, database, storage, and bandwidth add up to, so the comparison is against a real number rather than a guess.

Useful related references:

• Installation of Docker in Ubuntu: Step-by-Step for 22.04 and 24.04
• How to Install Docker on Ubuntu: 2026 Guide (22.04 and 24.04)
• Docker List Running Containers: Past docker ps
• Docker services on RunxBuild

FAQ

Which Synology models can run Docker?

Only x86 models with Intel or AMD processors. ARM-based units such as the DS223j, DS124, and DS223 cannot run Container Manager and it will not appear in Package Center. Check the CPU in Control Panel then Info Center — Realtek or Marvell means no.

Why does my container fail to start with a port binding error?

DSM reserves a long list of host ports, including 5000 and 5001 for its own web interface, 80 and 443 for Web Station, 445 for SMB, and 2049 for NFS. Map containers into the 8000 to 9000 range instead, and check with netstat before mapping rather than after the failure.

Why do I get permission denied on a Synology Docker volume?

The process inside the container runs as a numeric UID that does not match the DSM user owning the shared folder. Find your UID with id yourusername over SSH, then set user: uid:gid in Compose or supply PUID and PGID environment variables, and chown the host directory to match.

Should I use chmod 777 to fix Synology Docker permissions?

No. It removes the error and leaves a directory writable by every process on a device that holds your backups. Set correct ownership with chown to the UID and GID the container runs as instead — it is the same amount of work and it is not a standing risk.

How do I run Docker Compose on a Synology NAS?

Use the Project feature in Container Manager, which is a Compose front end. Paste the YAML, keep secrets in a .env file beside it, and set restart: unless-stopped so containers come back after DSM updates reboot the NAS.