Docker Volume Permissions Checklist: 7 Checks (2026)

Docker volume security is not really about what you store. It is about who can reach it and what they can do once they get there. A container with /etc bind-mounted can rewrite passwd and sudoers. A container with a read-write docker.sock can start a privileged one. This page documents the 7 checks in the CtrlOps Volume Permissions audit, in the order the audit runs them.

Every threshold below is transcribed from the audit script itself. One detail is worth carrying through the whole page: unlike the other Docker audits, four of these checks inspect every container on the host, stopped ones included, because a stopped container's mounts still describe what the host handed out and its volume data is still sitting on disk.

Key takeaways

Seven checks, split between what containers were given and what is left behind on the filesystem.

• Two are rated HIGH: sensitive host path mounts and writable mounts, which is where a writable docker.sock is caught. Four are MEDIUM and one is LOW.
• All seven need root. Three query the daemon, and four read /var/lib/docker/volumes directly, which is mode 701 on a healthy host and unreadable without it.
• Checks 1, 2, 6 and 7 cover stopped containers too. A container that is not running still has its mounts recorded, and restarting it re-grants every one of them.
• Checks 3, 4 and 5 read the filesystem, not Docker. They work on a host where the daemon is down, and they skip when the data root has been moved somewhere other than /var/lib/docker.
• The whole audit takes about 13 seconds when CtrlOps runs it over your existing SSH connection, against roughly 6 minutes of docker inspect, find and stat by hand.

Check 1: Are containers bind-mounting sensitive host paths?

A container with /etc mounted can rewrite passwd, shadow and sudoers. A container with / mounted owns the host outright. A container with docker.sock mounted can create a privileged container, which is the same thing with an extra step. These mounts do not weaken isolation, they remove it.

The audit inspects the bind mounts of every container, running or stopped, and matches the source path against /, /etc, /root, /boot, /proc, /sys, /dev, /var/run/docker.sock, /run/docker.sock, /var/lib/docker and /home. Both socket spellings are matched, because /var/run is a symlink to /run and docker inspect reports whichever path the container was started with.

How to check manually

docker ps -a --format '{{.Names}}' | while read c; do
  mounts=$(docker inspect -f '{{range .Mounts}}{{if eq .Type "bind"}}{{.Source}} {{end}}{{end}}' "$c")
  [ -n "$mounts" ] && echo "$c: $mounts"
done

There is no warning branch. A monitoring agent with /proc mounted read-only may well be a deliberate and reasonable decision, but the audit's job is to put the mount in front of you rather than to guess which ones you meant.

How to fix it

# Instead of handing over a host directory
docker run -v /etc:/host-etc nginx

# Mount only what the container actually needs, read-only
docker run -v app-config:/etc/app-config:ro nginx

If docker.sock access is genuinely required, by a CI runner or a monitoring agent, put a filtering proxy in front of the API rather than mounting the socket directly:

services:
  monitor:
    environment:
      DOCKER_HOST: tcp://docker-proxy:2375

Check 2: Are volume mounts writable when they should not be?

Docker mounts volumes read-write by default. Every volume added without :ro gives the container write access, including config files it only ever reads. The worst case is a writable docker.sock, which hands the container control of the daemon.

The audit walks every mount of every container, running or stopped, counts read-write against read-only, and flags a docker.sock mounted read-write as a failure on its own.

How to check manually

docker ps -a --format '{{.Names}}' | while read c; do
  docker inspect -f '{{range .Mounts}}{{.Source}} RW={{.RW}}
{{end}}' "$c" | sed "s/^/$c: /"
done

The pass with counts is deliberately informational. There is no correct ratio of read-write to read-only mounts, so the audit reports the numbers and leaves the judgement to you rather than inventing a threshold.

How to fix it

# Read-only bind mount
docker run -v /app/config:/config:ro myapp

# The --mount syntax says the same thing more explicitly
docker run --mount type=bind,src=/app/config,dst=/config,readonly myapp

services:
  app:
    volumes:
      - ./config:/app/config:ro
      - ./logs:/app/logs          # the only one that needs write access

Check 3: Are volume data directories world-writable?

