mediumIntermediateSymptom-first#volumes#permissions#uid#mount

Bind mount permission denied — UID/GID mismatch

Permission denied when writing to a bind-mounted directory inside the container

Likely source:configurationsecurity

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Permission denied when writing to a bind-mounted directory inside the container
  • Container runs as root but mount directory owned by a different UID on host
  • chown or chmod errors on mounted volume paths

Docker bind mounts preserve host UID/GID exactly. Always match the container's non-root UID to the host directory, or use named volumes to let Docker manage ownership.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Mount ownership on host

    ls -ln /host/path/to/mount

  • Container user ID

    docker exec <CONTAINER> id

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • Host dir owned by UID 1000, container runs as UID 1001
  • touch inside container returns Permission denied

Confirm before fixing

ls -ln /host/path/to/mount && docker exec <CONTAINER> id
READ

Compare host dir UID with container UID

Fix

sudo chown -R $(docker exec <CONTAINER> id -u):$(docker exec <CONTAINER> id -g) /host/path/to/mount
CHANGE

Chown the host directory to match the container UID/GID

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
ls -ln /host/path/to/mount
READ

Check host directory ownership

2
docker exec <CONTAINER> id
READ

Check container user UID/GID

3
docker exec <CONTAINER> touch /mount/testfile 2>&1
READ

Confirm permission denied

4
sudo chown -R <UID>:<GID> /host/path/to/mount
CHANGE

Align host directory ownership with container user

Prevention

  • Create host directories with the same UID/GID the container process runs as.
  • Use named volumes (docker volume create) instead of bind mounts for write-heavy workloads.
  • Use the :z or :Z SELinux flags on bind mounts on SELinux hosts.
  • Avoid running containers as root — use USER directive with a known UID.

Related runbooks

Same stack, same failure family — worth a skim.

Bind mount appears empty — container sees no filesmedium

Container shows empty directory for a bind mount path

DockerFoundation3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.