Introduction

Listing Docker volumes can mean two different things: showing all named volumes on the host or showing which mounts a specific container is using. Docker has commands for both, and knowing the difference matters because a container may use named volumes, bind mounts, or temporary filesystems.

List All Named Volumes on the Host

If you want to see every named volume Docker knows about, use docker volume ls.

docker volume ls

Typical output looks like this:

DRIVER    VOLUME NAME
local     myapp_data
local     postgres_data

This command is host-level. It does not tell you which running container uses each volume, only that the volumes exist in Docker's local volume store.

To inspect one of those volumes in more detail:

docker volume inspect postgres_data

That shows metadata such as the mountpoint on disk, driver, and labels.

List the Volumes Used by a Specific Container

If the question is really "what is mounted into this container," inspect the container rather than the volume list.

docker inspect my-container

The raw output is large, so it is usually better to extract only the mount information:

docker inspect --format='{{json .Mounts}}' my-container

Example output:

[{"Type":"volume","Name":"postgres_data","Source":"/var/lib/docker/volumes/postgres_data/_data","Destination":"/var/lib/postgresql/data"}]

This tells you:

• the mount type
• the host-side source path
• the container destination path
• the named volume, when one is involved

That is the most direct answer when you are debugging persistent data inside a single container.

Understand the Difference Between Volume Types

Docker mounts are not all the same. A container can use:

• a named volume managed by Docker
• a bind mount that points to a host directory
• a tmpfs mount stored in memory

That distinction matters because docker volume ls only shows named volumes. If your Compose file mounts ./data:/app/data, that is a bind mount, not a Docker volume, so it will not appear in the volume list.

For example:

1services:
2  app:
3    image: nginx:alpine
4    volumes:
5      - ./site:/usr/share/nginx/html:ro
6      - app_cache:/var/cache/app
7
8volumes:
9  app_cache:

In that example:

• './site:/usr/share/nginx/html:ro is a bind mount'
• 'app_cache:/var/cache/app is a named volume'

The bind mount appears in .Mounts during docker inspect, but not in docker volume ls.

Use Compose-Aware Checks When Needed

If you are working in a Compose project, first find the real container name:

docker compose ps

Then inspect the container:

docker inspect --format='{{range .Mounts}}{{println .Type .Source "->" .Destination}}{{end}}' myproject-db-1

This shorter view is handy when you only care about the source and destination mapping. It makes it obvious whether the data is coming from a host path or from a named Docker volume.

You can combine this with docker volume inspect on any named volume you discover to trace the storage path all the way back to the host filesystem.

Practical Debugging Workflow

When volume-related issues appear, use a fixed sequence:

1. Run docker compose ps or docker ps to identify the container
2. Run docker inspect --format='{{json .Mounts}}' ...
3. Check whether each mount is a bind mount or named volume
4. If it is a named volume, run docker volume inspect

That sequence removes ambiguity quickly. It also helps when a team says "the volume is missing" but the real issue is that the service is using a bind mount from the wrong directory.

Common Pitfalls

• Using docker volume ls to debug bind mounts does not work because bind mounts are not named volumes.
• Inspecting the wrong container is common in Compose projects where container names are generated. Check docker compose ps first.
• Assuming a listed volume is attached to the current container is incorrect. A volume can exist on the host without being mounted into the container you care about.
• Reading the full docker inspect output manually is slow and error-prone. Filter to .Mounts so the relevant data is obvious.
• Confusing the host source path with the container destination path can lead to deleting or editing the wrong data location.

Summary

• Use docker volume ls to list named volumes on the host.
• Use docker inspect --format='{{json .Mounts}}' container to see what a specific container mounts.
• Distinguish named volumes from bind mounts before diagnosing storage issues.
• In Compose projects, identify the generated container name first with docker compose ps.
• Follow the inspect sequence consistently to find where persistent data is really stored.