Trying to run docker-compose up
, my first container with a bind mount seems to be failing:
compose.cli.main.main: Cannot start container b097f0e6f952c1b40fd25f98f64ec27babe9efbfeabf224be939f07c87a9cd35: [8] System error: no such file or directory
Here's the relevant portion of my docker-compose.yaml
:
search:
container_name: dev_search
image: elasticsearch
volumes:
- ./elasticsearch/docker-entrypoint.sh:/docker-entrypoint.sh
- ./elasticsearch/config:/usr/share/elasticsearch/config
- ./elasticsearch/data:/usr/share/elasticsearch/data
ports:
- "9200:9200"
- "9300:9300"
Docker Compose version:
$ docker-compose --version
docker-compose version: 1.5.0rc3
Docker version:
$ docker --version
Docker version 1.8.3, build f4bf5c7
Docker Machine version:
$ docker-machine --version
C:\Program Files\Docker Toolbox\docker-machine.exe version 0.4.1 (e2c88d6)
Other fun facts:
docker-machine ssh default
and it looks like all the vboxsf mounts are goodA docker inspect
for the container would be really helpful to debug this.
@atrauzzi Where are you're shared volumes? in C:\Users ?
Yeah, in a path under my home dir.
@dnephin here's the output of inspect: https://gist.github.com/atrauzzi/8ca2d0b41c7852907fdd
Ok, the bind mounts look correct.
I looked around for tickets with similar errors, and I'm pretty sure the issue is with the entrypoint script /docker-entrypoint.sh
. The script needs to have executable permission (chmod +x
).
I'm not sure how that works in windows. I don't think there is an equivalent. So I think you'll have to change your config to include:
entrypoint: ['bash', '/docker-entrypoint.sh']
That way the script isn't being run directly, it'll run using bash, which has the executable permission enabled on it already.
I ran into the same problem, the entrypoint addition didn't help with my enviroment though...
Tried bind mounts with relative and absolute paths, no difference.
Environment: Windows 7 Pro, runs fine under Linux and OSX as well
Docker version 1.9.0, build 76d6bc9
docker-compose version: 1.5.0
docker-machine.exe version 0.5.0 (04cfa58)
Edit: gist of inspect
@rebsp that inspect shows no entrypoint and a Cmd of /start_up.sh
.
I don't think the issue has to do with volumes, it's an issue with file permissions. In linux you have to give a file executable permission before you can run it. I don't know how to give it that permission from windows.
Can you try with a command: ["bash", "/start_up.sh"]
? and if that doesn't work a gist of the inspect and the error message you get
@chadzink yours sounds like a different issue, I took a quick look at the inspect, but I don't see anything wrong. You might need to open a new issue about it.
@dnephin Thanks for looking, I'll do that.
@dnephin thanks for looking into it, I totally pasted the wrong inspect, sorry about that! Here are the two relevant inspects, once with command: ["bash", "/start_up.sh"]
and once with entrypoint: ['bash', '/docker-entrypoint.sh']
:
I notice the "Error": "",
line doesn't have the same [8] System error: no such file or directory
error from the original issue.
From what I can see, the error is coming from start_up.sh
. If you add set -x
to that script, maybe it will give you more output about the failure?
Jep, it just says
/start_up.sh: line 4: /var/www/html/src/htdocs/wp-content: No such file or directory
So the directory doesn't seem to exist on the docker machine? On my Windows host it's clearly there...
The mounts in the inspect look to be at D:\foo
. Have you created a virtualbox shared folder for that path? docker-machine only shares C:\Users
by default.
I don't think your issue is related to this one.
I had a similar issue with Windows 10 and changing the following in my Dockerfile
worked for me:
CMD ["/run.sh"]
to
ENTRYPOINT ["/bin/bash", "/run.sh"]
Wow thanks @dnephin and @jamescarlos! I'm using Cookiecutter-Django (https://github.com/pydanny/cookiecutter-django) and stumbled on this problem on Windows 7. Putting "/bin/bash" in front of the entrypoint-file resolved this issue!
This will be fixed by https://github.com/docker/docker-py/pull/938
@dnephin - I'm actually starting to wonder if this ticket has something to do with the paths that compose is sending in for the bind mounts.
I just tried starting up a project today and got this error. My VM does have the windows filesystem mounted, but if I'm using relative paths, where is compose telling the VM-docker daemon to start in order to find the files?
Compose doesn't communicate with the VM. docker-machine
adds a single shared folder for /C/Users
, and nothing else is available by default.
I think it's safe to close this. Bind mounts seem to be working on Windows using the docker beta, so I'd say so long as the docker ecosystem manages to translate paths to VM mounts correctly, there's no problem here.
panic: standard_init_linux.go:175: exec user process caused "no such file or directory"
I have been encountered this error every time on my Windows 10 when I run this command :
docker build -t my:hello .
docker run -ti my:hello bash
My Dockerfile :
FROM debian:jessie
VOLUME ["/data"]
COPY docker-entrypoint.sh /usr/local/bin/
RUN ln -s /usr/local/bin/docker-entrypoint.sh /docker-entrypoint.sh
ENTRYPOINT ["/bin/sh", "/docker-entrypoint.sh"]
Related "docker-entrypoint.sh":
!/bin/bash
echo
pwd
That's all . I hope some one can help my problem.
Sets git to clone repos without adjusting line-endings for unix to windows
For anyone coming across this issue. This was one of the first places I checked for a solution for this as I was experiencing the same problem when running Docker CE for windows. After some extensive research and multiple attempts, I came across this, which is the only fix that has worked for me so far. It may not resolve your issues, but it is something to try first at least.
Windows ends lines in a carriage return and a linefeed \r\n
,
While Linux and macOS only use a linefeed \n
.
In cmd enter: git config --global core.autocrlf input
@dnephin: You have ended days of headache for me. Thank you. I inherited a project that seemed to be built for UNIX, and no Mac or Linux user knew the answer.
Most helpful comment
Ok, the bind mounts look correct.
I looked around for tickets with similar errors, and I'm pretty sure the issue is with the entrypoint script
/docker-entrypoint.sh
. The script needs to have executable permission (chmod +x
).I'm not sure how that works in windows. I don't think there is an equivalent. So I think you'll have to change your config to include:
That way the script isn't being run directly, it'll run using bash, which has the executable permission enabled on it already.