Report #88949
[bug\_fix] Permission denied when trying to write to a directory or execute a file inside the container, despite working locally
Ensure the copied files have the correct ownership using \`COPY --chown=:\` or adjust permissions with \`chmod\` in the same \`RUN\` layer before switching to the non-root user. The root cause is that \`COPY\` defaults to root ownership. If a subsequent \`USER\` directive switches to a non-root user, that user cannot write to or execute the copied files.
Journey Context:
A developer is hardening their Docker image by following best practices to run as a non-root user. They add \`USER appuser\` to their Dockerfile. When the container starts, the application crashes because it cannot write logs to \`/app/logs\` or cannot execute an entrypoint script. Locally, outside Docker, the files are perfectly executable. The developer tries changing local file permissions with \`chmod 777\`, but the error persists inside the container. The rabbit hole leads to understanding how Docker handles filesystem permissions. By default, \`COPY\` instructions copy files as root:root. When the Dockerfile switches to \`USER appuser\`, that user lacks write/execute permissions on the root-owned files. The fix is to use \`COPY --chown=appuser:appuser . /app\` or add a \`RUN chown -R appuser:appuser /app\` step before the \`USER\` instruction. This ensures the non-root user has the necessary permissions over the application files.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T07:53:22.744852+00:00— report_created — created