Argthtjtr

I originally asked this on Stack Overflow, but I thought Super User might be more appropriate.

I have the strangest situation using Docker on WSL (Windows Subsystem for Linux, Ubuntu 16.04). I'm trying to bind mount /home/username (or just $HOME for convenience) as a volume in a container, and instead of finding the content of my home directory in the container, I get some other volume entirely.

What's stranger is that this 'other volume' persists from one container to the other whenever I try to bind mount $HOME or /home/username. If I touch a new file, it appears in all other containers I mount $HOME into. All other bind mounts to any other directory work correctly.

E.g. these all share the same mystery folder:

docker run -it --rm -v /home/username:/test alpine sh

docker run -it --rm -v $HOME:/test alpine sh

docker run -it --rm -v $HOME:/test -v $HOME:/test2 alpine sh

When I do a docker volume ls there's no volume called /home/username, so that rules out accidentally having a docker-hosted volume with the same name.

What is this mysterious volume I'm mounting, and why is docker not mounting my $HOME directory correctly?

Where is the Docker daemon running? I'm guessing it's running on a server somewhere or if you're using Docker for Windows (with Windows containers/LCOW), it's running on the host outside WSL. The bind mount is likely looking for "/home/username" on the host instead of inside the WSL environment where the Docker client is running. Based on your comment about /c and /d working, it sounds like these are getting mapped back to C: and D: drives on the host which suggests you're using Docker for Windows

From inside WSL, it looks like drives are mounted inside WSL but the rootfs lives on a virtual file system which would explain why /c and /d are working

nick@nick-desktop:/mnt$ mount

rootfs on / type lxfs (rw,noatime)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)

proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)

none on /dev type tmpfs (rw,noatime,mode=755)

devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,gid=5,mode=620)

none on /run type tmpfs (rw,nosuid,noexec,noatime,mode=755)

none on /run/lock type tmpfs (rw,nosuid,nodev,noexec,noatime)

none on /run/shm type tmpfs (rw,nosuid,nodev,noatime)

none on /run/user type tmpfs (rw,nosuid,nodev,noexec,noatime,mode=755)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noatime)

C: on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000)

W: on /mnt/w type drvfs (rw,noatime,uid=1000,gid=1000)

X: on /mnt/x type drvfs (rw,noatime,uid=1000,gid=1000)

Z: on /mnt/z type drvfs (rw,noatime,uid=1000,gid=1000)

Here is some documentation that talks about how the Linux rootfs in WSL works https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

The location in Windows WSL rootfs lives inside of is listed in KCU:SoftwareMicrosoftWindowsCurrentVersionLxss (see https://github.com/Microsoft/WSL/issues/2578)

Here is some additional information on Docker architecture explaining the difference between Docker daemon and client https://docs.docker.com/engine/docker-overview/

There's no good way to do this, as the docker daemon within the MobyLinuxVM has no knowledge of WSL, and vice versa.

If you try to mount the AppData folder containing the WSL files as a volume, you'll run into problems because you are writing files without creating the appropriate linux filesystem metadata:

https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/

Probably the better thing to do is to create a folder elsewhere on your C: drive, which you can access from WSL under /mnt/c, and can be mounted from docker using -v "C:foldername":/test. For convenience, you can bind mount /mnt/c to /c within WSL so you can write the docker command using -v /c/foldername:/test.

sudo mkdir /c
sudo mount --bind /mnt/c /c

See https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly

If you really need to mount $HOME as a docker volume, you could try setting up your WSL home folder as a folder on C: such as C:home, as described here:

https://brianketelsen.com/going-overboard-with-wsl-metadata/

You could then mount C:home as a docker volume. However, you could run into problems working within WSL, as your home folder will now be mounted as a drvfs filesystem instead of lxfs.

I was having the same issue, and I agree with Nijave that the problem is that the filesystem which the Docker Host mounts from (MobyLinuxVM running in Hyper-V in my case) is different from the filesystem managed by WSL (the location of which is buried in your user app data on the C: drive).

To solve this, I first got shell with access to the filesystem used by the Docker Host

docker run --privileged -it -v /var/run/docker.sock:/var/run/docker.sock jongallant/ubuntu-docker-client

docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/host alpine /bin/sh

chroot /host

Then, I linked my WSL home directory (using the Windows path) to the home directory on the filesystem which the Docker Host uses:

ln -s /C/Users/WINDOWS_USERNAME/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/home/LINUX_USERNAME/ /home/

After that I was able to do things like:

docker run -it --rm -v ~/.ssh:/root/.ssh alpine some-ssh-command

Note: there is a bug filed to address this in Docker Core:
https://github.com/docker/for-win/issues/2151

WARNING: you should probably only do this for read-only access to your $HOME directory. In the aforementioned bug, I was informed that this method still access the Windows filesystem through Samba, and so if you create/edit files you may run into the problems here: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/