Docker
Mounted Volumes
Container
Tutorial
DevOps

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.

bash
cat /proc/mounts

For focused checks, filter expected application paths:

bash
grep -E '/data|/config|/logs|/app' /proc/mounts

For richer details, inspect mountinfo:

bash
cat /proc/self/mountinfo | head -n 30

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.

bash
findmnt -T /data
mount | grep ' /data '

You can also inspect filesystem type:

bash
stat -f -c '%T' /data

This helps distinguish bind mounts, Docker managed volumes, and tmpfs style mounts.

Verify Read and Write Behavior

Test behavior directly with temporary probe files.

bash
echo "probe" > /data/.mount_probe
ls -l /data/.mount_probe

If write fails, inspect permissions and user identity:

bash
id
ls -ld /data

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.

bash
docker inspect <container_id> --format '{{json .Mounts}}'

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:

bash
docker inspect <container_id> --format '{{range .Mounts}}{{.Type}} {{.Source}} -> {{.Destination}} (ro={{.RW}}){{println}}{{end}}'

Build a Repeatable In Container Diagnostic Snippet

Use a compact shell check to speed troubleshooting.

bash
1#!/usr/bin/env sh
2set -eu
3
4echo "=== mount snapshot ==="
5cat /proc/mounts
6
7echo "=== key paths ==="
8for p in /data /config /logs; do
9  if [ -d "$p" ]; then
10    echo "found: $p"
11    ls -la "$p" | head -n 5
12  else
13    echo "missing: $p"
14  fi
15done

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:

bash
kubectl get pod <pod-name> -o yaml

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/mounts and /proc/self/mountinfo from 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 inspect data.
  • Use repeatable diagnostics to shorten incident response time.

Course illustration
Course illustration

All Rights Reserved.