102

My ENTRYPOINT script doesn't execute and throws standard_init_linux.go:175: exec user process caused "no such file or directory". Why so?

Doesn't Work

$ docker build -t gilani/trollo . && docker run gilani/trollo
Sending build context to Docker daemon   126 kB
Step 1 : FROM vault:latest
 ---> 1f127f53f8b5
Step 2 : MAINTAINER Amin Shah Gilani <[email protected]>
 ---> Using cache
 ---> 86b885ca1c81
Step 3 : COPY vaultConfig.json /vault/config
 ---> Using cache
 ---> 1a2be2fa3acd
Step 4 : COPY ./docker-entrypoint.sh /
 ---> Using cache
 ---> 0eb7c1c992f1
Step 5 : RUN chmod +x /docker-entrypoint.sh
 ---> Running in 251395c4790f
 ---> 46aa0fbc9637
Removing intermediate container 251395c4790f
Step 6 : ENTRYPOINT /docker-entrypoint.sh
 ---> Running in 7434f052178f
 ---> eca040859bfe
Removing intermediate container 7434f052178f
Successfully built eca040859bfe
standard_init_linux.go:175: exec user process caused "no such file or directory"

Dockerfile:

FROM vault:latest

MAINTAINER Amin Shah Gilani <[email protected]>

COPY vaultConfig.json /vault/config

COPY ./docker-entrypoint.sh /

RUN chmod +x /docker-entrypoint.sh

ENTRYPOINT ["/docker-entrypoint.sh"]

docker-entrypoint.sh:

#!/bin/bash

echo 'Hello World!'

Works

$ docker build -t gilani/trollo . && docker run gilani/trollo
Sending build context to Docker daemon   126 kB
Step 1 : FROM vault:latest
 ---> 1f127f53f8b5
Step 2 : MAINTAINER Amin Shah Gilani <[email protected]>
 ---> Using cache
 ---> 86b885ca1c81
Step 3 : COPY vaultConfig.json /vault/config
 ---> Using cache
 ---> 1a2be2fa3acd
Step 4 : ENTRYPOINT echo 'hello world'
 ---> Using cache
 ---> ef5792a1f252
Successfully built ef5792a1f252
'hello world'

Dockerfile:

FROM vault:latest

MAINTAINER Amin Shah Gilani <[email protected]>

COPY vaultConfig.json /vault/config

ENTRYPOINT ["echo", "'hello world'"]
Improve this question
3
  • Why you need ENTRYPOINT instead of RUN? I think that ENTRYPOINT is executed before RUN.
    – Vedran Jukic
    Commented Aug 11, 2016 at 20:06
  • 9
    @VedranJukic it isn't. RUN is executed while the image is being build, while ENTRYPOINT is executed after the image has been built. I need an ENTRYPOINT script because my app needs additional capabilities provided with the docker run --cap-add to initialize.
    – Amin Shah Gilani
    Commented Aug 11, 2016 at 20:10
  • 7
    Also make sure your executable was not saved in Windows (happens often with open source) and fix the ^M removal by running sed -i -e 's/\r$//' filename.sh
    – tomasdev
    Commented Aug 30, 2017 at 19:30

16 Answers 16

Reset to default
192

I was tearing my hair out with an issue very similar to this. In my case /bin/bash DID exist. But actually the problem was Windows line endings.

In my case the git repository had an entry point script with Unix line endings (\n). But when the repository was checked out on a windows machine, git decided to try and be clever and replace the line endings in the files with windows line endings (\r\n).

This meant that the shebang didn't work because instead of looking for /bin/bash, it was looking for /bin/bash\r.

The solution for me was to disable git's automatic conversion:

git config --global core.autocrlf input

