Manage permissions on shared Docker volumes

Volume access depends on the process's effective identity and the mounted filesystem's permissions. Numeric UID/GID mismatches are common, but read-only mounts, parent-directory permissions, ACLs, SELinux, and user-namespace mappings can produce similar failures.

Inspect the process and mount

docker inspect --format '{{json .Mounts}}' myapp
docker exec myapp id
ls -ldn /opt/app/data

The exec identity reflects the new exec process. If an entrypoint drops privileges before launching the application, inspect that application's actual process identity too. The container's configured USER alone may not tell the whole story.

On a conventional Linux bind mount without user remapping, numeric ownership is shared across the host and container views. A username spelled app in two images does not ensure the same UID. Rootless Docker and userns-remap add mappings that must be considered explicitly.

Prepare a dedicated bind-mounted directory

For a new, dedicated directory and an application intentionally running as UID/GID 1000:

sudo mkdir -p /opt/app/data
sudo chown 1000:1000 /opt/app/data
sudo chmod 0750 /opt/app/data
docker run -d --name myapp --user 1000:1000 \
  --mount type=bind,source=/opt/app/data,target=/data \
  myapp:1.2

Use actual required IDs and verify that the image supports this runtime user. This changes only the directory itself. Existing contents may need a reviewed migration; do not apply recursive ownership changes to a broad host path just to suppress an error. Changing the user can also prevent an image's initialization routine from working.

Understand named-volume initialization

docker run -d --mount type=volume,source=appdata,target=/data myapp:1.2

An empty volume mounted over an image directory is normally populated from that directory, unless copy-up is disabled. Existing image ownership can therefore help initialize it. A nonempty volume is not reset to new image ownership on every start, and volume drivers or mount options can change behavior. Named volumes are not an automatic permission-repair service.

Some images intentionally start as root, prepare a narrowly scoped data directory, and then drop privileges. A custom entrypoint can follow that pattern using an installed tool such as su-exec or gosu, but it must check failures and preserve the application's arguments. Blindly running chown -R on every startup can be slow, destructive to shared ownership, or incompatible with remote storage.

Let several containers share writes

Use an agreed group and supplementary membership, for example --group-add 3000. Give the directory appropriate group access and consider the setgid bit so newly created files inherit the directory's group. The application's umask or default ACLs must also permit the intended group access. Group write on existing files alone does not guarantee access to files created later.

Shared write permission does not make concurrent application updates safe. Database files, locks, and file formats have their own coordination requirements.

Check platform-specific controls

On SELinux hosts, :z denotes shared relabeling and :Z private relabeling for suitable bind mounts. Use them only for the intended data path; changing security labels on system directories can break other services. chmod 777 does not solve SELinux or a read-only filesystem and grants unnecessarily broad access.

Rootless mode maps container identities into the host user's namespace; non-root container UIDs can still map to subordinate host IDs and encounter bind-mount failures. Do not assume rootless mode eliminates ownership problems.

In Kubernetes, runAsUser, runAsGroup, and fsGroup address related concerns. Whether volume ownership is changed depends on the volume type, filesystem, and CSI driver; fsGroup is not a universal recursive fix for every mount.

See Docker volumes, user namespace remapping, and Kubernetes security contexts.