Check If a Docker Volume Is Assigned and Mounted to a Running Container

Docker volumes are a core feature for persisting data outside containers. However, one of the most common troubleshooting questions in Docker-based environments is:

“Is my volume actually mounted to the running container?”

This article provides a step-by-step, production-ready guide to verify whether a Docker volume is correctly assigned, mounted, and writable, using CLI tools and real-world debugging techniques.

Why Verifying Docker Volume Mounts Matters

Incorrectly mounted volumes can lead to:

• Data not being persisted
• Files disappearing after container restarts
• Applications writing to the container filesystem instead of the host
• Permission-related runtime errors

Before debugging application code, you should always confirm that Docker itself has mounted the volume correctly.

Step 1: List Running Containers

First, identify the running container you want to inspect.

docker ps

Example output:

CONTAINER ID   IMAGE               NAME               STATUS
f1a23bc45678   my-backend:latest   backend_service    Up 2 hours

You can use either the container ID or container name in the next steps.

Step 2: Inspect the Container Mounts

Use docker inspect to see all mounts attached to the container.

docker inspect backend_service

This command returns a large JSON object. The key section you are looking for is Mounts.

Step 3: Filter Only the Mounts Section (Recommended)

To avoid scrolling through hundreds of lines, filter the output:

docker inspect backend_service --format '{{ json .Mounts }}' | jq

If jq is not installed, you can still view raw output:

docker inspect backend_service | grep -A20 '"Mounts"'

Example: Correctly Mounted Volume

A properly mounted Docker volume looks like this:

"Mounts": [
  {
    "Type": "volume",
    "Name": "app-storage",
    "Source": "/var/lib/docker/volumes/app-storage/_data",
    "Destination": "/app/Storage",
    "Driver": "local",
    "Mode": "",
    "RW": true,
    "Propagation": ""
  }
]

Key Fields Explained

If RW is false, the volume is mounted read-only.

Step 4: Verify Volume From Inside the Container

Even if Docker shows the mount, confirm it from inside the container.

docker exec -it backend_service sh

(or bash, depending on the image)

Then run:

mount | grep Storage

or

df -h | grep app

You should see the volume mapped to the expected directory.

Step 5: Test Writing to the Volume

Inside the container, try creating a file:

cd /app/Storage
touch test.txt
echo "Docker volume test" > test.txt
ls -l

If this fails, you likely have a permission issue.

Step 6: Confirm Data Exists on the Host

If using a named volume:

docker volume inspect app-storage

Look for:

"Mountpoint": "/var/lib/docker/volumes/app-storage/_data"

Then on the host:

ls -l /var/lib/docker/volumes/app-storage/_data

If using a bind mount:

"Options": {
  "device": "/path/on/host",
  "o": "bind"
}

Verify directly:

ls -l /path/on/host

Common Problems and Fixes

1. Volume Exists but Is Not Mounted

Symptom:
docker volume inspect shows the volume, but container does not list it in Mounts.

Cause:
The volume is defined in Compose but the container was not recreated.

Fix:

docker compose down
docker compose up -d

2. Files Written Inside Container but Not on Host

Cause:

• Application writes to a different path
• Typo in mount path
• Double slashes (/app//Storage)

Fix:
Ensure the exact same path is used everywhere.

3. Permission Denied Errors

Cause:
Container runs as non-root user, host directory owned by root.

Fix Options:

• Fix ownership on host:

  chown -R 1000:1000 /path/on/host
  

• Or adjust Dockerfile:

  RUN mkdir -p /app/Storage && chown -R appuser:appuser /app/Storage
  

4. SELinux Blocking Writes (Linux Hosts)

Symptom:
Volume is mounted, permissions look fine, but writes fail.

Fix:
Use :Z or :z flag in Compose:

volumes:
  - app-storage:/app/Storage:Z

Best Practices for Docker Volume Debugging

• Always verify mounts using docker inspect
• Test write access from inside the container
• Prefer named volumes for portability
• Avoid typos in mount paths
• Recreate containers after Compose changes
• Log absolute paths used by the application

Conclusion

To confirm whether a Docker volume is correctly assigned and mounted:

1. List running containers
2. Inspect container mounts
3. Verify from inside the container
4. Test write access
5. Confirm data on the host

This systematic approach eliminates guesswork and helps quickly isolate whether the issue is Docker-related or application-related.