291

When I am running my docker image on windows 10. I am getting this error:

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

my docker file is:

FROM openjdk:8 EXPOSE 8080 VOLUME /tmp ADD appagent.tar.gz /opt/app-agent ADD services.jar app.jar ADD run.sh /run.sh # Install compiler and perl stuff RUN apt-get update RUN apt-get install -y build-essential RUN apt-get install -y gcc-multilib RUN apt-get install -y perl # Install Percona Toolkit RUN apt-get install --yes percona-toolkit RUN ["chmod", "+x", "/run.sh"] ENTRYPOINT ["/run.sh"]

and the script is start with #!/bin/sh

#!/bin/sh set -e JAVA_OPTS="-Dfile.encoding=UTF-8 -Djava.security.egd=file:/dev/urandom" if [ "${APPD_APP_NAME}" != "" ]; then JAVA_AGENT="-javaagent:/opt/app-agent/javaagent.jar fi exec java ${JVM_OPTS} ${JAVA_OPTS} ${JAVA_AGENT} -jar /app.jar

Tried method1: Tried changing #!/bin/sh to #!/bin/bash but getting same error.

Tried method2: added dos2unix in docker file

RUN apt-get install -y dos2unix RUN dos2unix /run.sh
Improve this question

29 Answers 29

Reset to default
507

Use notepad++, go to edit -> EOL conversion -> change from CRLF to LF.

update: For VScode users: you can change CRLF to LF by clicking on CRLF present on lower right side in the status bar

Improve this answer
Sign up to request clarification or add additional context in comments.

16 Comments