Reset the repo using this (don't forget to save your changes):

git rm --cached -r .
git reset --hard

And then rebuild.

Some more helpful info here: How to change line-ending settings and here http://willi.am/blog/2016/08/11/docker-for-windows-dealing-with-windows-line-endings/

For repo owners and contributors

If you own a repo or contribute to it, set mandatory LF line endings for .sh files right in the repo by adding the .gitattributes file with the following line:

*.sh text eol=lf
Improve this answer
7
  • I knew this could be a problem and I had core.autocrlf already set to input. But then I realized my IDE was adding in stupid CRLF so I fixed it and now it works. Thank you!
    – Ryan Shillington
    Commented Nov 5, 2017 at 16:16
  • Sometimes it is not git but the code editors you are using, in my case the IJ was setting all line endings as windows ones, screwing all the scripts when they was about to be executed through my dockers
    – Juan Monsalve
    Commented Jun 10, 2020 at 20:07
  • Thanks my friend you're great!!! I was been stuck with this error for months, only building and starting my containers on a linux machine via ssh. What a shame of developer am I? :/
    – WitnessTruth
    Commented Mar 21, 2023 at 16:26
  • 3
    Also in VSCode we can change the end format Setting Line Endings in VSCode: Open VSCode: Open the file you are working on or create a new one. Bottom Right Status Bar: Look at the bottom right corner of the VSCode window. You'll find a label that indicates the current line endings used in the file. It might say "CRLF" or "LF." Click on the Line Endings Label: Click on the label displaying the line endings (CRLF/LF). A menu will appear with options for changing the line endings. Select "LF" (Unix): Choose the "LF" (Unix) option from the menu.
    – André Castro
    Commented Dec 1, 2023 at 19:51
  • This is life saving, but to add I would re-iterate @RyanShillington point that it does not have to be git but to solve the problem momentarily you can ensure that vscode (or any other editor you're working on) saves the file in UTF-8 and not UTF-8 BOM that is applied automatically when using windows even if you didn't use it as a git repo.
    – karimkohel
    Commented Jan 6 at 11:16
89

the vault:latest image does not contain /bin/bash which you try to call with your shebang #!/bin/bash. You should either change that to #!/bin/sh or completely remove the shebang from your script.

Improve this answer
4
  • 1
    @BMitch: and I checked out vault:latest ;-)
    – Abacus
    Commented Aug 11, 2016 at 20:21
  • 1
    @prayagupd use /bin/sh
    – Koen.
    Commented Oct 2, 2017 at 19:09
  • 2
    In my case removing #!/bin/bash didn't help, in fact missing it was causing the same problem. Correct solution for me was the one provided by @daniel-howard.
    – Dragan Nikolic
    Commented Dec 23, 2017 at 21:54
  • You saved my bacon - i've been staring at this for days and this was it!
    – Jack S
    Commented Aug 25, 2022 at 13:48
36

Another possibility:

Check that the file is not saved with Windows line endings (CRLF). If it is, save it with Unix line endings (LF) and it will be found.

Improve this answer
3
  • 2
    Here is a command to go along with this answer. dos2unix is the linux command to change line endings for multiple files.
    – dskow
    Commented Dec 14, 2017 at 15:28
  • You might also be able to make the change within your editor or IDE. In Atom, there's a button in the bottom-right corner, to the left of the file encoding and syntax info.
    – Ryan Allen
    Commented Dec 14, 2017 at 16:08
  • This worked for me! thanks! here you can find how to turn a file from LF to CRLF and vv stackoverflow.com/questions/3569997/….
    – Paolo Biavati
    Commented Oct 17, 2023 at 12:50
31

Without seeing your image, my initial idea is that you don't have /bin/bash in your image. Changing the first line of your docker-entrypoint.sh to:

#!/bin/sh

will likely resolve it.

Improve this answer
1
  • 5
    This is especially relevant when using Alpine based images where the default shell is not called bash but ash.
    – Dirk
    Commented Nov 13, 2017 at 18:25
14

I struggled for hours because I haven't noticed anywhere explained that you need to copy the file in the location where the VM can access the file, preferably globally like so:

COPY docker-entrypoint.sh /usr/local/bin/

(I had thought it should just be automatically accessible since it's part of the dockerfile context)

Improve this answer
8

I came here with a similar issue while troubleshooting my attempt to build a Dockerfile "entry point" (entrypoint.sh) bash shell script (to be executed within the .NET Core SDK 2.2 image). The start of the script had the line #!/bin/bash, and during execution of docker-compose up (after successfully building with docker-compose build, the logging reported web_1 | ./entrypoint.sh: line 1: #!/bin/bash: No such file or directory.

Checking the file with VS Code, I noticed it was reporting the following encoding:

UTF-8 with BOM

enter image description here

Clicking on this, I would get the option to Save with encoding:

enter image description here

I chose to save as UTF-8 (utf8), which resolved the issue.

NOTE: I also found this SO article What's the difference between UTF-8 and UTF-8 without BOM?

Improve this answer
1
  • 1
    Duuuude so much thanks I was dying inside, in fact i had to check Lf encoding AND this utf-8 without bom... Many thanks it did the trick!
    – Moff452
    Commented Jan 21, 2021 at 12:42
6

Gosh I struggled for 2–3 hours!! Thanks to @Ryan Allen For my case it was CRLF problem. I am working on puppet manifests over ATOM for jenkins setup. Make sure if you are using ATOM or any other IDE on windows, when you take your file ( especially .sh) to unix, convert it to unix format. It worked like magic once converted. Here is what I added in my puppet file:

  exec {'dos2unix':
    path      => ['/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin:/opt/puppetlabs/bin'],
    command   => 'dos2unix /dockerwork/puppet/jenkins/files/*',
    subscribe => File['/dockerwork/puppet/jenkins/files/init.sh'],
  }
Improve this answer
4

I struggled with this as well on windows. At first, i used a python regular base image, and my start.sh file first line was #!/bin/bash.

Once I changed to a python-alpine image, I found that changing my start.sh to #!/bin/sh did the trick.

Improve this answer
3

This problem is to do with line endings and I solved it with the solution below

Convert the DOS file to a unix format. This removes any wired line endings.

dos2unix - is available in alpine as well as other Linux distributions.

I used it like so: RUN apk add dos2unix && dos2unix /entry.sh

Improve this answer
2

My case was that the alpine image I was using didn't come with bash at all... RUN apk-install bash did the trick obviously

Improve this answer
3
  • 1
    No need to install bash (unless you want to use bashisms), just use #!/bin/sh
    – Koen.
    Commented Oct 2, 2017 at 19:10
  • In my case I needed bashisms yes.
    – Painy James
    Commented Oct 3, 2017 at 8:18
  • This conversation was helpful, thank you, although I had a different problem. I had not installed (apk add) dumb-init on my alpine image even though my docker-entrypoint.sh was calling it.
    – Valerie Parham-Thompson
    Commented Jan 29, 2018 at 15:51
2

Windows the problem was the CRLF it needs to be LF:

enter image description here

If you still keep getting the error it could be because you're running Windows. Move the source code directory under the WSL drive/root and open VsCode choosing the notification to open in WSL mode:

enter image description here

Improve this answer
1

Another reason this error comes up is if your Windows User password changes.

In my case my entrypoint.sh line endings were LF but I was still getting the error. Our admin has a mandatory password reset about every month or so. Whenever this happens I would run into the error. If this is your reason you may need to reset your credentials in docker settings under "Shared Drives".

Unselect the drive and apply. Then reselect the drive and apply. It will prompt you for your password.

Improve this answer
0

Sorry for hacking -- this is not a response to the question, but a description of a different problem and it's solution that has the same symptoms.

I had

ENTRYPOINT ["/usr/bin/curl", "-X", "POST", "http://myservice:8000", \
              "-H", "Content-Type: application/json", \
              "-d", '{"id": "test"}' \
]

I was getting the error:

/bin/bash: [/usr/bin/curl,: No such file or directory

It turns out it's the single quotes that messed it up. Docker documentation has a note:

The exec form is parsed as a JSON array, which means that you must use double-quotes (“) around words not single-quotes (‘). Blockquote

Solution -- use double quotes instead of single and escape nested double quotes:

ENTRYPOINT ["/usr/bin/curl", "-X", "POST", "http://myservice:8000", \
              "-H", "Content-Type: application/json", \
              "-d", "{\"id\": \"test\"}" \
]
Improve this answer
0

None of the solutions worked for me but I was able to solve the error by setting WORKDIR to the same directory that contained the entrypoint script. No amount of cd'ing would work but somehow WORKDIR solved it

Improve this answer
0

In my case it was due to the build being for a different platform than the current one (say, you're building on a M1 mac and that defaults to arm64 instead of amd64), Docker will be more than happy to pull it and run the container, but then it fails with this message.

Improve this answer
0

none of the solutions worked for me except copying the entrypoint.sh file to /usr/local/bin to run from there.

when copied to other folders like my app folder e.g /var/www/docker/entrypoint.sh at first , i could see the .sh file was there when inspecting the image , but when running the container it disappeared, causing the error. and my dockerignore file didn't mention any .sh

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.