EC
permission denied on volume mount
DockerERRORNotableStartupHIGH confidence

SELinux, AppArmor, or filesystem permissions are blocking volume access

What this means

This error occurs when Docker is blocked from mounting a host directory into a container due to insufficient permissions. The cause is often not standard file permissions but rather security modules like SELinux (on CentOS/RHEL) or AppArmor (on Ubuntu), or file ownership mismatches.

Why it happens
  1. 1SELinux policy on the host is preventing the container from accessing the specified directory.
  2. 2The user inside the container (e.g., 'node', 'nginx') has a different UID than the owner of the files on the host, preventing access.
  3. 3The host directory is located in a protected area that Docker is not allowed to access (e.g., user's home directory on some Docker Desktop configurations).
  4. 4Incorrect file ownership or permissions on the host directory.
How to reproduce

On an SELinux-enforced system, trying to mount a directory from the host without the correct security label.

trigger — this will error
trigger — this will error
# On a system with SELinux enabled (e.g., CentOS)
mkdir /path/to/data
touch /path/to/data/some-file.txt
# Attempt to mount the directory into a container
docker run -v /path/to/data:/data alpine ls /data

expected output

ls: can't open '/data': Permission denied

Fix 1

Append ':z' or ':Z' to the Volume Mount (SELinux)

WHEN Running on an SELinux-enforced host like CentOS, RHEL, or Fedora.

Append ':z' or ':Z' to the Volume Mount (SELinux)
# ':z' allows the content to be shared among multiple containers
docker run -v /path/to/data:/data:z alpine ls /data

# ':Z' makes the content private to this container
docker run -v /path/to/data:/data:Z alpine ls /data

Why this works

These flags instruct Docker to automatically relabel the host directory with the correct SELinux context, making it accessible to the container.

Fix 2

Match User IDs

WHEN The issue is a UID/GID mismatch between the host files and the container user.

Match User IDs
# Find the ownership of the host directory
# ls -ld /path/to/data -> drwxr-xr-x 2 1001 1001 4096 Mar 13 12:00 /path/to/data
# Run the container with the matching user and group ID
docker run --user 1001:1001 -v /path/to/data:/data alpine ls /data

Why this works

This forces the process inside the container to run as the same UID/GID as the owner of the host files, ensuring the file system permissions align.

What not to do

✕ Disable SELinux or AppArmor completely.

These security modules are a critical part of the host's defense. Disabling them system-wide to fix a Docker issue exposes the entire system to unrelated vulnerabilities.

✕ Run 'chmod 777' on the host directory.

While it might solve the immediate problem, it makes the directory world-writable, which is a significant security risk, especially for sensitive data.

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All Docker errors