docker volume mountpath is wrong

[ankitbko]

• [ x] I have tried with the latest version of my channel (Stable or Edge)

Expected behavior

docker volume inspect Mountpoint path should point to correct folder on host. The same incorrect path is reflected in docker GUI.

Actual behavior

Mountpoint path shown does not exist.

Information

Please, help us understand the problem. For instance:

• Is it reproducible? Yes

• Is the problem new? No

• Did the problem appear with an update? No

• Windows Version: 10.0.19041 N/A Build 19041.264

• Docker Desktop Version: 2.3.0.2 (45183)

• Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: No

Steps to reproduce the behavior

1. create a docker volume docker volume create foo
2. docker volume inspect foo. Note Mountpoint.
   
3. Open bash in wsl. sudo ls on Mountpoint from previous step. The path does not exist.
   
4. Wsl #4176 (comment) has the correct path on host where volume is stored. sudo ls /mnt/wsl/docker-desktop-data/data/docker/volumes
   

[simonferquel]

This is by design: inspect returns internal object states, and from the daemon perspective, the mountpoint is correct.
Think of it as with working with an remote daemon: named volumes mountpoints refer to a place within the remote machine filesystem. This is the same thing here.
However with WSL2, the /var/lib directory of the docker daemon mount namespace is also bind mounted in /mnt/wsl (this is because we rely on cross-distro mounts for achieving this with maximum performance). It is a side effect of our wsl2 implementation, and it should not be relied on - there is no guarantee we'll use the same trick forever.

[ankitbko]

Is there no way to show the actual path on the host? Surely at some point it must resolve to the actual path on host system. It is really confusing as the bind type mounts show correct Source and the volume type doesn't.

So the daemon sees the mount point as /var/lib and its dynamically resolved into /mnt/wsl/docker-desktop-data when mounting but from with wsl2 terminal I cannot resolve the same?

[simonferquel]

There is no way, and no, it does not have to. It is docker daemon that creates the undelying directory and mount things from there, always from the same mount namespace.

[ankitbko]

That is unfortunate. I am not sure if it is documented anywhere, if not then we should. I have seen similar question on SO without answer before I stumbled upon the other issue in WSL repo.

[thaJeztah]

Named volumes are not designed to be accessed directly (although you can define a named volume with a custom storage path on the host).

If you want to use a path on your host to be shared between a container and the host, you could use a bind-mount (-v <path on host>:<path in container>)

[ankitbko]

@thaJeztah Ya well this performance improvement is the reason I had to use it.

In the scenario like this where I have to mount the entire code base in volume-mount, it is really helpful to be able to traverse it through host machine. Just opening windows explorer over there is super useful.

Well the issue was that for a novice like me when I see Mountpoint for bind is a real physical location on host , I assumed same would be applicable for volume type. It really threw me off when it was not so. Couldn't find it where it is documented also.

BTW how can I define named volume with custom path on the host?

[thaJeztah]

Ya well this performance improvement is the reason I had to use it.

If you're running with WSL2, I think bind-mounting from the WSL2 Linux filesystem should not have that overhead (docker/docs#10801). I'm not on Windows myself, but worth trying as well

BTW how can I define named volume with custom path on the host?

There's some details in these threads; moby/moby#36974 (comment), moby/moby#19990 (comment), and some "under the hood" description docker/compose#2957 (comment)

The TL;DR to create a volume but (using the mount options that are passed to linux when creating the volume)

docker volume create --opt type=none --opt device=/some/host/path --opt o=bind myvolume

[ankitbko]

Although I haven't tried but its likely WSL2 filesystem would work with bind nicely.
Buuut some of my colleagues are on Mac and they would still have problem as per the article :) Then I will have to maintain multiple devcontainer environments for different system (which is what devcontainers tries to solve in first place)

[thaJeztah]

Depending on the project, the mutagen based file caching may help https://docs.docker.com/docker-for-mac/mutagen-caching/

[ankitbko]

@thaJeztah thanks for that. It would be useful in some of the projects we have. Currently I have a java project (and I am not a java dev), is there a way to exclude the target folders from syncing back to the host? Maybe something like glob pattern to exclude folders from mutagen cache?

[ankitbko]

@thaJeztah I can confirm bind mounting WSL 2 filesystem gives much better performance than windows filesystem.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked