Mount volume doesn't work on Windows 10 using git-bash

[assumptionsoup]

It seems to be doing something weird with the path.

On git-bash:

$ docker run --rm -v c:/Users:/data alpine ls /data
ls: C:/Program Files/Git/data: No such file or directory

On cmd.exe:

C:\Windows\System32>docker run --rm -v c:/Users:/data alpine ls /data
All Users
Default
Default User
Default.migrated
DefaultAppPool
Public
desktop.ini

C:\Windows\System32>docker --version
Docker version 17.06.0-ce, build 02c1d87

[IllyaMoskvin]

Out of curiosity, can I ask where your Git for Windows is installed? Also, did you select to install Git for Windows when installing Docker Toolbox, or did you leave it unchecked, since you've already had it installed? This might be a red herring, but I'm looking into various path-related issue currently.

[anderejd]

Related (same?) problem:
https://forums.docker.com/t/weird-error-under-git-bash-msys-solved/9210/2

I can confirm the bug here too. docker run ubuntu /bin/echo hello world works in cmd.exe but not in Git Bash.

[anderejd]

I use the workaround described by dsebastien in the issue linked in my previous reply with a small modification to avoid changing the calling shell environment. This is what I use as workaround now, in my ~/.bash_profile on Windows 10, Git Bash:

# Workaround for Docker for Windows in Git Bash.
docker()
{
        (export MSYS_NO_PATHCONV=1; "docker.exe" "$@")
}

[anderejd]

Related issue: moby/moby#24029

[borekb]

@anderejd This workaround unfortunately doesn't work for me if docker run ... is called from an npm script. I have something like this:

{
  "scripts": {
    "start": "docker run -v $(pwd):/docs ...",
  }
}

and the volume mapping doesn't work. The only way I can make it work is to update the script directly, like so:

{
  "scripts": {
    "start": "MSYS_NO_PATHCONV=1 docker run -v $(pwd):/docs ...",
  }
}

which is of course ugly for other team members who don't use Git Bash, or are not on Windows at all.

[samjgalbraith]

This is from mingw intercepting your shell commands and replacing things it thinks are linux filesystem paths with their equivalent windows path. In git-bash you'll need to use double backslashes instead of single in Windows paths. To stop the container path /data getting mangled into C:\\data, you need to use a double-slash rather than just a single at the start.

docker run --rm -v C:\\Users://data alpine ls /data

[borekb]

Some more info: my script contains `pwd`, like this:

docker run --rm -v `pwd`:/app image

This resolves to something like:

docker run --rm -v /c/Dev/app:/app image

which does not work. This works:

MSYS_NO_PATHCONV=1 docker run --rm -v /c/Dev/app:/app image

And this works as well:

docker run --rm -v c:\\Dev\\app:/app image

So if I want to stay away from hardcoded path value and use `pwd` in some script, I really seem to need to have:

MSYS_NO_PATHCONV=1 docker run --rm -v `pwd`:/app image

which is unpleasant until you know what you're dealing with.

[anderejd]

@borekb I'm actually not using the workaround I posted any longer. The only sane way seems to be to set export MSYS_NO_PATHCONV=1 in the .bash_profile and live with the side effects.

[borekb]

I tried that but the situation was generally worse (many other things on my system stopped working with permanent MSYS_NO_PATHCONV=1).

I still think that Docker for Windows should support paths like /c/Dev/app in volume mappings.

[borekb]

UPDATE: I'll keep the info updated in a Gist, I needed that myself a couple of times already during this week.

For anyone interested, I now use a workaround that does not depend on a Bash alias but instead puts a script to a PATH. It's the only way I found to make docker and docker-compose happy in Git Bash without needing to manually specify MSYS_NO_PATHCONV=1 each time.

I created two small shell scripts, docker and docker-compose, and put them in a location that has higher-priority than Docker's default path. For that, I needed to update the system PATH:

This is the contents of my docker proxy script:

#!/bin/bash

(export MSYS_NO_PATHCONV=1; "docker.exe" "$@")

Similarly for docker-compose.

[matt-github-acct]

If anyone is curious, I spent some time digging into why this is happening and came up with this.

The error is stemming from a POSIX -> Windows API path conversion.

Some solutions:

1. Do what @borekb mentioned above and disable the path conversion.
2. Pass the command to the Windows shell.
3. Something else?

[nstohler]

For Git Bash for Windows (in ConEmu), the following works for me:

