open /data/db.sqlite: permission denied (bind mount on SELinux host)

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.