19.2.6.3 Inspect Mount Output

When you run docker inspect on a container and examine the Mounts field, you get a detailed JSON array that describes every filesystem mount active inside that container. This section of the inspect output documents all the ways the container accesses storage outside its own writable layer, including bind mounts, named volumes, and tmpfs mounts.

Accessing Mount Output

docker inspect <container_name_or_id>

To extract only the mounts section:

docker inspect --format "{{json .Mounts}}" my_container

For a more readable format using the jq utility:

docker inspect my_container | jq '.[0].Mounts'

Structure of the Mounts Array

The Mounts field is a JSON array where each element represents a single mount point:

"Mounts": [
  {
    "Type": "bind",
    "Source": "/home/user/app/data",
    "Destination": "/app/data",
    "Mode": "rw",
    "RW": true,
    "Propagation": "rprivate"
  },
  {
    "Type": "volume",
    "Name": "app_storage",
    "Source": "/var/lib/docker/volumes/app_storage/_data",
    "Destination": "/app/storage",
    "Driver": "local",
    "Mode": "",
    "RW": true,
    "Propagation": ""
  },
  {
    "Type": "tmpfs",
    "Source": "",
    "Destination": "/tmp/cache",
    "Mode": "",
    "RW": true,
    "Propagation": ""
  }
]

Fields Common to All Mount Types

Type

The Type field identifies the kind of mount:

• bind: A host filesystem path is mounted directly into the container.
• volume: A Docker-managed named or anonymous volume is mounted.
• tmpfs: An in-memory filesystem is mounted; data is lost when the container stops.

Source

The Source field contains the path on the host machine where the mount originates:

• For bind mounts: the absolute host path specified at container creation.
• For named volumes: the path to the volume directory managed by Docker, typically under /var/lib/docker/volumes/<volume_name>/_data.
• For anonymous volumes: also a path under /var/lib/docker/volumes/, but with a generated UUID as the name.
• For tmpfs mounts: this field is empty since the storage exists only in memory.

Destination

The Destination field is the absolute path inside the container where the mount is accessible. This is the path container processes use to read from or write to the mount.

RW

The RW boolean indicates whether the mount is read-write (true) or read-only (false). A read-only mount prevents the container from writing to that path.

Mode

The Mode field holds the raw mount options string as passed at container creation. For bind mounts it typically shows rw, ro, z, or Z (for SELinux relabeling). For volumes this is often empty.

Bind Mount Fields

Bind mounts have additional context in the Propagation field:

{
  "Type": "bind",
  "Source": "/etc/nginx/conf.d",
  "Destination": "/etc/nginx/conf.d",
  "Mode": "ro",
  "RW": false,
  "Propagation": "rprivate"
}

Propagation

The Propagation field controls whether mounts created inside the container are visible on the host, and vice versa. Possible values:

• private: Mount events inside the container do not propagate to the host, and host mount events are not visible inside the container.
• rprivate: Recursive private — the same as private but applied recursively to all submounts.
• shared: Mount events propagate in both directions between the container and the host.
• rshared: Recursive shared.
• slave: The host can propagate mount events into the container, but not the reverse.
• rslave: Recursive slave.

The default propagation for bind mounts is rprivate.

Named Volume Fields

Named volumes have the Name and Driver fields:

{
  "Type": "volume",
  "Name": "postgres_data",
  "Source": "/var/lib/docker/volumes/postgres_data/_data",
  "Destination": "/var/lib/postgresql/data",
  "Driver": "local",
  "Mode": "",
  "RW": true,
  "Propagation": ""
}

• Name: The name of the Docker volume as created with docker volume create or specified in a compose file.
• Driver: The volume plugin used to manage the volume. local is the default built-in driver; third-party plugins appear here for network storage or cloud volumes.

Anonymous volumes are nearly identical but have a UUID-style name generated by Docker:

{
  "Type": "volume",
  "Name": "a4f3d2b1c5e6...",
  "Source": "/var/lib/docker/volumes/a4f3d2b1c5e6.../_data",
  "Destination": "/var/lib/mysql",
  "Driver": "local",
  "Mode": "",
  "RW": true,
  "Propagation": ""
}

tmpfs Mount Fields

For tmpfs mounts, the Source is always empty and the Propagation is always empty:

{
  "Type": "tmpfs",
  "Source": "",
  "Destination": "/run/secrets",
  "Mode": "",
  "RW": true,
  "Propagation": ""
}

tmpfs mounts are useful for storing sensitive data in memory that should never touch the disk, or for caching temporary data with low latency.

Practical Queries

List all mount destinations inside a container:

docker inspect --format "{{range .Mounts}}{{.Destination}}{{println}}{{end}}" my_container

Show only bind mounts:

docker inspect my_container | jq '.[0].Mounts[] | select(.Type == "bind")'

Show only read-only mounts:

docker inspect my_container | jq '.[0].Mounts[] | select(.RW == false)'

Show source and destination pairs:

docker inspect --format "{{range .Mounts}}{{.Source}} -> {{.Destination}}{{println}}{{end}}" my_container

Check if a specific volume is mounted:

docker inspect my_container | jq '.[0].Mounts[] | select(.Name == "postgres_data")'

How Mount Output Relates to Container Creation Flags

Each entry in the Mounts array corresponds to a flag used when running the container:

• --volume /host/path:/container/path or -v produces a bind mount entry.
• --volume volume_name:/container/path produces a named volume entry.
• --mount type=bind,... also produces a bind mount entry with more precise control.
• --mount type=tmpfs,... produces a tmpfs entry.
• --mount type=volume,... produces a named volume entry.

The inspect output is the canonical record of what was actually applied, including any defaults filled in by Docker that were not explicitly specified in the run command.

Use in Debugging

Mount inspection is commonly used when diagnosing issues where:

• A container cannot find a configuration file that should have been bind-mounted.
• Data written inside a container is not persisting because the path was not mounted to a volume.
• A container is writing to a path that was intended to be read-only.
• Two containers need to verify they share the same named volume or bind mount source.

Checking the Mounts array in docker inspect gives a definitive answer about what storage the container actually has access to at runtime.