Inspect Docker Volumes Without Guessing Their Mount Paths

docker volume inspect tells you exactly where Docker keeps a volume's data, instead of you guessing under /var/lib/docker. In the next ten minutes you will check your version, find the exact volume name, read the full JSON record, and pull out one field with a template, all without changing a single volume.

You need the Docker CLI and access to its daemon. Most of this needs no sudo at all: if your account cannot reach the Docker socket, fix that through your normal Docker administration process rather than sprinkling sudo over every example. Reading a mount path is not permission to alter what is underneath it.

1. Check the installed command

Confirm the version and the exact interface before copying a command into a script:

$ docker --version
Docker version 29.8.1, build 4a63305
$ dpkg-query -W -f='${Package} ${Version}\n' docker-ce-cli
docker-ce-cli 5:29.8.1-1~ubuntu.24.04~noble
$ docker volume inspect --help
Usage:  docker volume inspect [OPTIONS] VOLUME [VOLUME...]

Display detailed information on one or more volumes

The command takes one or more volume names, and its only option in this CLI is -f or --format. There is no option here to create, mount, detach or remove a volume: this command reads, nothing else.

Checkpoint: if the help output shows a different interface, keep the installed command's syntax as the authority for your host. Docker CLI behaviour can vary between releases.

2. Find an exact volume name

Use docker volume ls when you do not already have the name. It also doubles as a guard against a spelling error:

$ docker volume ls
DRIVER    VOLUME NAME
local     commonweal-data
local     deploy_app-pgdata
local     webvm_home

3. Read the complete record

Pass an exact name to docker volume inspect:

$ docker volume inspect commonweal-data
[
    {
        "CreatedAt": "2026-09-19T14:22:26+01:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/commonweal-data/_data",
        "Name": "commonweal-data",
        "Options": null,
        "Scope": "local"
    }
]

The default result is a JSON array, even for a single volume. The record shows the Docker name, driver, creation time, scope, driver options and labels, plus the daemon-side mount point. A null value is real output here: it is different from an empty object or an empty label set.

The Mountpoint path belongs to the Docker host or daemon environment. With a remote Docker context, it is not necessarily a path on the machine where you typed the command, so do not assume ls or a backup tool on your workstation can reach it directly.

4. Inspect several volumes in one call

List multiple names as separate arguments:

$ docker volume inspect commonweal-data deploy_app-pgdata
[
    {
        "CreatedAt": "2026-09-19T14:22:26+01:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/commonweal-data/_data",
        "Name": "commonweal-data",
        "Options": null,
        "Scope": "local"
    },
    {
        "CreatedAt": "2026-09-19T14:22:26+01:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/deploy_app-pgdata/_data",
        "Name": "deploy_app-pgdata",
        "Options": null,
        "Scope": "local"
    }
]

The result keeps one record per requested volume. Keep names as separate shell arguments, and quote a name that comes from a variable:

$ volume_name='commonweal-data'
$ docker volume inspect "$volume_name"

Do not build an argument list by blindly splitting untrusted text. A name containing shell syntax is input to validate, not a command fragment to trust.

5. Extract a field with a Go template

Use --format when a script needs one value rather than the full JSON document. This prints the mount point for each named volume:

$ docker volume inspect --format '{{.Name}} -> {{.Mountpoint}}' commonweal-data deploy_app-pgdata
commonweal-data -> /var/lib/docker/volumes/commonweal-data/_data
deploy_app-pgdata -> /var/lib/docker/volumes/deploy_app-pgdata/_data

The template runs once per result. The field names match the object Docker returns: Name, Mountpoint, Driver, Scope, Labels and Options are the useful starting points. Use single quotes around the template in a POSIX shell so it does not expand the braces or dollar signs itself.

For machine-readable output, ask for Docker's own JSON representation of each object:

$ docker volume inspect --format '{{json .}}' commonweal-data
{"CreatedAt":"2026-09-19T14:22:26+01:00","Driver":"local","Labels":null,"Mountpoint":"/var/lib/docker/volumes/commonweal-data/_data","Name":"commonweal-data","Options":null,"Scope":"local"}

Use a JSON parser downstream if you need reliable field handling. Do not parse the pretty-printed default with line-oriented tools when a template or parser can express the requirement directly.

6. Diagnose a failed lookup

A name that does not exist returns a non-zero status and an empty JSON array before the daemon error:

$ docker volume inspect definitely-not-a-volume
[]
Error response from daemon: get definitely-not-a-volume: no such volume
$ printf 'exit status: %s\n' "$?"
exit status: 1

In a script, capture the status immediately after the inspect command. Do not let an empty array look like a successful discovery: re-run docker volume ls, check the spelling, and confirm you are using the intended Docker context.

If the error says permission is denied while connecting to the daemon, that is an access problem, not evidence the volume is missing. If it says the daemon is unavailable, check the service or remote endpoint through your platform's normal procedure. Those separate repairs may need elevated privileges, but docker volume inspect itself stays read-only throughout.

7. Keep the safety boundary clear

Inspection does not change a volume, but the printed mount path identifies persistent application data. Treat it as sensitive operational information, especially when labels or names reveal a project, customer or environment.

Warning: do not follow an inspect command with docker volume rm or docker volume prune as a cleanup experiment. Those are different, potentially destructive operations. Before removing anything, establish that no container needs the volume, confirm a tested backup, and record an explicit recovery plan. There is no undo in docker volume inspect itself, because it makes no state change at all.

Done means