docker run -d ubuntu /bin/sh -c "while true; do echo hello world; sleep 1; done"
using from git bash on win10 cause
C:\Program Files\Docker\Docker\Resources\bin\docker.exe:
Error response from daemon:
oci runtime error:
exec: "C:/Program Files/Git/usr/bin/sh":
stat C:/Program Files/Git/usr/bin/sh: no such file or directory.
and docker ps -a returns
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
82be3202167b ubuntu "C:/Program Files/Git" About a minute ago Created jovial_engelbart
seems like git bash change all dirs from root to local one, related to git bash installation
exec this command from power shell works well
also it change dir when adding a data volume
docker run -d -P --name web -v /webapp training/webapp python app.py
"Mounts": [
{
"Name": "945c5b0f0e3b140dad75b0de9850f504c37ef8472c94bd69550bc89af4210914",
"Source": "/var/lib/docker/volumes/945c5b0f0e3b140dad75b0de9850f504c37ef8472c94bd69550bc89af4210914/_data",
"Destination": "C:/Program Files/Git/webapp",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
running this command in power shell works fine
find similar issue on stack overflow
shell is mangling the file name according to these rules
+1
$ winpty docker run -it -p 8065:80 -p 2262:22 drupal:7.50 /bin/bash
docker: Error response from daemon: oci runtime error: exec: "C:/Program Files/Git/usr/bin/bash": stat C:/Program Files/Git/usr/bin/bash: no such file or directory.
$ docker version
Client:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built: Thu Jul 28 21:15:28 2016
OS/Arch: windows/amd64
Server:
Version: 1.12.0
API version: 1.24
Go version: go1.6.3
Git commit: 8eab29e
Built: Thu Jul 28 21:15:28 2016
OS/Arch: linux/amd64
COMMAND
"C:/Program Files/Git"
... on Windows 10 Pro
Getting the same error on Windows 10 Right now.
me@my-pc MINGW64 /z
$ docker run -it ubuntu /bin/bash
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: oci runtime error: exec: "C:/Program Files/Git/usr/bin/bash": stat C:/Program Files/Git/usr/bin/bash: no such file or directory.
$ docker info
Containers: 23
Running: 0
Paused: 0
Stopped: 23
Images: 18
Server Version: 1.12.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 67
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: null bridge overlay host
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.20-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.942 GiB
Name: moby
ID: WKOX:HURI:52OJ:XGQG:3XP5:4VQ3:DPRC:RHEA:HNX5:UU2X:JTKM:42DT
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 14
Goroutines: 23
System Time: 2016-09-29T04:15:05.3298145Z
EventsListeners: 0
Registry: https://index.docker.io/v1/
Insecure Registries:
127.0.0.0/8
Works fine when using the normal Windows command prompt, just not with Git-Bash
Yes, that's mingw trying to be smart, and converting paths. It's not a bug in Docker, but the way mingw handles these paths. Here is some more information about that "feature"; http://www.mingw.org/wiki/Posix_path_conversion. Prefixing the path with a double slash (//bin/bash) should prevent this, or you can set MSYS_NO_PATHCONV=1, see http://stackoverflow.com/questions/7250130/how-to-stop-mingw-and-msys-from-mangling-path-names-given-at-the-command-line#34386471
(but I'm not on Windows myself, so cannot check).
Posted a workaround here: https://github.com/docker/toolbox/issues/673
Most helpful comment
Yes, that's mingw trying to be smart, and converting paths. It's not a bug in Docker, but the way mingw handles these paths. Here is some more information about that "feature"; http://www.mingw.org/wiki/Posix_path_conversion. Prefixing the path with a double slash (
//bin/bash) should prevent this, or you can setMSYS_NO_PATHCONV=1, see http://stackoverflow.com/questions/7250130/how-to-stop-mingw-and-msys-from-mangling-path-names-given-at-the-command-line#34386471(but I'm not on Windows myself, so cannot check).