How to list Docker mounted volumes from within the container
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
When a container cannot read expected files, volume mount problems are often the root cause. From inside the container, you can inspect active mount points even without Docker daemon access. A dependable diagnosis combines in container mount inspection and host side metadata verification.
Inspect Mounts from Inside the Container
Linux containers expose mount information through proc files.
For focused checks, filter expected application paths:
For richer details, inspect mountinfo:
If your target path does not appear here, it is not mounted in this container namespace.
Identify Mount Type and Access Mode
A mount can be present but still misconfigured, for example read only or wrong filesystem type.
You can also inspect filesystem type:
This helps distinguish bind mounts, Docker managed volumes, and tmpfs style mounts.
Verify Read and Write Behavior
Test behavior directly with temporary probe files.
If write fails, inspect permissions and user identity:
A common issue is UID mismatch between container process and host directory owner.
Correlate with Host Side docker inspect
Inside container checks do not reveal full source path mapping. On the Docker host, inspect mount metadata.
This shows destination path, source path, mount type, and read only flag. Compare this with in container findings for complete diagnosis.
For quick label style output:
Build a Repeatable In Container Diagnostic Snippet
Use a compact shell check to speed troubleshooting.
This is useful in incident runbooks and debugging images.
Common Container Volume Scenarios
Typical causes of mount related failures:
- Path typo in compose or run command.
- Read only mount where application expects write.
- Host path exists but empty due wrong source mapping.
- Kubernetes style overlay confusion when translated to local Docker tests.
Checking both mount presence and data visibility avoids false assumptions.
Operational Advice
For production services:
- Log effective mount paths on startup.
- Run lightweight mount readiness checks.
- Fail fast when required mount path is missing.
These checks turn hidden infrastructure misconfiguration into clear startup errors.
Kubernetes and Orchestrated Environments
In orchestrated setups, mount behavior may come from volume claims, config maps, or secrets. Inside container checks remain useful, but always correlate with orchestrator definitions to confirm expected source mapping and read only flags.
For Kubernetes debugging, compare in container mount state with pod volume definitions:
This helps distinguish application issues from deployment manifest mistakes.
Common Pitfalls
- Looking only at application logs without inspecting actual mount tables.
- Assuming mount exists because path directory exists in image.
- Ignoring read only flags and misdiagnosing write errors.
- Skipping host side inspect when source destination mapping is unclear.
- Leaving probe files behind in persistent volumes after debugging.
Summary
- Inspect
/proc/mountsand/proc/self/mountinfofrom inside the container. - Confirm mount type, path, and access mode before deeper debugging.
- Validate read and write behavior with temporary probe files.
- Correlate in container observations with host side
docker inspectdata. - Use repeatable diagnostics to shorten incident response time.

