Docker Community Forums

Share and learn in the Docker community.

Standard_init_linux.go:175 exec user process caused no such file

General Discussions
#2

Just a quick note.

The entrypoint does indeed exist since I’m doing a chmod +x on it.

With the chmod commented out like below I’m getting a “permission denied” error instead of “no such file”.

COPY docker-entrypoint.sh /entrypoint.sh
#RUN chmod +x /entrypoint.sh
ENTRYPOINT [ "/entrypoint.sh" ]
1 Like
#3

Finally figured it.

I had to run dos2unix on the entrypoint script. Wish the error message was more descriptive.

27 Likes
#4

Line endings can be a PITA when working with shell scripts on Linux, unfortunately it’s Linux itself that’s producing such an uninformative error.

Running on a Linux machine, and changing a script to DOS line endings;

./script.sh
bash: ./script.sh: /bin/sh^M: bad interpreter: No such file or directory

We’re working on trying to improve that error message (at least to try including which file caused the error)

3 Likes
#5

hi can you explain it slowly so I can comprehend your point

1 Like
#6

Thank you! This worked for me as well after much frustration.

1 Like
#7

Saved my day… thanks a lot

#8

I think you just have to make sure the line endings of your files, especially (exclusively?) the .sh scripts are unix-style not some other (windows).

2 Likes
#9

Thank you! For me was about line endings.

#10

Hi, I’ve run into the same issue creating the .sh file in vscode. Is there a way to save it without having to run dos2unix?

1 Like
#11

For vscode, just press CRLF in the status bar while opening the .sh file, select LF then save the file.

10 Likes
#12

I also happen to get this when I compile a go program and put it in a container using multi-stage building.

In my case the solution was to add CGO_ENABLED=0 to the go build line.

5 Likes
#13

some kind of monster, save my day!

#14

Holy, I was going mad with this error converting to LF did the trick for me Tnx

#15

Hi, All of my files are in LF format but I still get the error

standard_init_linux.go:211: exec user process caused “no such file or directory”

While it works properly on my local machine, this problem arised only when we deployed it to cluster through bit bucket/bamboo pipeline

Any help much appreciated. Thank you.

#16

Thanks,

I open Shell Script file (entrypoint.sh) with VS Code, Change CRLF to LF, save it and then its work.

REF:
Create new file - default to LF, not CRLF
Configuring Line Separators

#17

This fixed the issue for me. Thank you.

#18

I was facing the same issue and neither running dos2unix helped, neither was it a CRLF/LF based issue.

What I realized is that I was using a debian based image and to run the script, I had to use

ENTRYPOINT ["sh", "entrypoint.sh"]

So debian image had /bin/sh and not /bin/bash. Every shell has its own unique ways of running shell scripts and I learnt an important lesson to not assume that they all run the same.

Also, using an ubuntu:bionic image is much preferred. It defaults to bash.
So on the ubuntu:bionic image, both these work:

ENTRYPOINT ["/entrypoint.sh"]
ENTRYPOINT [“bash”, “entrypoint.sh”]

One way to also verify if your script is being executed correctly, is to have a simple echo "Hello world, this works!" command in your script and run the image locally.

docker run -it <image> /bin/bash for ubuntu.
docker run -it <image> /bin/sh for debian.

If you see and output for the the echo command, things are working fine. Else, it should open up a shell in the root directory of the image.

2 Likes
#19

re: Else, it should open up a shell in the root directory of the image.

This is if you remove the entrypoint section from the dockerfile and want to run an interactive shell with the docker run commands posted above.

#20

I am using the debian:buster-slim image and it certainly has bash installed. Which debian were you using that didn’t have bash? Did you launch an interactive shell on the container and verify bash was not installed e.g. which bash ?

In your entrypoint.sh script, what was the she-bang at the top of the script?
I had this error when I erroneously used #!/usr/local/bin/bash
Changing the script to #!/bin/bash made it work.

I did try your suggestion of ENTRYPOINT[“bash”,“entrypoint.sh”] with the script still using the wrong she-bang, and that did also work. That kind of feels excessive though, you are launching a subshell to run your script which then runs in another subshell.

#21

I had #!/bin/bash at the top of my entrypoint script and got this error. Changing it to #!/bin/sh fixed it for me.