Named volume data lives under /var/lib/docker/volumes/<name>/_data. If a volume's data directory carries the world-writable bit, any local account on the host can modify its contents, not just root and not just the container that owns it. On a shared host, a CI server or any machine with multiple user accounts, that is a real path to tampering.

The audit scans exactly two levels deep under /var/lib/docker/volumes, which is the <name>/_data layer, for directories with permission bit 0002 set, and reports up to ten.

How to check manually

sudo find /var/lib/docker/volumes -mindepth 2 -maxdepth 2 -type d -perm -0002

How to fix it

# One volume
sudo chmod o-w /var/lib/docker/volumes/myvolume/_data

# Everything the scan flagged
sudo find /var/lib/docker/volumes -mindepth 2 -maxdepth 2 -type d -perm -0002 -exec chmod o-w {} \;

Check which containers use a volume before changing its permissions:

docker ps -a --filter volume=myvolume --format '{{.Names}}'

Check 4: Are volumes owned by orphaned UIDs?

When an image or container is removed, its volume data stays behind. The files may be owned by a UID that maps to nothing: no host user, and no container configured to run as it. Those volumes are blind spots, because nobody knows what is in them, who wrote them or whether they hold anything sensitive.

The nuance that makes this check useful is what it does not flag. A uid with no host user is completely normal, because postgres at 999 and nginx at 101 exist only inside their images. The audit builds the list of uids that running and stopped containers are configured to use, and only reports data owned by a uid that appears in neither that list nor /etc/passwd.

How to check manually

# uids any container is configured to run as
docker ps -aq | while read c; do docker inspect -f '{{.Config.User}}' "$c"; done | cut -d: -f1 | grep -E '^[0-9]+$' | sort -u

# owners of the volume data directories
sudo sh -c 'for d in /var/lib/docker/volumes/*/_data; do printf "%s %s\n" "$(stat -c %u "$d")" "$d"; done'

It warns rather than fails because orphaned data is a housekeeping problem that occasionally turns out to be the only surviving copy of something. The correct response is to look before deleting.

How to fix it

# See what is in it
sudo ls -la /var/lib/docker/volumes/<volume-name>/_data/

# Keep a copy if it matters
sudo cp -a /var/lib/docker/volumes/<volume-name>/_data/ /backup/<volume-name>/

# Then remove the volume
docker volume rm <volume-name>

Check 5: Is the volume directory permission set correctly?

/var/lib/docker/volumes is the gate in front of every named volume on the host. Docker sets it to 701 or 711, which lets root manage volumes while unprivileged accounts cannot list or traverse the directory. Anything looser, 755 or 777, lets any local account walk into every volume's data at once. One permissive parent exposes everything underneath it.

The audit reads the mode of that one directory and compares it against the known-safe set: 700, 701, 710 and 711. Per-volume modes are deliberately left to check 3, so a single 777 volume produces one finding rather than two.

How to check manually

sudo stat -c '%a %n' /var/lib/docker/volumes

How to fix it

sudo chmod 701 /var/lib/docker/volumes
sudo stat -c '%a %n' /var/lib/docker/volumes

Check 6: Are there anonymous or dangling volumes?

Dangling volumes are volumes no container references. They accumulate when containers are removed without -v, or when a Compose stack is torn down without --volumes. Each one may hold stale state: a database directory, uploaded files, a dump somebody took before a migration, or credentials that are still valid.

The audit lists volumes with Docker's own dangling=true filter and reports the count with up to five examples.

How to check manually

docker volume ls -f dangling=true
docker volume ls -f dangling=true -q | wc -l

How to fix it

# Look before you prune
docker volume ls -f dangling=true
docker volume inspect <volume-name>
docker volume rm <volume-name>

# Only once you know what is in them
docker volume prune

Then stop them accumulating:

docker compose down --volumes
docker rm -v <container-name>

Check 7: Are containers running with a read-only root filesystem?

A read-only root filesystem stops a compromised process from writing into the container: no dropped binaries, no modified application code, no persistence outside the paths you mounted deliberately. It does not prevent the compromise, it removes most of what usually comes next.

The audit reads HostConfig.ReadonlyRootfs across every container on the host, stopped ones included, and reports how many lack it out of the total.

How to check manually

