moby: Basic volume mount fails with windows docker client against boot2docker

By default, only the "c:\users" directory is shared with the VirtualBox VM, so anything outside of that can’t be used as a volume, unless you configured VirtualBox to share other directories

On 16 Mar 2016, at 13:58, Avinash-Setty notifications@github.com wrote:

Recently I tried mounting using Docker Run command in Windows, still it doesn’t work. Can anyone help me here?

avina@avinash-laptop MINGW64 ~ $ ll /c/development/phase2/Experiments/SimpleApp/src/SimpleApp total 872 -rw-r–r-- 1 avina 197611 412 Mar 15 17:44 appsettings.json -rw-r–r-- 1 avina 197611 207 Mar 15 17:43 bower.json drwxr-xr-x 1 avina 197611 0 Mar 15 17:44 Controllers/ -rw-r–r-- 1 avina 197611 1249 Mar 15 17:43 gulpfile.js drwxr-xr-x 1 avina 197611 0 Mar 15 17:44 Migrations/ drwxr-xr-x 1 avina 197611 0 Mar 15 17:44 Models/ drwxr-xr-x 1 avina 197611 0 Mar 15 17:43 node_modules/ -rw-r–r-- 1 avina 197611 213 Mar 15 17:43 package.json -rw-r–r-- 1 avina 197611 1809 Mar 15 17:44 project.json -rw-r–r-- 1 avina 197611 840603 Mar 15 17:50 project.lock.json -rw-r–r-- 1 avina 197611 7006 Mar 15 17:43 Project_Readme.html drwxr-xr-x 1 avina 197611 0 Mar 15 17:44 Properties/ drwxr-xr-x 1 avina 197611 0 Mar 15 17:44 Services/ -rw-r–r-- 1 avina 197611 1332 Mar 15 17:43 SimpleApp.xproj -rw-r–r-- 1 avina 197611 241 Mar 15 18:05 SimpleApp.xproj.user -rw-r–r-- 1 avina 197611 3928 Mar 15 17:44 Startup.cs drwxr-xr-x 1 avina 197611 0 Mar 15 17:44 ViewModels/ drwxr-xr-x 1 avina 197611 0 Mar 15 17:44 Views/ drwxr-xr-x 1 avina 197611 0 Mar 15 17:43 wwwroot/

avina@avinash-laptop MINGW64 ~ $ docker run -v /c/development/phase2/Experiments/SimpleApp/src/SimpleApp:/SimpleApp -p 5000:5000 -it microsoft/aspnet root@112446af63af:/# cd SimpleApp/ root@112446af63af:/SimpleApp# ls -al total 4 drwxr-xr-x 2 root root 40 Mar 16 13:36 . drwxr-xr-x 60 root root 4096 Mar 16 13:36 … root@112446af63af:/SimpleApp# exit — You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub

@adeelahmadch I found Docker-compose has an option COMPOSE_CONVERT_WINDOWS_PATHS which solves this problem:

COMPOSE_CONVERT_WINDOWS_PATHS=1 docker-compose up -d

You can also set an environmental variable to disable path conversion, but note this was ONLY added in Git for Windows.

MSYS_NO_PATHCONV=1 docker run -v ...

It’s still a very hacky fix.

http://stackoverflow.com/a/34386471/1160528

---

Just like in actual Linux, G4W’s shell (called mintty) supports .bashrc files - so you can create one (touch ~/.bashrc or vim ~/.bashrc) and add export MSYS_NO_PATH=1.

After that, relaunch your bash and it’ll warn you that login scripts are missing, but have been automatically added - and never worry about this again (until it’s properly dealt with, at least).

Personally I found that automatic path conversion caused nothing but problems, which is why I’ve blanket disabled it (in gitbash/mintty). If you find yourself needing it occasionally, just drop a MSYS_NO_PATHCONV=0 infront of the command you need - or, even run export MSYS_NO_PATHCONV=0 to enable it for that session.

A better way to convert paths is to do it explicitly, with cygpath -m /c/cygwin/unixy/path converts to C:/cygwin/unixy/path.

I tried the path workarounds with limited luck but indeed this is MSYS path conversion in action – a few more details here

Double slash works if desperate – e.g. these work

docker run -it -v //myvol debian:jessie //bin/bash
docker run -it -v //myvol://myvol debian:jessie //bin/bash

but for now probably best to use either powershell or boot2docker ssh

docker run -d --name redis-server -p 6379:6379 -v /h/redis:/var/lib/redis anapsix/redis

/h/redis = H://redis

@skaegi @SirRagnar This is duplicate of #12590. It’s happening due to msys, it converts unix paths to windows paths before passing them to docker.exe. In this case, that’s not a docker bug. (it’s not a msys bug either, it’s by design.)

See my comments in #12590 to run it correctly, or use cmd.exe or powershell to not to have this problem.

Or when I try to create a container like this,

docker run -v $(pwd):/app -w /app node npm start I get “:/app” is not a valid repository/tag: invalid reference format.

So I’m not sure what I’m doing wrong to get this to work. I’ve already got an express app installed and I’m in that directory, that’s where the PWD comes in and seems to throw no error. Only the :/app

Just to update, docker run -w C:/Users/djackson/ExpressSite node npm start

Just trying to get something to work but the above tells me Error response from daemon... It needs to be an absolute path and I thought that was an absolute path… This is driving me nuts! Lol.

Error: Invalid volume specification Info: Docker 1.12.5 docker-compose version 1.9.0 docker-machine.exe version 0.8.2 Terminal: git bash OS: Windows 10

Description: I just want to share my experience here for windows users who use git bash and ran into volume mount issue. i had a similar problem but unlike other people i was facing issue with “docker-compose up” command. In my .yml file i was trying to mount volume like;

volumes:
    - "/e/orchestration-workshop/dockercoins/webui/files/:files/"

i tried everything from // to ’ but nothing worked for me. at the end i tried this workaround to make it work.

volumes:
    - "/e/orchestration-workshop/dockercoins/webui/files/"

So when you don’t specify volume it use the same name as of your source directory and it worked. now i can see my folder mounted under /files on my docker container.

😃

The double slash at the beginning works in most cases. But there’s one in particular that won’t work

docker exec -it web rsync -rvul --exclude='/vendor' //var/www/files_remote/ //var/www/files

Problem bit is --exclude='/vendor' if I switch it to --exclude='//vendor' rsync doesn’t match it properly so the vendor directory is included. If I change it to --exclude='vendor' it excludes in sub dirs as well.

I’ve tried playing with the posix path conversion rules that @skaegi linked to, but couldn’t find a combo that would work. Any suggestions?

@ahmetalpbalkan do you think we should add something to the docs explaining this? I can imagine more people will run into this.

I’m going to close this issue, because of the reasons mentioned above https://github.com/docker/docker/issues/12751#issuecomment-96288101

Thanks for reporting @skaegi, it’s appreciated