Docker client on WSL creates volume path problems

Question

Windows 10 build 15063.11, running Windows Subsystem for Linux (WSL) Xenial 16.04.2 LTS.

There's a docker client running in WSL connecting to the Windows Hyper-V daemon. Fun.

The one issue I can't get rid of is the path mapping between WSL and the Hyper-V daemon for volumes - from compose files. Compose files are supposed to be cross platform - they're all relative, and if I start just changing the compose.yml just to suit my WSL monstrosity, the services won't start anywhere else properly, which isn't entirely practical.

Is there something like export MSYS_NO_PATHCONV=1 that I can do to make WSL stop mutilating the paths before they're sent to the daemon?

Where does this problem need to be solved? In the daemon? In compose? in WSL? where can I contribute?

Volume mappings outside of compose files work wonderfully because you can specify them absolutely, and in the proper format when you pass them to the client/daemon.

e.g., docker run -v c:/my/stuff/is/here:/vars/now/here magicImage from within WSL works fantastic. It's just compose is getting absolute file names from WSL that are not actually file names e.g., /mnt/c/my/stuff/isnt/here because in the daemon's Hyper-V universe, /mnt/c/ is nonsense.

follow-up: reached out to docker/compose. docker-compose calls os.path.abspath to resolve the absolute paths of the resources, so it seems likely that the issue is more likely in using Microsoft / BashOnWindows.

Answer 1

I think the answer is already in the Docker-compose and incorrect absolute paths for volumes · Issue #1854 · Microsoft/BashOnWindows thread on GitHub, but I’m posting here for others to see:

There are two potential workarounds: symlinks and bind mounting. They both work, but a bind is probably better since some services do not use symlinks.

aseering provides the commands in a comment on the GitHub thread.

$ sudo mkdir /c
$ sudo mount --bind /mnt/c /c
$ cd /c/path/to/project
$ docker-compose ...

The only downside to a bind is that it lasts only as long as the instance (in this case the container) because of the way we initialize containers.  So, binding would need to be a part of the container start routine.