docker ps -a --format '{{.Names}}' | while read c; do
  echo "$c: ReadonlyRootfs=$(docker inspect -f '{{.HostConfig.ReadonlyRootfs}}' "$c")"
done

This check overlaps with check 5 of the Container Hardening audit, and the two differ in scope and severity on purpose. That one is LOW and reads running containers as a hardening control. This one is MEDIUM and reads every container, because in a volume context a writable root filesystem is also where data ends up that nobody meant to persist.

How to fix it

docker run --read-only \
  --tmpfs /tmp:rw,noexec,nosuid \
  --tmpfs /var/run:rw,noexec,nosuid \
  myapp

services:
  app:
    read_only: true
    tmpfs:
      - /tmp:rw,noexec,nosuid
      - /var/run:rw,noexec,nosuid
    volumes:
      - app-data:/app/data      # the only writable path

Test in staging first. Most applications need /tmp, /var/run and one data directory, and the ones that need more tell you within seconds of starting.

What this audit does not cover

This audit reads mount paths, file permissions, ownership and read-only enforcement. It does not check:

• Container-level hardening. Privileged mode, capabilities and the runtime user are the Container Hardening audit.
• Daemon-level controls. Socket exposure, rootless mode and log rotation are the Daemon and Socket audit.
• Image contents. CVE scanning, embedded secrets and EOL base images are the Image Vulnerabilities audit.
• Network exposure. Port publishing, inter-container connectivity and env secrets are the Network and Supply Chain audit.
• Runtime limits. Seccomp, AppArmor and memory, CPU and PID caps are the Runtime and Resources audit.
• What is inside the volumes. The audit reads ownership and permissions, never file contents.

The manual audit problem at scale

These seven checks need root and move between docker inspect, find, stat and the daemon's volume list. On one host that is about six minutes. On ten servers it is an hour of repetitive commands, and the finding easiest to miss is a writable docker.sock on a container that has been stopped for a month and will hand over the host the moment somebody starts it again.

How CtrlOps runs all 7 checks in one click

Instead of running these commands on every server by hand, CtrlOps runs the whole Volume Permissions audit over the SSH connection you already have open. Nothing is installed on the server: no agent, no daemon, no package, no new credentials. The checks are read-only POSIX shell that executes, streams its results back, and leaves nothing behind.

Watch it run

The recording below walks through the SSH and Access audit rather than this one, but the flow is identical for every audit in the catalog: pick it, watch the checks stream in, read the score, send the failures to the AI Terminal.

Step 1: Open the Audit tab

Connect to your server in CtrlOps and open the Audit tab in the left sidebar.

Step 2: Select Volume Permissions

Choose it from the Docker category. All 7 checks are listed with their descriptions, severity levels and the estimated run time, about 13 seconds in total. Every check on this audit needs root, and the UI says so before you run anything.

Step 3: Run it

The audit runs over your existing SSH session. Results stream in as they complete, so you watch each check pass, warn or fail rather than waiting on a final report.

Step 4: Read the report

You get a summary containing:

• A hardening score out of 100
• A severity breakdown: how many HIGH, MEDIUM and LOW findings
• Pass, warning, failed and skipped counts
• A findings table naming the container, the source path and the destination for every sensitive mount

Step 5: Fix what failed

Select the failed findings and send them to the AI Terminal. Each proposed fix command appears with an explanation of what it changes. Nothing runs until you review and approve it, which matters here more than anywhere else in the Docker category: a chmod on the wrong volume directory can stop an application from writing its own data.

Step 6: Re-run and compare

Run the same audit again after applying the fixes and watch the score move. Check 6 is the one to revisit quarterly, because dangling volumes accumulate from ordinary work rather than from mistakes.

Conclusion

Volume findings age differently from the rest of the Docker category. A privileged container is visible in docker ps. A volume left behind by an image you deleted last spring is visible to nothing you look at, and it may still hold a database dump with credentials that still work.

Two of these seven are HIGH, and both describe a container that was handed part of the host. The rest are about what accumulates on disk when nobody is watching. The CtrlOps Security Audit runs the set in about 13 seconds per server, agentlessly, and reads stopped containers along with running ones.

The neighbouring checklists cover the other container layers: container hardening, daemon and socket, image vulnerabilities, runtime and resources and network and supply chain.

Frequently asked questions