Why does my Docker container throw 'Permission denied' even though it works on my Mac?

Docker Desktop on macOS quietly remaps UIDs on bind mounts, so a host folder appears already owned by the container user. On a native Linux host no such remapping happens, so the same docker-compose.yml hits Permission denied the first time it runs in staging or production. Fix ownership explicitly with chown in an entrypoint rather than relying on the Mac behaviour.

Should I use chmod 777 to fix a Docker permission error?

No. chmod 777 grants read, write, and execute to every user and makes the permission model meaningless. Use chown -R appuser:appuser on the specific folders instead, so the application user owns the directories it is responsible for.

How do I find out which user my Docker container runs as?

Run docker compose exec web id . It prints the UID and GID the process actually runs as, usually uid=1000(appuser) . Linux enforces permissions on that numeric UID, not on the name.

How do I make the Docker permission fix permanent?

Bake ownership into the image with COPY --chown=appuser:appuser and a RUN chown before the USER appuser line, then fix mounted-volume ownership at startup in an entrypoint that runs as root and drops to appuser with gosu . Set ownership first, drop privileges last.

Why does a named volume keep the wrong owner after I fixed my Dockerfile?

A named volume only initialises its ownership from the image the first time it is created. Rebuilding the image does not reset an existing volume. Remove and recreate the volume (for example docker compose down -v ) so it re-initialises with the corrected ownership.

Docker Permissions Without Panic: Why I Ran chown Inside My Container

26 Jun 2026 (updated: 14 Sep 2026) / 36 minutes to read

Elena Daehnhardt

Fixing Docker “Permission denied” for a Non-Root Container User

A Docker permission error is an ownership mismatch: a folder created by root (at image build or container startup) is being written to by an application that runs as a non-root user such as appuser, so Linux refuses the write. The fix is to change folder ownership with chown, not to loosen permissions with chmod 777.

Sometimes Docker does not fail loudly.

It does not say:

Hello Elena, your container is fine, but your app cannot write to the folder because the owner is wrong.

No. Docker prefers mystery.

You run the app. Everything looks healthy. The container is up. Nginx is serving. Flask is alive. Then suddenly uploads fail, backups do not appear, static files refuse to update, or Python throws one of those wonderfully unhelpful messages:

Permission denied

In my case, the fix was this command:

docker compose exec -u root web chown -R appuser:appuser /backups /app/protected_files /app/app/static

At first glance, it looks like a scary Linux spell.

But it is actually a very practical Docker permissions repair.

Let’s unpack it.

The Proper Fix: Own It at Build, Repair Volumes at Runtime

🔒 Subscribe to keep reading.

You've hit a Deep Dive tutorial.

I spend dozens of hours researching, coding, and breaking things to write these guides. This content is free, but reserved for my subscriber community. Drop your email below to unlock this guide (and all past/future deep dives):

Already a subscriber? Use the magic link from your last newsletter, or reset your password.

New subscribers get an inbox mail: Set a password to unlock articles. The form does not log you in — use the same email afterwards.

Docker Permissions Without Panic: Why I Ran chown Inside My Container

📚 This post is part of the "MLOps & Deployment" series

Fixing Docker “Permission denied” for a Non-Root Container User

The Proper Fix: Own It at Build, Repair Volumes at Runtime

References

Citation

Docker Permissions Without Panic: Why I Ran chown Inside My Container

📚 This post is part of the "MLOps & Deployment" series

Fixing Docker “Permission denied” for a Non-Root Container User

The Proper Fix: Own It at Build, Repair Volumes at Runtime

You're in

References

Citation