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

General
1

I just started using Docker for Windows and I quickly run into an error that I cannot resolve.
I have tried both the stable and beta releases with the same result.

standard_init_linux.go:175: exec user process caused "no such file or directory

This happens on e.g. the mongodb 3.2 Dockerfile on the hub. If I remove the ENTRYPOINT in that Dockerfile it will start.

The issue happens in other dockerfiles as well though. I believe it is related to ENTRYPOINT but I am not 100% certain.

Docker version

Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:04:48 2016
 OS/Arch:      windows/amd64
 Experimental: true

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 21:04:48 2016
 OS/Arch:      linux/amd64
 Experimental: true

Docker info

Containers: 5
 Running: 3
 Paused: 0
 Stopped: 2
Images: 68
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 55
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.15-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.855 GiB
Name: moby
ID: ZSLX:OERW:JGK6:HHAV:AGQU:IHA4:XZYA:2BIH:S2FS:WS5M:ZMK5:5MME
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8`
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.

12 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)

2 Likes
5

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

6

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

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).

1 Like
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?

11

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

3 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.

1 Like
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.