Self-Hosting

Docker on Synology (Container Manager)

Run containers on DSM without fighting it — the DSM 7.2+ Container Manager (and the 7.3 naming churn), the bind-mount permission failure that blocks most first runs, and the 80/443 conflict with DSM's own web services.

Problem summary

Running Docker on a Synology means Container Manager (the DSM 7.2+ successor to the old Docker package — and on DSM 7.3.x the package name churns back toward 'Docker', so check Package Center rather than assuming the menu). Operators trip on three predictable things: whether the model can run it at all (x86 Plus-series yes; some ARMv8 models per Synology's release notes; verify your exact unit), the bind-mount permission failure when the mapped share doesn't grant the container's UID/GID read/write, and port conflicts because DSM reserves 80/443 for its own web UI. Use the Project feature to run Compose stacks, keep data under a dedicated `/volume1/docker` share, and front web apps with DSM's reverse proxy instead of fighting for 80/443.

Operator snapshotEvidence first

First proof

Open Package Center and confirm what the container package is actually called.

Screen to open

ls -ln /volume1/docker/<app>

Expected signal

You see Container Manager (DSM 7.2) or the migrated Docker package (7.3.x).

Stop boundary

Don't force unsupported packages onto an incompatible NAS.

Layer path

1Container Manager is the DSM 7.2+ successor to the old Docker package; on DSM 7.3.x the package name churns back toward 'Docker', so check Package Center rather than trusting a remembered menu name. The engine underneath is standard Docker + Compose.

2Model support is by architecture: x86_64 Plus/value-and-up run it; Synology's release notes add specific ARMv8 models (e.g. DS420j, DS223). Older/low-end ARM units may not — verify the exact model.

3The #1 first-run failure is a bind-mount permission error: the mapped share doesn't grant the container's UID/GID read/write. The #2 is a port conflict because DSM reserves 80/443 for its own web services.

4Multi-container apps belong in a Project (Compose), managed as a unit, not wired container-by-container in the GUI.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Confirm package + model support

Check: Check Package Center and the model's Synology spec.

Expected result: Container Manager/Docker is installable and present.

If not: If unsupported, plan the workload on a mini-PC instead.

Create a dedicated docker share

Check: Make /volume1/docker with a sensible owner.

Expected result: App data has one consistent, owned home.

If not: Avoid scattering bind mounts across user shares.

Fix bind-mount permissions

Check: Align the container's PUID/PGID to a user with R/W on the share.

Expected result: The container starts and writes its data.

If not: If it errors, correct permissions in Settings → Volume Settings.

Avoid the 80/443 conflict

Check: Map web containers to high ports.

Expected result: No port conflict with DSM.

If not: Front them with DSM's reverse proxy for clean URLs.

Import as a Project

Check: Bring multi-container apps up via a compose Project.

Expected result: The stack manages up/down/logs as a unit.

If not: Validate with docker compose config if the import fails.

Back up the stack

Check: Back up the compose files, env, and the /volume1/docker data.

Expected result: The stack can be rebuilt elsewhere.

If not: Prove it on a scratch host before relying on it.

Decision tree

If: Container errors 'permission denied' on its data folder

Then: The mapped share doesn't grant the container's UID/GID access.

Action: Set permissions in Settings → Volume Settings; align PUID/PGID to a user with R/W.

If: Container can't bind 80/443

Then: DSM already owns those ports.

Action: Map to a high port and reverse-proxy it via DSM's Login Portal/Web Station.

If: Package isn't where the docs say

Then: DSM 7.3.x naming churn (Container Manager ↔ Docker).

Action: Check Package Center for the actual installed name; the workflow is unchanged.

If: Model can't install Container Manager

Then: Unsupported architecture.

Action: Confirm against Synology's release notes; consider a mini-PC for the container workload.

Safe stop: Don't force unsupported packages onto an incompatible NAS.

If: Multi-container app keeps breaking after edits

Then: Containers wired individually in the GUI.

Action: Re-import as a Project from a single compose file and manage up/down as a unit.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Container exits immediately or can't write config	Container log + ownership of /volume1/docker/<app>	Bind-mount permissions / UID-GID mismatch	Fix in Settings → Volume Settings; set PUID/PGID.
Web-app/proxy container won't start on 80/443	Port mapping vs DSM's reserved ports	Port conflict with DSM web services	Use a high port + DSM reverse proxy.
Docs reference a package you don't have	Package Center's installed package name	DSM 7.2 vs 7.3 naming	Use the installed package; ignore the label difference.
Package won't install at all	NAS model/architecture vs Synology's supported list	Unsupported model	Verify the model; move the workload to supported hardware if needed.
Stack drifts/breaks after manual container edits	Whether it's a Project or loose containers	No single source of truth	Convert to a compose Project.

Reference

Commands and settings paths

Check the data share's ownership/permissions

ls -ln /volume1/docker/<app>

Where: Synology SSH (enable SSH in Control Panel)

Expected: The owner UID/GID matches the container's PUID/PGID with R/W.

Failure means: Root-owned or wrong-UID folders cause 'permission denied' in the container.

Safe next step: Fix via Settings → Volume Settings or chown to the intended UID/GID.

See which service holds a port

sudo netstat -tlnp | grep -E ':80|:443'

Where: Synology SSH

Expected: DSM's own services are bound to 80/443.

Failure means: A conflict confirms why a container can't bind those ports.

Safe next step: Map the container to a high port and reverse-proxy it.

Validate a compose file before importing as a Project

docker compose -f compose.yaml config

Where: Synology SSH (or a workstation) in the project folder

Expected: The merged, resolved config prints with no errors.

Failure means: A parse error means the Project import will also fail.

Safe next step: Fix the YAML/paths, then import in Container Manager → Project.

Hardware boundary

Hardware and platform boundary

Change only when

Move container workloads to a mini-PC when the NAS model can't run Container Manager or you need real CPU headroom.
Adopt the Project/Compose workflow as soon as an app has more than one container.

Evidence that matters

An x86 Plus-series (or a Synology-listed ARMv8 model) on DSM 7.2+.
A dedicated docker share with correct UID/GID ownership.
DSM's reverse proxy in front of high-port web containers.

Evidence that does not matter

The exact package label (Container Manager vs Docker) — the engine is the same.
Freeing 80/443 from DSM — reverse-proxy instead.

Avoid

'Read/Write for Everyone' on sensitive shares to dodge a permission error.
Binding containers directly to 80/443.
Hand-wiring multi-container apps instead of using a Project.

Related tool

Use the linked tool to turn this runbook into a guided check for your exact setup.

NAS setup planner

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from 2026-06 research verified against Synology's Container Manager release notes and the container folder-permission KB, plus the Docker Compose specification. The operator differentiators are the DSM 7.2→7.3 package-name churn, the bind-mount UID/GID permission fix, and reverse-proxying around DSM's reserved 80/443 instead of fighting for them.

Sources/assumptions

Assumes a Synology NAS on DSM 7.2 or later running Container Manager (or, on DSM 7.3.x, the migrated 'Docker' package — the engine is standard Docker + Compose either way).
Model support is by architecture: x86_64 Plus/value-and-up run it; Synology's release notes cite specific ARMv8 models (e.g. DS420j, DS223) gaining support — stated as 'verify your model', not a fake compatibility matrix.
The permission fix path (Settings → Volume Settings on the mapped share) and the DSM 80/443 reservation are from Synology's own KB and DSM behavior; exact menu labels are version-dependent.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Synology: Container Manager release notesUsed for the DSM 7.2+ requirement, the Container Manager → Docker package naming, and the ARMv8 model additions (verify the exact model).Synology KB: Container can't access the folder or fileUsed for the bind-mount permission fix (Settings → Volume Settings) behind the most common Container Manager first-run failure.Docker docs: How Compose works (Compose Specification)Used for the preferred compose.yaml filename, the Compose v2 `docker compose` plugin, and Project/Compose fundamentals.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Confirm the layer (app, container, network) before deep config.
4. Prove the restore; don't assume it.

FAQ

My container can't write to its folder on the NAS — why?

This is the #1 Container Manager failure: the bind-mounted shared folder (e.g. `/volume1/docker/<app>`) doesn't grant the container's user read/write. Synology's KB fixes it in Settings → Volume Settings by correcting permissions on the mapped folder; practically, align the container's UID/GID (the PUID/PGID pattern many images use) to a DSM user that has R/W on a dedicated `docker` share. Don't reach for 'Read/Write for Everyone' on sensitive shares. See Synology's folder-permission KB.

My reverse-proxy/web-app container can't bind to port 80 or 443 — what now?

DSM reserves 80 and 443 for its own web UI / Web Station, so a container wanting those ports conflicts. The calm fix is to map the container to a high port and front it with DSM's built-in reverse proxy (Login Portal / Web Station), rather than trying to free 80/443 (which is invasive and can lock you out of DSM). If you'd rather run your own proxy, see home reverse proxy: nginx vs Caddy vs Traefik.

Should I run my app as separate containers or a Compose Project?

Use the Project feature for any multi-container app. Container Manager's Project imports a `compose.yaml`/`docker-compose.yml` and manages the whole stack (up/down, rebuild, logs) as a unit, which is far more maintainable than wiring containers individually in the GUI. Author the stack the same way you would anywhere — see a maintainable Docker Compose home stack.