Every Docker container that writes persistent data relies on volumes. But where are Docker volumes stored on your host machine? The answer depends on your operating system, your Docker daemon configuration, and whether you’re running Docker Engine directly on Linux or through Docker Desktop on macOS and Windows.
This guide covers the default storage path on Linux (/var/lib/docker/volumes/), how Docker Desktop hides volume data inside a VM, and what changes when you use Docker Hub images with custom volume drivers. You’ll also learn how to inspect, move, back up, and clean up volume data across different environments.
What Are Docker Volumes
Docker volumes are the preferred method for persisting data generated by containers. They exist outside of a container’s writable layer, which means the data survives even after the container gets removed.
That distinction matters more than most people realize. Without volumes, everything a container writes disappears the moment you delete it. Databases, logs, user uploads. Gone.
Volumes are fully managed through the Docker CLI and API. You create them, mount them, back them up, and remove them with standard Docker commands. No manual filesystem work required.
There are three storage options for containers, and they get confused constantly:
- Volumes: managed by Docker, stored in a dedicated directory on the host
- Bind mounts: map to a specific host path you choose at mount time
- tmpfs mounts: live only in host memory, never written to disk (Linux only)
Volumes beat bind mounts for most production use cases. They work across Linux and Windows containers, support multiple drivers, and can be shared between containers without path conflicts.
Stack Overflow’s 2025 Developer Survey showed Docker reaching 71.1% adoption among professional developers, a 17-point jump in a single year. That makes volume storage one of the most frequently encountered persistence questions in software development today.
One thing that trips people up. Volumes and Docker images are stored in different subdirectories, even though they both live under the same root. Volumes hold your persistent application data. Images hold your read-only filesystem layers. Mixing these up leads to accidental deletions.
Where Docker Volumes Are Stored on Linux
On Linux, the default storage path for Docker volumes is /var/lib/docker/volumes/.
Every named volume gets its own subdirectory. Inside each subdirectory, there’s a data folder holding the actual files. So a volume called mydatabase lives at /var/lib/docker/volumes/mydatabase/data.
Anonymous volumes follow the same parent path but use a random SHA256 hash as the directory name instead of a human-readable label. You’ll see something like /var/lib/docker/volumes/8f1a3b9c.../data with no indication of which container created it.
Quick way to verify the exact mountpoint for any volume:
“ docker volume inspect mydatabase `
That returns a JSON block with the Mountpoint field showing the full path. Docker's official documentation confirms this as the standard inspection method.
File Ownership and Permissions
Files inside /var/lib/docker/volumes/ are owned by root by default. This catches people off guard when they try to read volume data from non-root user accounts.
The permissions inside the data folder depend on what the container wrote. If your containerized app runs as UID 1000, the files will reflect that ownership. But the volume directory itself stays root-owned.
Linux powers 75% of all Docker container deployments, according to Command Linux’s 2024 container adoption data. That makes the /var/lib/docker/volumes/ path the single most common volume storage location across all platforms.
Confirming the Docker Root Directory
Run docker system info and look for the Docker Root Dir field. If nobody changed the daemon configuration, it reads /var/lib/docker.
If someone modified the data-root setting in daemon.json, volumes will be under that custom path instead. I've seen teams waste hours looking in the default location when someone on the ops side had quietly moved the root to a bigger partition months ago.
Docker Volume Storage on macOS and Windows
Here’s where it gets tricky. On macOS and Windows, Docker Desktop runs containers inside a lightweight Linux virtual machine. Volumes live inside that VM, not directly on the host filesystem.
So when you run docker volume inspect and see /var/lib/docker/volumes/myvol/data, that path exists inside the VM. Browsing to /var/lib/ in Finder or Explorer gives you nothing. The directory doesn't exist on the host.
This confuses a lot of developers. The Docker community forums have dozens of threads from people who can’t find their volumes after following Linux-based tutorials.
macOS Volume Location
Disk image path: ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
Docker Desktop for Mac stores everything (images, containers, volumes) inside a single disk image file. You can see the location and size under Docker Desktop Settings, then Resources, then Advanced.
The default VM disk limit on Docker for Mac is 64 GB. That’s shared across all images, containers, and volumes. Projects with heavy database volumes can bump into this ceiling fast.
Windows Volume Location
Windows has two different backends, and each stores volumes differently:
| Backend | Volume Location | Notes |
|---|---|---|
| WSL 2 | Inside the WSL 2 distribution’s virtual disk | Better performance, recommended setup |
| Hyper-V | C:\ProgramData\docker\volumes | Legacy approach, slower I/O |
| Windows containers | C:\ProgramData\docker\volumes | Only for native Windows containers |
With WSL 2 (the default since Docker Desktop 4.x), the volumes sit inside a .vhdx file managed by the Linux distribution. You can't just browse to them in File Explorer.
Accessing Docker Volumes Inside the Docker Desktop VM
The most reliable method is to run a temporary container that mounts the volume:
` docker run --rm -v myvolume:/data -v $(pwd):/backup alpine cp -r /data /backup `
That copies everything from the volume into your current directory. A bit clunky, but it works on both macOS and Windows without touching VM internals.
For direct VM access on macOS, the nsenter approach still works:
` docker run --rm -it --privileged --pid host debian nsenter -t 1 -m -u -n -i sh `
This drops you into the VM’s filesystem where you can browse /var/lib/docker/volumes/ directly. Took me a while to discover that one. Most tutorials skip it.
Docker’s 2025 State of App Dev report found that 64% of developers now use non-local environments as their primary setup, up from 36% in 2024. But a significant number still run Docker Desktop locally, which makes understanding VM-based volume storage a daily concern for back-end development teams.
How Docker Selects the Storage Location
Docker doesn’t randomly pick where to put your data. The storage location follows a clear chain of configuration decisions.
The data-root setting in /etc/docker/daemon.json controls the root directory for all Docker data, including volumes. Change this, and everything moves: images, containers, build cache, and volumes. The default is /var/lib/docker.
The Storage Driver’s Role
overlay2 is the default storage driver on most modern Linux distributions. It handles the layered filesystem for images and containers. But here’s what a lot of people miss: the storage driver doesn’t directly affect where volumes are stored.
Volumes always go under /volumes/ regardless of whether you're running overlay2, btrfs, or zfs as your storage driver. The driver affects image layer storage and container writable layers, not named volumes.
That said, your choice of storage driver does affect overall disk usage. And when you run docker system df, the breakdown shows images, containers, and volumes separately. They all share the same underlying partition unless you've configured configuration management to separate them.
Custom Volume Drivers
The local driver is the default. It stores volume data on the host filesystem. But Docker supports third-party volume plugins that change where data actually ends up.
- NFS driver: stores data on a network file share
- Amazon EBS: attaches cloud block storage
- Azure Disk: integrates with Azure’s managed disks
When you use a non-local driver, the Mountpoint from docker volume inspect might not correspond to a real path on your host. The driver manages the mapping internally.
The container infrastructure software market nearly doubled from $465.8 million in 2020 to $944 million in 2024, according to Gartner. That growth drives demand for more flexible storage solutions beyond the default local driver, especially in production environments running distributed workloads.
Inspecting a Docker Volume’s Path
Four commands give you everything you need to find where a specific volume lives on disk.
docker volume inspect <volumename> is the most direct. It returns JSON with the Mountpoint field showing the exact filesystem path, plus the driver, labels, and scope.
` $ docker volume inspect my-vol [ { "Driver": "local", "Labels": {}, "Mountpoint": "/var/lib/docker/volumes/my-vol/data", "Name": "my-vol", "Options": {}, "Scope": "local" } ] `
docker volume ls lists every volume on the host with its driver name. Good for spotting anonymous volumes (the ones with long hash names) that pile up over time.
docker system info confirms the Docker Root Dir. If volumes aren’t where you expect, check this first.
cat /etc/docker/daemon.json shows any custom data-root configuration. If this file doesn't exist or doesn't contain a data-root key, Docker uses the default path.
Developers who face planning challenges (31% according to Docker’s 2024 Trends Report) often don’t realize that volume inspection is part of debugging storage issues. Running these four commands takes under a minute and tells you exactly what’s going on.
One thing worth noting. If you’re using Docker Compose, volumes get prefixed with the project name. A volume defined as dbdata in a project called myapp shows up as myappdbdata in docker volume ls. That prefix trips people up when they're searching for volumes by name.
Named Volumes vs Anonymous Volumes vs Bind Mounts
These three terms get used interchangeably in casual conversation, but they work differently and store data in different places.
| Type | Storage Path | Created By | Lifecycle |
|---|---|---|---|
| Named volume | /var/lib/docker/volumes//_data | Explicit docker volume create or Compose file | Persists until manually removed |
| Anonymous volume | /var/lib/docker/volumes//_data | Automatically when no name is given | Orphaned easily after container removal |
| Bind mount | Any host path you specify | The -v or --mount flag at runtime | Depends on host filesystem |
Named Volumes
You give them a name. Docker stores them at /var/lib/docker/volumes//data. They survive container removal and can be shared between multiple containers simultaneously.
For most database use cases (MySQL, PostgreSQL, MongoDB), named volumes are what you want. Docker’s documentation explicitly recommends them as the preferred persistence mechanism.
Anonymous Volumes
Same parent directory, but the name is an auto-generated hash like 8f1a3b9c4e…. Docker creates these when a Dockerfile has a VOLUME instruction or when you mount without specifying a name.
The problem? They pile up. Containers get removed, but their anonymous volumes stay behind. I’ve seen dev machines with 40+ orphaned anonymous volumes consuming gigabytes of disk space. docker volume prune clears them out, but you have to remember to run it.
Bind Mounts
Bind mounts aren’t managed by Docker at all. They point to whatever host directory you specify. The data lives wherever you tell it to, not under /var/lib/docker/.
Good for local development where you want live code reloading. Bad for production because they create tight coupling between the container and the host filesystem. Your codebase stays accessible on the host for quick edits, but portability suffers.
With container usage hitting 92% in the IT industry according to Docker’s 2025 report (up from 80% in 2024), understanding which volume type fits your app deployment strategy is no longer optional knowledge. It’s baseline.
Changing the Default Docker Volume Storage Location
The default partition fills up. That’s the main reason people move Docker’s data root to a different disk. If /var sits on a 50 GB partition and you're running a dozen containers with database volumes, you'll hit the ceiling fast.
The fix is editing /etc/docker/daemon.json to set a new data-root path:
` { "data-root": "/mnt/docker-data" } `
Stop Docker first with systemctl stop docker, move the existing data, update the config, then restart. Skip any of these steps and you'll either lose data or end up with two copies eating disk space.
Symlinks work as a quick alternative. Point /var/lib/docker to a bigger partition without touching daemon.json. But this approach gets messy during Docker upgrades, so the data-root method is cleaner for long-term use.
Gartner estimates that over 95% of new digital workloads deploy on cloud-native (mostly containerized) platforms as of 2025, up from 30% in 2021. With that level of container density, running out of volume storage is a “when” problem, not an “if” problem.
Moving Volumes to an External or Network Drive
The local volume driver supports NFS, CIFS, and direct device mounts through mount options. You don't need a third-party plugin for basic network storage.
Creating an NFS-backed volume:
` docker volume create --driver local --opt type=nfs --opt o=addr=192.168.1.100,rw,nfsvers=4.1 --opt device=:/exports/app-data nfs-app-volume `
When you inspect this volume, the Mountpoint still shows a path under /var/lib/docker/volumes/, but the actual data lives on the NFS server. Docker handles the mount transparently.
Performance tradeoff: NFS adds network latency. Fine for shared config files and static assets. Bad for write-heavy database workloads. If your MySQL container starts throwing timeout errors after switching to NFS volumes, that’s why.
Spotify famously ran into storage challenges when scaling their microservices architecture across thousands of containers, eventually moving to cloud-managed storage solutions for their most demanding workloads.
Managing Docker Volume Storage and Disk Usage
Volumes are the sneakiest disk space consumers in Docker. Images get attention because they’re big and visible. But volumes quietly accumulate in the background, especially anonymous ones that outlive their containers.
docker system df gives you the full picture in one command:
` TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 15 5 4.2GB 2.8GB (66%) Containers 8 3 120MB 85MB (70%) Local Volumes 23 6 8.5GB 6.1GB (71%) Build Cache 0 0 0B 0B `
That 71% reclaimable on volumes is typical. Most of it comes from orphaned anonymous volumes that nobody remembers creating.
Cleanup Commands
| Command | What It Removes | Risk Level |
|---|---|---|
| docker volume prune | Unused volumes only | Low (safe for most setups) |
| docker system prune | Containers, images, networks | Medium (does NOT touch volumes) |
| docker system prune –volumes | Everything including volumes | High (can delete persistent data) |
The critical detail that catches people: docker system prune does not remove volumes by default. You need the –volumes flag. Docker made this a deliberate design choice because volume data is often irreplaceable.
Spotting Orphaned Volumes
Run docker volume ls -f dangling=true to list volumes not attached to any container. The output is usually a wall of SHA256 hashes (anonymous volumes) mixed with a few named ones.
Red Hat’s 2024 State of Kubernetes Security report found that two-thirds of organizations delayed container deployment due to security concerns. Part of that includes data management risks from unmonitored volume growth. Stale volumes with outdated database snapshots can become a liability.
A good habit: schedule docker volume prune -f as a cron job on development machines. On production servers, review the list manually before deleting anything. One wrong prune and your database is gone. Setting up proper DevOps practices around container storage prevents those kinds of incidents.
Docker Volume Storage in Container Orchestration
Single-host Docker volumes are simple. Multi-host orchestration is where storage gets complicated.
Docker Compose and Named Volumes
Compose prefixes volume names with the project name. A volume called dbdata in a project directory named myapp becomes myappdbdata on disk.
The volumes still land in /var/lib/docker/volumes/ on the same host. Compose doesn't change the storage location, just the naming convention. If you're managing a software development process with multiple team members running the same Compose file, each developer ends up with their own local copy of every volume.
Docker Swarm Volume Behavior
Key limitation: volumes in Docker Swarm are local to each node. When a service gets rescheduled to a different node, the volume data doesn’t follow.
That’s a dealbreaker for stateful services like databases. The workarounds are using a shared storage driver (NFS, GlusterFS) or constraining the service to a specific node. Neither is ideal.
Docker Swarm’s share of the orchestration market has declined significantly. Kubernetes vs Docker comparisons consistently show Kubernetes winning for production workloads, and storage flexibility is a big reason why.
Kubernetes Persistent Volumes
Kubernetes takes a completely different approach. Instead of mapping directly to host paths, it abstracts storage into two objects:
- PersistentVolume (PV): the actual storage resource, provisioned by an admin or dynamically by a StorageClass
- PersistentVolumeClaim (PVC): a pod’s request for storage with specific size and access requirements
The CNCF’s 2024 Annual Survey documented 80% of organizations deploying Kubernetes in production, up from 66% in 2023. Kubernetes holds roughly 92% of the container orchestration market, according to Edge Delta’s adoption analysis.
Cloud-managed storage backends like Amazon EBS, Google Persistent Disk, and Azure Disk Storage handle the physical location of volume data. The Container Storage Interface (CSI) standard lets any cloud provider or storage vendor plug into Kubernetes without custom code.
Where does the actual data end up? That depends entirely on the CSI driver and storage backend. Could be a network-attached block device, a cloud disk in another availability zone, or an NFS share. The pod never knows or cares. That level of abstraction is what Docker volumes lack on their own, and it’s why teams running stateful workloads at scale tend to move toward Kubernetes and its containerization model.
Backing Up and Restoring Docker Volumes
Knowing where volumes are stored is only half the puzzle. The other half is protecting that data.
Docker doesn’t include built-in backup commands for volumes. You handle it yourself, either with tar archives, docker cp, or third-party tools.
Tar-Based Backup Using a Temporary Container
This is the standard method recommended across Docker’s own documentation and community guides:
` docker run --rm -v mydatabase:/source:ro -v $(pwd)/backups:/backup alpine tar czf /backup/mydatabase-backup.tar.gz -C /source . `
What this does: spins up a throwaway Alpine container, mounts the volume as read-only, creates a compressed archive, and exits. The backup file lands in your current directory.
One gotcha that most tutorials get wrong (and a detailed analysis on Augmented Mind confirms this): the directory structure inside the tar archive depends on where you run the tar command from. Use -C /source . to keep paths relative. Skip the -C flag and your restore will create nested directories like source/var/lib/mysql/ instead of the clean data you expected.
Restoring from a Backup
` docker run --rm -v mydatabase:/target -v $(pwd)/backups:/backup alpine sh -c "cd /target && tar xzf /backup/mydatabase-backup.tar.gz" `
Stop the container using the volume before restoring. Writing to a volume while a database is actively reading from it is a recipe for corruption.
Direct Filesystem Copy
On Linux, you can copy files directly from /var/lib/docker/volumes//data/ to another location. It works, but only when:
- No container is actively writing to the volume
- You’re on the host machine (not inside a VM like Docker Desktop)
- You have root access
For database volumes (MySQL, PostgreSQL, MongoDB), always prefer the database’s own backup tool, like pgdump or mysqldump, over raw filesystem copies. These tools handle write consistency. A raw copy during an active transaction can produce a corrupted backup.
Third-Party Backup Tools
docker-vackup (by Bret Fisher) is probably the most well-known. It exports and imports volumes as tarballs or container images. The functionality was later integrated into Docker Desktop’s Volumes tab starting with version 4.29.
loomchild/volume-backup is another popular option on GitHub. It handles compression, exclusion patterns, and remote transfers via SSH piping.
Volumerize wraps Duplicity for scheduled backups with support for multiple cloud backends (S3, Google Cloud Storage, Azure Blob).
According to Contrary Research, Docker processes over 25 billion image pulls per month as of 2024, with 17 million developers on the platform. With that scale of usage, volume backup is a critical part of any continuous deployment workflow. Losing a production database volume because nobody set up backups is the kind of mistake you only make once.
Teams running critical workloads should document their backup process alongside their software documentation. A backup strategy that only exists in one person’s head isn’t really a strategy.
FAQ on Where Are Docker Volumes Stored
What is the default storage path for Docker volumes on Linux?
Docker stores volumes at /var/lib/docker/volumes/ by default. Each named volume gets a subdirectory with a data folder inside. Anonymous volumes use a random hash as the directory name instead of a readable label.
Where are Docker volumes stored on macOS?
Docker Desktop for Mac runs containers inside a lightweight Linux VM. Volumes exist inside that VM’s filesystem, not on your Mac directly. The VM’s disk image sits at ~/Library/Containers/com.docker.docker/Data/vms/0/data/.
Where are Docker volumes stored on Windows with WSL 2?
With the WSL 2 backend, volumes live inside the Linux distribution’s virtual disk file (.vhdx). You can’t browse to them in File Explorer. Use docker volume inspect or a temporary container to access the data.
How do I find the exact path of a specific Docker volume?
Run docker volume inspect <volumename> and check the Mountpoint field in the JSON output. This shows the full filesystem path. On Docker Desktop, that path refers to a location inside the VM, not the host.
What is the difference between a named volume and an anonymous volume?
Named volumes have a user-assigned label and persist until you delete them manually. Anonymous volumes get a random hash name and are created automatically when no name is specified. Both are stored under the same parent directory.
Can I change where Docker stores volumes?
Yes. Edit /etc/docker/daemon.json and set a new data-root path. Stop Docker, move existing data to the new location, then restart. This moves all Docker data, including images and build cache, not just volumes.
How do I check how much disk space Docker volumes are using?
Run docker system df for a quick summary of space used by images, containers, and volumes. Add -v for a detailed breakdown showing each volume's individual size. This helps identify which volumes consume the most storage.
How do I delete unused Docker volumes?
Use docker volume prune to remove all volumes not currently mounted to a container. The standard docker system prune does not touch volumes unless you add the –volumes flag. Always verify before pruning on production servers.
Can Docker volumes be stored on an NFS share?
Yes. Create a volume with the local driver using NFS mount options: –opt type=nfs with the server address and export path. Docker mounts the NFS share transparently when a container uses that volume.
How do I back up a Docker volume?
Mount the volume into a temporary Alpine container and create a tar archive. Use :ro (read-only) on the source mount for consistency. For database volumes, prefer tools like pgdump or mysqldump over raw filesystem copies.
Conclusion
Understanding where Docker volumes are stored comes down to knowing your operating system and daemon configuration. On Linux, /var/lib/docker/volumes/ is the default storage location. On macOS and Windows, everything sits inside a VM managed by Docker Desktop.
The practical takeaway: use docker volume inspect to find exact paths, run docker system df to monitor disk usage, and set up a backup routine before you actually need one.
Whether you’re running a single Docker setup on a dev machine or managing persistent storage across a Kubernetes cluster with CSI drivers, volume management is a core skill. Customize your data-root`, prune orphaned volumes regularly, and keep your build pipeline clean.
Get the storage layer right and everything else runs smoother.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, Speckyboy, and Slider Revolution among others.
