On a Linux host, Docker volumes sit under /var/lib/docker/volumes. That path comes from the daemon’s data root, which an admin can move but rarely has a reason to.
Docker Engine 29.0 and later switches fresh installations to the containerd image store by default for handling image and container layers, according to Docker’s own engine documentation. Named and anonymous volumes still land under the same local driver path regardless of that backend. Installations upgraded from an earlier version keep using the classic overlay2 driver until the containerd image store is enabled manually.
What Is a Docker Volume
Docker creates and manages volumes itself, on the host, separate from the filesystem of any one container.
Docker picks the folder. Nobody types a host path when a named volume gets created, and that one detail is what separates a volume from a bind mount.
Containers are meant to be thrown away, which is the whole reason volumes exist. Sysdig’s 2023 Cloud-Native Security and Usage Report found that 72% of containers live less than five minutes. Anything written straight into a short-lived container’s writable layer disappears with that container.
A volume outlives the container attached to it. Docker tracks its location in its own metadata, so you don’t have to remember a path, and several containers can read and write the same data at the same time.
It isn’t the container itself, though. The running instance, which the breakdown of how a Docker container behaves once it starts covers, is a separate object that attaches to the volume at a mount path.
Docker was ranked the most used tool among professional developers in the 2024 Stack Overflow Developer Survey, at 59% adoption. So the way it handles persistent data touches a huge number of running production systems.
Volumes are only one of the storage options Docker offers. Bind mounts and tmpfs mounts solve related problems differently, and there’s a section on them further down.
Where Are Docker Volumes Stored by Default on Linux
/var/lib/docker/volumes, unless someone changed the daemon’s configuration.
Every volume gets its own subdirectory there, named after the volume. Inside it sits a folder called \_data, and that’s where the files actually live.
The parent location is the Docker data root. It holds a lot more than volumes: network configuration, plugin data, and (on installs still using the classic overlay2 driver) the image and container layers. The guide on how a Docker image differs from a running container describes those as the read-only layers a container starts from.
Docker Engine 29.0 and later switched fresh installs to the containerd image store instead of overlay2, according to Docker’s own documentation. On those installs, containerd manages image layers and keeps them under its own storage root (by default /var/lib/containerd), not inside the Docker data root.
Volumes aren’t affected by that change. The local volume driver still writes named volumes to /var/lib/docker/volumes no matter which backend handles images underneath.
The default location is /var/lib/docker/volumes, and each volume’s data sits in /var/lib/docker/volumes/[name]/\_data (both per Docker official documentation). The data-root key inside daemon.json controls the whole thing, also per Docker official documentation. Image handling depends on the install: fresh Docker Engine 29.0+ installs use the containerd image store with the overlayfs snapshotter, while older or upgraded installs stay on overlay2, the classic default across Ubuntu, Debian, Fedora, and RHEL.
The directory is owned by root. On most distributions, permissions stop a standard user account from even listing what’s inside, so don’t expect to browse it casually.
How Do You Find the Exact Storage Path of a Volume
Run docker volume inspect against the volume’s name.
Guessing the path from memory is a bad habit. A changed data-root setting or a custom volume driver can put it somewhere else entirely.
- Run docker volume ls to see every volume Docker currently knows about
- Pick the name of the one you need from that list
- Run docker volume inspect followed by that name
- Read the Mountpoint field in the output, which gives the full path on the host
The output also shows the driver, usually local, plus any labels attached to the volume.
If you forget a flag, the Docker command reference is worth keeping open the first few times you do this by hand.
People skip inspect and poke around the filesystem directly all the time. Don’t. Editing files inside \_data from outside Docker can leave the daemon’s internal state out of sync with what’s on disk, and that’s a painful thing to diagnose later.
How Do Named Volumes and Anonymous Volumes Differ in Storage
Both end up under the same parent directory. They just get there differently.
| Type | How it is created | Folder name used |
|---|---|---|
| Named volume | docker volume create, or a name given in a run or compose command | The exact name you chose |
| Anonymous volume | A Dockerfile VOLUME instruction, or a mount with no name specified | A generated hash-style ID |
Named Volumes
You get a folder you can recognize on sight, so a named volume is the sensible pick for anything you plan to back up or reattach later. It’s easy to find with docker volume ls or a quick inspect, it survives container removal, and a new container can pick it up by name. It also fits neatly into a Compose file that declares services and shared volumes together.
The only real downside is that somebody has to name it on purpose, which is one extra step compared to letting Docker generate something.
Anonymous Volumes
These mostly happen by accident.
A Dockerfile with a VOLUME instruction, or a run command that mounts a path without naming the source, creates one automatically under a hash-style folder name. That name tells you nothing at a glance.
- They get left behind once the container is removed, unless the removal command included the volumes flag
- They’re the most common source of orphaned storage on a machine that has run a lot of short-lived containers
Official images for databases like Postgres and Redis often declare a VOLUME instruction internally. That’s why a quick docker volume ls on a development machine tends to turn up several anonymous entries nobody remembers creating.
How Does Volume Storage Differ From Bind Mounts and Tmpfs
All of them attach storage to a container, but each answers a different question about where that storage should live.
| Storage type | Location | Managed by | Typical use case |
|---|---|---|---|
| Volume | Docker data root, path chosen by Docker | Docker | Databases, application state that must survive restarts |
| Bind mount | Any host path the user specifies | The user | Source code during local development, config files |
| Tmpfs mount | Host memory, not disk | Docker, backed by RAM | Secrets and temporary caches that should never touch disk |
A bind mount points at a folder you already know on the host, which is why it shows up so often in local development. Editing a source file on the host and watching the change appear inside a running container works cleanly with a bind mount and not with a volume.
Tmpfs trades persistence for speed. The data sits in RAM and vanishes the moment the container stops. Fine for a session token or a build cache, wrong for anything that has to outlive a restart.
A team running a database in a real production environment almost always reaches for a named volume over a bind mount. Docker managing the storage location makes it less likely that a stray host path breaks a deployment.
Where Are Docker Volumes Stored on Windows and macOS
The path is the same, /var/lib/docker/volumes. It just exists inside a Linux virtual machine instead of on the host filesystem.
Windows (WSL2)
In most modern setups, Docker Desktop on Windows runs its Linux side inside a WSL2 distribution rather than a full separate hypervisor VM.
So /var/lib/docker/volumes lives inside that WSL2 distro, not under C:\. It won’t show up in a normal Explorer folder view, but you can reach it by typing a \\wsl$ or \\wsl.localhost network path into the File Explorer address bar (the exact path depends on your Docker Desktop version). A WSL terminal works too, as does Docker Desktop’s own Volumes view or a privileged container that mounts the host’s Docker directory.
Windows still leads developer machines by a wide margin, with 59.2% personal use recorded in the 2024 Stack Overflow Developer Survey, which explains why this confusion fills so many support threads.
Docker’s own WSL guidance recommends keeping project files inside the Linux filesystem rather than the Windows one, since crossing between the two sides slows file access noticeably.
macOS (Docker Desktop VM)
macOS never runs containers natively. Docker Desktop starts a lightweight virtual machine, historically built on LinuxKit, to host the daemon and its storage.
There’s no WSL equivalent here, so that VM is the only place the path exists. The volume data sits inside a virtual disk image tied to the com.docker.docker application data folder. Reaching the files directly usually means a privileged container using nsenter, or Docker’s own diagnostic tools. Finder can’t help, since it never sees the VM’s internal filesystem.
The explainer on what a virtual machine actually is covers why this setup exists at all. Docker needs a Linux kernel underneath it, and neither Windows nor macOS ships one on its own.
How Do You Change the Docker Data Root Location
Edit the data-root key inside daemon.json and restart the Docker daemon.
Running out of space on the drive that holds /var/lib/docker is the usual reason. A CI server pulling large images over and over will fill its system drive eventually. So will a workstation with a small boot SSD sitting next to a much bigger secondary disk, and some servers simply have a storage policy that puts container data on a specific mounted volume.
The daemon reads daemon.json only at startup, so it has to be restarted for the change to take effect. If you’ve followed the steps in the guide on how the Docker daemon actually starts up, this is the same restart you’d do after most daemon-level configuration changes.
The mistake that trips people up most is moving the setting without moving the data.
Docker doesn’t copy old images, containers, or volumes to the new location. A naive edit followed by a restart can make existing volumes look like they vanished, when they’re sitting untouched at the old path.
On a fresh Docker Engine 29.0+ install that uses the containerd image store, data-root moves volumes but not image layers, because containerd keeps those under its own root. If the goal is to free up the system drive, containerd’s storage location needs to be redirected as well.
How Do You Move Existing Docker Volumes to Another Disk
Copy the data to the new location, then point Docker at the copy. Relocating the folder by hand doesn’t work.
The CNCF 2024 Annual Survey found that 74% of organizations already use containers to manage stateful applications, and those are exactly the workloads that can’t tolerate a careless storage move.
- Stop every container currently using the volume
- Start a temporary container that mounts both the old volume and the new target location
- Copy the data across with a tool like tar or rsync from inside that temporary container
- Point the new container, or the updated data-root setting, at the copied files
- Verify the data before deleting anything from the original location
Skipping the stop step is the classic mistake. A database still writing to a volume mid-copy can leave behind files the application can’t cleanly recover from.
There are two situations that lead to this move. One is relocating a single named volume to faster or larger storage. The other is moving the whole data-root, which shifts every volume on the host at once.
The precaution matters just as much for one container as for a whole host. The guide on stopping a running Docker container the right way covers the same discipline before you touch anything it has mounted.
A copy can look complete in a file listing and still be missing the ownership or permission bits the original application depended on. A quick functional test beats a visual check every time.
How Do You Back Up and Restore Docker Volume Data
Copy the volume’s files somewhere outside Docker’s own storage. Docker keeps no history of a volume’s past contents.
Most organizations aren’t well set up for this. Veeam’s 2024 Data Protection Trends Report, based on 1,200 IT leaders, found that only 25% of organizations use a backup solution built specifically for containers. The rest skip container backups entirely or capture only part of the stack, and a manual volume backup procedure closes exactly that gap.
Backing Up a Volume
The standard pattern goes like this.
- Start a temporary container that mounts the target volume as read-only
- Mount a host backup folder into that same container
- Run a tar command inside the container to archive the volume’s contents into that folder
- Remove the temporary container once the archive is written
That container doesn’t need to stay running afterward. The run syntax is covered step by step in the guide on creating a new Docker container from an image.
Restoring a Volume
Restoring is the same pattern in reverse, nothing new.
A fresh or existing volume gets mounted into a temporary container next to the backup folder, and the archive is extracted back into place.
A few details decide whether the restore works. The tar command has to run from inside the source directory, otherwise paths nest under an extra folder. File ownership inside the archive needs to match what the original application expects. And restoring into a volume that already holds data overwrites files instead of merging them.
A typical WordPress Docker Compose setup pairs a database volume with a separate volume for the site files, including uploads. Both need restoring together, or the site ends up pointing at media files that no longer exist.
How Do You Clean Up Unused or Orphaned Volumes
Run docker volume prune. By default it removes unused anonymous volumes, meaning those not attached to at least one container. Unused named volumes are removed only if you add the –all flag.
Anonymous volumes are the usual target, since they pile up quietly every time a container using one gets removed without the matching cleanup flag.
| Command | What it removes | Touches volumes still in use |
|---|---|---|
| docker volume prune | Unused anonymous volumes (add –all to include unused named volumes) | No |
| docker rm -v | Anonymous volumes tied to that one container | No |
| docker system prune –volumes | Unused anonymous volumes plus stopped containers, unused networks, and dangling images | No |
None of these touch a volume that a running or stopped container still references. That’s a deliberate safety choice by Docker, not an oversight.
The buildup usually comes from containers built on images with a Dockerfile VOLUME instruction and then removed without the -v flag. CI pipelines are another source, especially ones built around DevOps practices that spin up disposable containers for every job, all day long. Development machines add to it too, where old project containers get deleted but their volumes never do.
Check usage before pruning. Run docker volume ls first and cross-check against what you still need. This matters most with –all, since that flag also deletes named volumes that no container currently references, even if you meant to reattach them later.
When Docker Volume Storage Assumptions Fail
The default path and default behavior in this article hold in the common case. Not in every case.
Persistent storage isn’t a solved problem even for teams who deal with it daily. Portworx’s Voice of Kubernetes Experts 2025 report, a Dimensional Research survey of more than 500 practitioners, found that 31% cite persistent storage as a top challenge, behind security (72%) and observability (51%).
A few things break the assumptions in practice. A changed data-root setting means /var/lib/docker/volumes is simply the wrong path on that host. A third-party volume driver can write data to a remote NFS share or a cloud block store, off the host entirely. Windows and macOS users won’t find the path in a normal folder view, since it lives inside a Linux VM. And files edited by hand inside a volume’s \_data folder can leave Docker’s internal tracking out of sync with what’s actually on disk.
Orchestration changes things too. Anyone running the same workloads through Kubernetes instead of plain Docker is working with a different storage abstraction, built around persistent volumes and the Container Storage Interface rather than one host’s local driver.
Fleets of hosts managed through infrastructure as code often bake a custom data-root path into every provisioning script. On those machines the default path isn’t the default at all.
None of this makes the default behavior wrong. It’s a starting assumption, not a guarantee, so confirm it with docker info or docker volume inspect before troubleshooting anything that assumes otherwise.
FAQ on Where Are Docker Volumes Stored
Can You Edit Files Inside a Docker Volume Directly
Technically yes, but it’s a bad habit. Editing files inside the \_data folder from outside Docker can leave the daemon’s internal tracking out of sync with what actually sits on disk. Use a container mount for changes instead.
Do Docker Volumes Require Root or Administrator Access to View
On Linux, the default data root is owned by root, so a standard user account can’t browse it without elevated permissions. On Windows and macOS, the files sit inside the Docker Desktop VM, so they aren’t directly browsable from the host in the usual way.
Does Docker Compose Store Volumes in the Same Location as Docker Run
Yes. Compose relies on the same local volume driver and the same default path on the host. The only difference is naming: Compose prefixes a project name unless the volume is declared external.
What Happens to a Volume’s Data When the Container Using It Is Removed
The data survives. A named or anonymous volume stays on disk after the container is gone. Anonymous volumes are deleted only if the container was removed with the -v flag or ran with –rm, while named volumes are never removed that way and stay until you delete them yourself.
Can Third-Party Volume Drivers Store Data Somewhere Other Than the Host Machine
Yes. A plugin-based driver can write volume data to an NFS share or a cloud block store instead of the local disk. Docker volume commands still work normally, but the Mountpoint field shows a network path.
What Should You Check First in Where Are Docker Volumes Stored?
Start with docker volume inspect. A volume’s actual location on a given host gets confirmed that way, not assumed from the default path.
Then look at the daemon’s data-root setting, since one line in daemon.json overrides everything documented as standard.
After that, find out whether the host runs through a WSL2 distribution or a Docker Desktop VM. That layer changes where the filesystem actually sits, not just how you reach it.
- Inspect the volume’s Mountpoint
- Check daemon.json for a custom data-root
- Rule out a WSL2 or VM abstraction
Roughly three in four organizations use containers for stateful applications, and nearly a third of teams name persistent storage a top challenge. Skipping that sequence is a costly shortcut, not a harmless one.
Verifying the path takes a few seconds. Guessing it can cost an afternoon, especially once a migration also touches where a Docker image’s read-only layers sit on disk.
- How to Turn On Dark Mode in Notepad++ (Built-In, No Plugin) - October 3, 2026
- PostgreSQL Cheat Sheet - October 2, 2026
- How to Repair a Corrupt SQL Server Database Without Any Data Loss - October 2, 2026
