docker compose secrets: file permission denied on mount

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR: Add the :z (shared) or :Z (private) flag to the bind mount: -v /host/data URIs/data URIsz. SELinux blocks the container process from touching host files that lack a container file label, and the flag relabels on mount. Without it, everything looks right but every write gets permission denied.

The error

open /data/db.sqlite: permission denied

(inside the container, when the same operation works on a named volume or with --privileged)

Fix it

1. Confirm SELinux is the cause: ls -Z /host/data shows unconfined_u:object_r:user_home_t:s0 (no container label), and ausearch -m avc -ts recent | grep denied shows denials. Expected: AVC denials for the container process.

2. Relabel with the shared flag (multiple containers need it) or private flag (single container): docker run -v /host/data URIs/data URIsz [image] Expected: reads and writes work.

3. For --mount syntax: --mount type=bind,source=/host/data,target=/data,bind-propagation=rshared does NOT set the label; use the :z short syntax or chcon -Rt container_file_t /host/data on the host.

When this applies

• RHEL/CentOS/Fedora/Rocky hosts with SELinux enforcing
• Bind mounts failing with permission denied while named volumes work

When this does NOT apply

• SELinux disabled or permissive (getenforce says so)
• UID/GID mismatch permission errors (fix with chown, not labels)

Versions

All Docker versions on SELinux-enforcing distros.

Why it happens

SELinux confines the container process to files labeled container_file_t. Host files carry their own labels, and the kernel denies access regardless of unix permissions. :z tells docker to relabel the content on mount.

Edge cases

• :Z (capital) gives a private unshared label; a second container mounting the same path with :Z will break the first. Use :z when sharing.
• Relabeling touches every file; on huge directories the first mount is slow.
• podman users: same flags, same reason; this skill is docker but the mechanism is identical.
• Disabling SELinux "fixes" it too, at the cost of the confinement; prefer the label flags.

Asked: how to fix open /data/db.sqlite: permission denied (bind mount on SELinux host). Verified answer: Fixes 'permission denied' writing to bind-mounted volumes on SELinux systems (RHEL, CentOS, Fedora). Use when the mount works but the container cannot read/write files. The fix steps above were cross-checked against the accepted community answer at https://stackoverflow.com/questions/52228696 (so:52228696), which confirms the same resolution.

Not specified by the original author.

TL;DR

Pass the secret id through as a build argument and use that argument as the Dockerfile secret id, for example ARG SECRETID with RUN --mount=type=secret,id=$SECRETID,target=/run/secrets/secret.txt.

Steps

1. A Dockerfile RUN --mount=type=secret,id=secret-file step finds nothing in /run/secrets when the secret was set through the Dagger CLI. The reason: a secret set via the CLI gets its name set to the sha256 checksum of its value, not to any friendly name, so a Dockerfile looking up a named id never matches. A related gotcha is that WithMountedSecret needs the exact destination file path to mount to.
2. Do not rely on the CLI-set secret name. Pass the secret id through as a build argument and use that argument as the Dockerfile secret id, for example ARG SECRETID with RUN --mount=type=secret,id=$SECRETID,target=/run/secrets/secret.txt. This was answered by a Dagger contributor and confirmed working by the reporter, and related fixes landed in the cookbook.

When to use

You are seeing this: A related gotcha is that WithMountedSecret needs the exact destination file path to mount to. Use this skill when you run into "Docker build secrets not visible in /run/secrets when set through the Dagger CLI".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The reason: a secret set via the CLI gets its name set to the sha256 checksum of its value, not to any friendly name, so a Dockerfile looking up a named id

The thread asked: A Dockerfile RUN --mount=type=secret,id=secret-file step finds nothing in /run/secrets when the secret was set through the Dagger CLI. The reason: a secret set via the CLI gets its name set to the sha256 checksum of its value, not to any friendly name, so a Dockerfile looking up a named id never matches. A related gotcha is that WithMountedSecret needs the exact destination file path to mount to.

The verified answer: Do not rely on the CLI-set secret name. Pass the secret id through as a build argument and use that argument as the Dockerfile secret id, for example ARG SECRETID with RUN --mount=type=secret,id=$SECRETID,target=/run/secrets/secret.txt. This was answered by a Dagger contributor and confirmed working by the reporter, and related fixes landed in the cookbook.

Thread: https://vectle.com/threads/thr_DASNBtspJUaTfV87BI4TNA