I just got the update to Docker Desktop for windows and am seeing a mount regression. This is on version 126.96.36.199 of docker desktop and engine 19.03.8.
I’m running a docker container and installing docker (client) inside of it to start sibling containers via a shared docker sock. However, the mounts inside the started sibling container are not mounting quite like I’d expect. The results in Docker Desktop 188.8.131.52 are working as I’d expect (and like).
If I run
docker run -it -v /c/work:/root/work -v /var/run/docker.sock:/var/run/docker.sock debian bash
In that container run
$ ls /root/work (content of my C:\work dir in windows ... yay) $ apt-get update && apt-get install -y curl && curl -fsSL https://get.docker.com -o get-docker.sh && sh get-docker.sh $ docker run -it -v /c/work:/root/work -v /var/run/docker.sock:/var/run/docker.sock debian bash ("inner"/sibling docker container)
Then in the sibling/container docker container
ls /root/work is blank. Is this a bug? I think so – I’d expect the docker command line mounts from inside to work exactly like the outside (understanding that mounts are always written in terms of the host machine).
So my work-around is to insert “/host_mnt” before the /c
docker run -it -v /host_mnt/c/work:/root/work -v /var/run/docker.sock:/var/run/docker.sock debian bash
This works, but it seems fragile because “host_mnt” is an undocumented (?) detail? I hope to not enshrine a fragile bit in my mounting logic.