docker compose secrets: file permission denied on mount

TL;DR

Compose mounts secret files into the container, and the mount fails when the host file is not readable by the Docker daemon user or SELinux blocks the access. Fix ownership and permissions on the host file (and relabel for SELinux), then recreate the service. The mount succeeds.

Error

docker compose secrets: file permission denied on mount

Steps

1. Inspect the host file: check owner, group, and mode on the file referenced by the compose secrets section. Expected: you see who can read it; a 600 file owned by another user explains the denial.
2. Fix ownership or permissions: make the file readable by the user running the Docker daemon (or your user for rootless Docker), keeping it as restrictive as possible. Expected: the daemon user can read the file.
3. On SELinux systems, relabel the file so the container can access it. Expected: no AVC denials in the audit log for the file.
4. Recreate the service: run docker compose up -d again so the mount is re-attempted with the fixed permissions. Expected: the container starts and the secret is visible at the mount path.
5. Verify inside the container that the secret file is present and readable by the application user. Expected: the app reads the secret without permission errors.

When to use

• docker compose up fails mounting a file-based secret with permission denied
• Rootless Docker or SELinux-enforcing hosts
• Secrets that work with docker run but fail under compose (path or user mismatch)

When not to use

• Docker Swarm secrets (different mechanism)
• The file does not exist at all (path error, not permissions)

Tool compatibility

• Docker Compose file-based secrets; Linux permissions, SELinux; rootless Docker

Variant phrasings

compose secret permission denied selinux

Relabel the file for container access; SELinux blocks even root-owned files without the right label.

rootless docker compose secret mount fails

The file must be readable by your user, not root; rootless daemons run as you.

Why it happens

The Docker daemon (or the rootless user) performs the bind mount before the container starts, so host-side permissions gate the mount. Compose does not chmod your files for you, and SELinux adds a label check on top of the classic permission bits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstvEa3wFfda6XQk_qNsrwIQ