docker run --rm -it -v `pwd -W`:c:/api microsoft/dotnet:2-runtime

Note the backticks/backquotes around pwd -W!

With all other variations of PWD I've tried I've received: "Error response from daemon: invalid volume specification: ..."

https://stackoverflow.com/a/53776949/54159

[ice7mayu]

In Git bash (Git for Windows ) add a slash / before $(pwd) to bind-mount current dir to /backup folder in container, like:
winpty docker run -it --rm -v /$(pwd):/backup busybox

[cmosguy]

Hopefully, people scroll all the way down to @ice7mayu comment, this is the only one that works!

winpty docker run -it --rm -v /$(pwd):/backup busybox

Don't waste your time on all the other comments.

[imv7]

Only solved when Shared Folder

[patricknelson]

I think I started hitting a roadblock with winpty when trying mount named volumes. For example, take these commands:

Windows cmd.exe (works fine)

C:\test>docker run -it  -v example-root:/root busybox
/ # exit

git-bash without winpty

user@computer MINGW64 /c/test
$ docker run -it  -v example-root:/root busybox
the input device is not a TTY.  If you are using mintty, try prefixing the command with 'winpty'

git-bash with winpty

user@computer MINGW64 /c/test
$ winpty docker run -it  -v example-root:/root busybox
C:/Program Files/Docker Toolbox/docker.exe: Error response from daemon: create example-root;C: "example-root;C" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.
See 'C:/Program Files/Docker Toolbox/docker.exe run --help'.

The reason I don't just use cmd.exe is because I'd like to standardize on bash scripts that can run on both Windows + Mac to run commands on the container instead of writing two completely separate sets of scripts (why I'm using this container in the first place). However, I do need to persist data for caching reasons and would rather it be tucked away (not showing in the local host machine's folder).

Anyone have any clue how to workaround that named mount issue?

[PeterDaveHello]

I got the same result just like @patricknelson , looks like the above methods don't work now, I'm running Docker Desktop 19.03.5 on Windows 10 1903.

$ winpty docker run -it -v /$(pwd):/workdir -w /workdir alpine:3.10 ls
C:/Program Files/Docker/Docker/Resources/bin/docker.exe: Error response from daemon: the working directory 'C:/Program Files/Git/workdir' is invalid, it needs to be an absolute path.
See 'C:/Program Files/Docker/Docker/Resources/bin/docker.exe run --help'.

$ MSYS_NO_PATHCONV=1 winpty docker run -it -v /$(pwd):/workdir -w /workdir alpine:3.10 ls
C:/Program Files/Docker/Docker/Resources/bin/docker.exe: Error response from daemon: the working directory 'C:/Program Files/Git/workdir' is invalid, it needs to be an absolute path.
See 'C:/Program Files/Docker/Docker/Resources/bin/docker.exe run --help'.

$ winpty docker run -it -v c:\\:/workdir -w /workdir alpine:3.10 ls
C:/Program Files/Docker/Docker/Resources/bin/docker.exe: Error response from daemon: the working directory 'C:/Program Files/Git/workdir' is invalid, it needs to be an absolute path.
See 'C:/Program Files/Docker/Docker/Resources/bin/docker.exe run --help'.

[mat007]

@PeterDaveHello this is a limitation of Git for Windows, see https://stackoverflow.com/q/48427366/1195832

[tihomir-kit]

For me, this kind of syntax currently works on windows 10 1909 and docker desktop 19.03.5:

MSYS_NO_PATHCONV=1 docker run -it -v $(pwd):/workdir -w /workdir alpine:3.10 ls

[woonpeng]

@PeterDaveHello were you able to find a solution that does not involve pre-pending a POSIX paths with an additional /?

E.g not this:

$ winpty docker run -it -v /$(pwd):/workdir -w //workdir alpine:3.10 ls

Edit: I finally found a solution, it was to roll back to an appropriate version of Git for Windows. The latest, as of today v2.27.0, does not seem to recognize the MSYS_NO_PATHCONV environment variable. v2.26.2 was fine.

[mvpkenlin]

So the only solution now is adding MSYS_NO_PATHCONV=1?

[brewba]

Best solution is to prefix absolute paths with "//" when running bash on windows. A path that starts with "/[a-z]/" is transformed into a drive number, and other paths, even those that start with a single "/", are treated as relative paths.

Using "//" is the POSIX way to say "this is an absolute path".