Perfect! I had a .sh file added which was being run from my Dockerfile. I replaced the line endings and Ta Da. Thank you
I did not find this option in notepad++ in 'edit tab' but I've changed it clicking on the bottom right side button written Windows( CR LF) and I changed to Unix. Thanks a lot!
I got this error when trying to build and run ckan docker images on Windows. If you run into this problem on a cloned repo, it might be useful to use the core.autocrlf setting during clone, if so, execute: git config core.autocrlf input => (deleted the files from the repo; wasn't sure if git reset would reset the newlines) => git reset --hard Copied from: github.com/LiveOverflow/PwnAdventure3/issues/11
For which file(s?) would you need to change this? The Dockerfile?
@Gloweye: no. the file you are passing in entry-point. In above case /run.sh
|
157

I had the same issue when using the alpine image.

My .sh file had the following first line:

#!/bin/bash

Alpine does not have bash. So changing the line to

#!/bin/sh

or installing bash with

apk add --no-cache bash

solved the issue for me.

Improve this answer

2 Comments

This! Should be in bold on Apline's Docker Hub page.
Yep, this is it. If you are using an entrypoint.sh file with Alpine docker image use #!/bin/sh instead of bash!
134

change entry point as below. It worked for me

ENTRYPOINT ["sh","/run.sh"]

As tuomastik pointed out in the comments, the docs require the first parameter to be the executable:

ENTRYPOINT has two forms:

ENTRYPOINT ["executable", "param1", "param2"] (exec form, preferred)

ENTRYPOINT command param1 param2 (shell form)

Improve this answer

4 Comments

Worked for me. In this case, we do not even need to add #!/bin/sh in the shell script. Mentioning "sh" in the ENTRYPOINT does the job
Can you explain why and when the "sh" is necessary? I saw many example working without.
@Opsse Without "sh", normal shell processing does not happen source
Turns out that in my ENTRYPOINT script I was using /bin/bash as shell interpreter, but since my image is alpine based it didn't come with it. I changed in my script bash by sh and problem solved.
93

Suppose you face this issue while running your go binary with in alpine container. Export the following variable before building your bin

# CGO has to be disabled for alpine export CGO_ENABLED=0

Then go build

Improve this answer

5 Comments

within Dockerfile this is, add ENV CGO_ENABLED=0 before the go build line. This worked for me.
so in Dockerfile, it should be: RUN export CGO_ENABLED=0 && go build
A better solution than disabling CGo, which can have a bunch of negative side effects, is to install the shared libraries that the Go binary is looking for. In Alpine, this can usually be achieved by adding RUN apk add --no-cache libc6-compat to your Dockerfile, to install the glibc compatibility libs.
Thanks, you save my day. Please note you can oneline this : RUN CGO_ENABLED=0 go build
@Gus Thanks! I think you should create an answer with this as it's a better/alternative solution than disabling CGO.
31

In my case I had to change line ending from CRLF to LF for the run.sh file and the error was gone.

Improve this answer

2 Comments

I have to keep fixing the same files over and over. It's like windows wants to keep me in it's ecosystem.
@JonathanCzitkovics maybe you should check your git config and the settings for your code editor
29

I just wanted to add: for VSCode users, you can change CRLF line endings to LF by clicking on CRLF in the status bar, then select LF and save the file.

I had the same issue, and this resolved it. Steps to follow for VSCode

Improve this answer

1 Comment

Worked for me for running on windows a node alpine container using docker-compose created on Linux. Thanks!
19

"No such file or directory" is coming from Linux, and I've seen the following causes:

First cause is not actually having the file inside your container. Some people try to run a command from the host without adding it to their image. Some people shadow their command by mounting a volume on top of the command they wanted to run. If you run the same container, but with a shell instead of your normal entrypoint/cmd value, and run an ls /path/to/cmd you'll see if this exists.

The next cause is running the wrong command. This often appears with json/exec formatting of the command to run that doesn't parse correctly. If you see a command trying to run ["app", or something similar, the json string wasn't parsed by Docker and Linux is trying to use a shell to parse the command as a string. This can also happen if you misorder the args, e.g. trying to run -it is a sign you tried to place flags after the image name when they must be placed before the image name.

With shell scripts, this error appears if the first line with the #! points to a command that doesn't exist inside the container. For some, this is trying to run bash in an image that only has /bin/sh. And in your case, this can be from Windows linefeeds in the script. Switching to Linux/Unix linefeeds in your editor will correct that.

With binaries, this error appears if a linked library is missing. I've seen this often when Go commands that are compiled with libc, but run on alpine with musl or scratch without any libraries at all. You need to either include all the missing libraries or statically compile your command. To see these library links, use ldd /your/app on your binary.

Improve this answer

4 Comments

Thanks! For my go application in scratch image, had to rebuild using CGO_ENABLED=0
My Case: 1.Executable binary is build from alpine,but base image that running go command is debian,so error occurred.
In my case, the binary was built using GraalVM Native Builder, by default it is built in a 'dynamic' form which apparently requires some library not present in Alpine. After adding --static to build a static binary the problem vanished.
⁺¹, my story: we had a COPY foo/ / statement in a Dockerfile. Among other things, it was copying /lib/… directory. Then what happened: we decided to upgrade image to a next release, and as turned out they replaced /lib with a symlink /lib → /usr/lib. As result, COPY statement started overwriting the symlink with a directory. And then, starting any binary on the container would result in them not finding /lib/x86_64-linux-gnu/libc.so.6, and Docker quitting with the infamous standard_init_linux.go:219: exec user process caused: no such file or directory.
18

Note a similar error such as:

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

can happen if the architecture an image was built for does not match the one of your system. For instance, trying to run an image built for arm64 on a x86_64 machine can generate this error.

Improve this answer

1 Comment

Thanks for writing that. It made me realize I was building with ubuntu and running with alpine and alpine was presumably missing something needed.
15

It's a CRLF problem. I fixed the problem using this: 

git config --global core.eol lf git config --global core.autocrlf input find . -type f -print0 | xargs -0 dos2unix
Improve this answer

Comments

11

I had this issue when building an application using CGO, then copying it over to a scratch image. Libc did not exist there, so I used alpine as my base image instead.

Improve this answer

1 Comment

This is not much voted, but solved my problem. Thanks.
6

Replacing CRLF with LF using Notepad++

  1. Notepad++'s Find/Replace feature handles this requirement quite nicely. Simply bring up the Replace dialogue (CTRL+H), select Extended search mode (ALT+X), search for “\r\n” and replace with “\n”:
  2. Hit Replace All (ALT+A)

Rebuild and run the docker image should solve your problem.

Improve this answer

Comments

6

I was building a Go application, and every one of these answers was wrong for me, so I wanted to share my solution. For me, I had a Dockerfile that had no Windows involvement (coded on a Mac, albeit shared between one on macOS 11 and another on macOS 12. Line endings are the same though).

For me, the solution ended up being that I needed to build my application as a statically linked binary that would run without external dependencies. I was building a Dockerfile for a Go application that was first built in a Go builder image, and then in a scratch image. To allow my binary to run on scratch, I had to add the CGO_ENABLED=0 flag. More info on this reddit page: https://www.reddit.com/r/golang/comments/pi97sp/comment/hbo0fq6/?utm_source=share&utm_medium=web2x&context=3

My code, which ended up working:

############################ # STEP 1 build optimized executable binary ############################ FROM golang:1.16-alpine AS builder WORKDIR /app COPY go.mod ./ COPY go.sum ./ RUN go mod download COPY *.go ./ RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-w -s" -o cl-api ############################ # STEP 2 build a small image ############################ FROM scratch COPY --from=builder /app/cl-api / EXPOSE 8000 ENTRYPOINT ["/cl-api"]
Improve this answer

1 Comment

This answer worked for me i.e compiling without dynamic (.so) links.
4

This is because the shell script is formatted in windows we need to change to unix format. You can run the dos2unix command on any Linux system.

dos2unix your-file.sh

If you don’t have access to a Linux system, you may use the Git Bash for Windows which comes with a dos2unix.exe

dos2unix.exe your-file.sh
Improve this answer

1 Comment

Best solution here. dos2unix can of course be installed in the dockerfile and a RUN command run on any/all files needed for the container to run. This is a common issue if building linux based images on a windows machine. i.e. find ./src/ -iname "*.ts" | dos2unix or whatever command works in one's circumstances.
4

I had the same error message while building a docker image based on ARM on x86 machine. The issue is solved by installing QEMU and registering the script

#Install the qemu sudo apt-get install qemu binfmt-support qemu-user-static packages #This step will execute the registering scripts docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
Improve this answer

1 Comment

It worked for me, without registration step.
4

The problem:

The problem comes from the .sh file. First we must remember that Windows uses \r\n as the end of the line, while Linux and Mac use \n. Git has a feature called autoclrf that is generally set to “true” on Windows. This automatically converts \n to \r\n upon completion of the download from a Git repository, but Git does not make any kind of notice of this, hence the error is generated. This process is good, at least for the other files, but it is not the case for bash files, as is the case for the entrypoint.sh file.

The Immediate Solution:

Open your favorite code editor and change the line endings for the file that is causing the conflict, in our case: entrypoint.sh. You can do that in Visual Studio Code at the bottom right of the software, click where it says CRLF and change the end of the line of the file to LF.

Read the entire post for permanent solution from the link below:

https://davidcasr.medium.com/docker-standard-init-linux-go-211-exec-user-process-caused-no-such-file-or-directory-en-c0cb42edb295

Improve this answer

Comments

3

For the VScode users, at the bottom-right corner of the IDE you can find CRLF/LF, so toggle this to LF and save again your file. Tada!! You will be fine.

enter image description here

Improve this answer

Comments

1

Add this to your Dockerfile

RUN cat /run.sh | tr -d '\r' > /run.sh
Improve this answer

Comments

1

I solve a similar issue

My configuration: -> Docker Desktop WSL 2 backend - Windows -> required CGO_ENABLED=1, because I compile a Kafka Producer using the Lib confluent-kafka-go.v1/kafka

My docker image has been build success, but when I going to start-up the image using docker-compose-up, is occur the same issue:

xxxxx:~/cp-all-in-one/cp-all-in-one-community# docker-compose up Recreating ms-c3alert ... done Attaching to ms-c3alert ms-c3alert | standard_init_linux.go:211: exec user process caused "no such file or directory" ms-c3alert exited with code 1

After, test all options in thread and another pages... I found the Fix adding in the go build sentence -ldflags='-w -extldflags "-static"'

RUN CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -ldflags='-w -extldflags "-static"' -a -installsuffix cgo -o c3alert .
Improve this answer

1 Comment

The solution for me was also similar to the one described in the answer above and the one provided by @arulraj.net. Had to ENV CGO_ENABLED=0 RUN go mod download RUN go build -a -installsuffix cgo -o myAppName . and then it worked.
1

I had an extra line at the end of my .sh file. I deleted it and fixed the issue.

Improve this answer

Comments

1

This error can also arise if trying to run a dynamically-linked executable in a from-scratch container. The executable will not be able to link to shared (so) libraries, and will report a (not so informative) "no such file or directory" error.

Let's build a dynamic executable test:

cat <<EOF | g++ -x c++ - -o test #include <iostream> int main() { std::cerr << "Hello!" << std::endl; return 0; } EOF

This is indeed a dynamic executable. Running ldd test will report something like (dependencies on libc etc.):

linux-vdso.so.1 (0x00007ffd699fc000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff570f7a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff570c76000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff570a5f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5706c0000) /lib64/ld-linux-x86-64.so.2 (0x00007ff5714fe000)

Now, let's build a from-scratch image with the former executable. The Dockerfile will be:

FROM scratch COPY test / CMD [ "/test" ]

Build the image. Then, run an on-the-fly container from image:

docker build . -t local/test docker run --rm local/test

The container fails with exit code 1, and i get:

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

The problem is solved by using static linking (use -static flag in previous gcc/g++ linker command) which produces a standalone executable.

Improve this answer

Comments

0

I solve this issue set my settings in vscode.

  1. File
    1. Preferences
      1. Settings
        1. Text Editor
          1. Files
          2. Eol - set to \n

Regards

Improve this answer

Comments

0

I found a particular edge case where I was using the tini init in an alpine container, but since I was not using the statically linked version, and Alpine uses musl libc rather than GNU LibC library installed by default, it was crashing with the very same error message.

Had I understood this and also taken time to read the documentation properly, I would have found Tini Static, which upon changing to, resolved my problem.

Improve this answer

Comments

0

There are multiple right answers here. I don't see the VIM version of it so here it is. Open your file in VIM, check the bottom status line for example, execute set ff=dos (for CRLF) or set ff=unix (for LF).

Improve this answer

Comments

0

You can use BBEdit on Mac to sort this issue since Notepad++ isn't available.

It's obvious at the bottom of the window. Alongside character-set options

Improve this answer

Comments

0 
git config core.autocrlf false git rm --cached -r . git reset --hard

https://www.codegrepper.com/code-examples/shell/How+to+change+all+files%27+default+eol+to+LF+in+windows

Improve this answer

Comments

0

I had a similar issue while building with the following

FROM golang:1.18.0-alpine3.15 AS builder WORKDIR /go/src/blah COPY . . RUN go get -d -v ./... RUN go install -v ./... WORKDIR /go/src/blah FROM centos AS runtime ## NOTICE THE DISTRO CHANGE HERE COPY --from=builder /go/bin/blah /bin/blah CMD ["blah"]

Here is my fix (same as outlined above, however adding for people to check it out )

FROM golang:1.18.0-alpine3.15 AS builder WORKDIR /go/src/blah COPY . . RUN go get -d -v ./... RUN export CGO_ENABLED=0 && go install -v ./... <== added during install/build WORKDIR /go/src/blah FROM centos AS runtime COPY --from=builder /go/bin/blah /bin/blah CMD ["blah"]

Cheers.

Improve this answer

Comments

0

When this error happend, all you need to do is to search where you are using the exec command, since this is what the error state.

Most of the time, this is because you are using it into your entrypoint.sh file to unable running additional commands.

To fix this error, run dos2unix your-entrypoint-file.sh.

This will update the EOL character.

See also https://nickjanetakis.com/blog/fixing-exec-format-errors-with-docker-entrypoint-scripts-on-windows

Improve this answer

Comments

0

This can also happen if you're running a non-statically compiled binary in a scratch container, or without some shared libraries it requires.

Example here https://github.com/thought-machine/prometheus-cardinality-exporter/issues/26

Improve this answer

Comments

0

I ran into this issue and just could not figure out why. I was stuck for 2 days trying EVERYTHING including re-writing my code line by line. then after nothing worked I said, "just for grins and giggles, let me delete the folder and rename it". I did this, rebuilt the docker image, and imported into containerd to run in K8s and viola it worked. I was so mad because it just didn't make sense that that worked! I don't know but hope it helps someone.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.