Find where Docker stores images and container data

Start with docker info, but do not assume its Docker Root Dir accounts for every image layer in every Docker version. Storage location depends on the active daemon, platform, image store, and configuration.

docker context show
docker info
docker system df -v

A remote context reports the remote daemon's storage, not your laptop's. Docker Desktop may report paths inside its Linux VM rather than paths directly visible on the host.

Common locations and important exceptions

Fresh Docker Engine 29 installations use the containerd image store by default. Existing installations and customized environments may use different layouts. The Docker data-root setting does not relocate containerd snapshotter data automatically.

For a classic storage-driver installation, directories such as overlay2, image, containers, volumes, and buildkit can hold layers, metadata, logs, volumes, or build cache. This is an illustrative legacy layout, not an API or a universal directory tree for current installations.

Inspect space through supported interfaces

docker system df -v helps separate object categories. Filesystem tools can provide read-only space and inode measurements on the relevant Linux mount points, subject to access and storage-backend accounting. Shared layers and sparse virtual disks mean apparent sizes do not always add up to physical usage.

Do not manually delete or edit Docker's layer directories, container metadata, or managed log files. Use supported removal and pruning commands after selecting disposable objects. docker system prune -a is a broad destructive action, not the default answer to every space investigation.

Guance disk metrics can track the mount points that hold this data. They measure filesystem capacity and inode usage, not a precise breakdown of one Docker directory.

Plan a data-root migration carefully

For the applicable Linux daemon, configuration may include:

{
  "data-root": "/data/docker"
}

Merge this into the existing valid daemon configuration; do not overwrite unrelated settings. Changing the path does not move old data.

A migration requires a compatible destination filesystem, sufficient space, application-consistent backups, and a maintenance window. Stop workloads and the relevant daemon/services, account for socket activation and live-restore behavior, and confirm that no process is still writing the source. Then copy data with ownership, permissions, hard links, ACLs, extended attributes, and sparse files preserved as applicable, using an administrative tool such as rsync configured for those requirements.

Validate the configuration, restart the correct service, and verify image inventory, containers, mounts, and application data before retiring the original copy. SELinux labels and storage-driver compatibility can require additional work. With a containerd image store, its data and configuration need a separate coordinated plan; moving only Docker's root is incomplete.

Desktop and portable transfers

Use Docker Desktop's supported settings to locate or move its disk image. Host paths and VM/WSL layouts vary by version and backend. Reclaiming data inside the VM and reducing the physical host file size are distinct operations; supported reclaim behavior also varies. A factory reset deletes data and is not a routine disk-compaction step.

To transfer images between machines, prefer a registry or docker image save/load. Do not treat a live copy of internal storage directories as a portable image backup. A container filesystem export is also not equivalent to saving image layers, metadata, and mounted volume data.

See Docker daemon storage configuration and Docker Desktop settings.