OCI runtime exec failed: exec failed: (...) executable file not found in $PATH": unknown

Question

I have dockerized an app which has ffmpeg installed in it via libav-tools. The app launches without problem, yet the problem occured when fluent-ffmpeg npm module tried to execute ffmpeg command, which was not found. When I wanted to check the version of the ffmpeg and the linux distro set up in the image, I used sudo docker exec -it c44f29d30753 "lsb_release -a" command, but it gave the following error: OCI runtime exec failed: exec failed: container_linux.go:296: starting container process caused "exec: \"lsb_release -a\": executable file not found in $PATH": unknown

Then I realized that it gives me the same error with all the commands that I try to run inside the image or the container.

OCI runtime exec failed: exec failed: container_linux.go:296: starting container process caused "exec: \"ffmpeg -a\": executable file not found in $PATH": unknown

This is my Dockerfile:

FROM ubuntu:xenial
FROM node
RUN apt-get -y update
RUN apt-get --yes install libav-tools
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY package.json /usr/src/app
RUN npm install
COPY . /usr/src/app
RUN npm run build
ENV NODE_ENV production
EXPOSE 8000
CMD ["npm", "run", "start:prod"]

I would kindly ask for your help. Thank you very much!

Solution 1

This happened to me on windows. Any of these commands will work

On Windows CMD (not switching to bash):

docker exec -it <container-id> /bin/sh

On Windows CMD (after switching to bash):

docker exec -it <container-id> //bin//sh

or

winpty docker exec -it <container-id> //bin//sh

On Git Bash:

winpty docker exec -it <container-id> //bin//sh

For Windows users, the reason is documented in the ReleaseNotes file of Git and it is well explained here - Bash in Git for Windows: Weirdness... :

The cause is to do with trying to ensure that posix paths end up being passed to the git utilities properly. For this reason, Git for Windows includes a modified MSYS layer that affects command arguments.

Linux & Windows Users

You might need to run using /bin/bash or /bin/sh, depending on the shell in your container. Using shell instead of bash or vice versa will also give you this error.

Solution 2

docker exec -it <containerId> sh

Solution 3

I had this due to a simple ordering mistake on my end. I called

[WRONG] docker run <image> <arguments> <command>

When I should have used

docker run <arguments> <image> <command>

Same resolution on similar question: https://stackoverflow.com/a/50762266/6278

Solution 4

If @papigee does solution doesn't work, maybe you don't have the permissions.

I tried @papigee solution but does't work without sudo.

I did :

sudo docker exec -it <container id or name> /bin/sh

Solution 5

Get rid of your quotes around your command. When you quote it, docker tries to run the full string "lsb_release -a" as a command, which doesn't exist. Instead, you want to run the command lsb_release with an argument -a, and no quotes.

sudo docker exec -it c44f29d30753 lsb_release -a

Note, everything after the container name is the command and arguments to run inside the container, docker will not process any of that as options to the docker command.

---

For others with this error, the debugging steps I'd recommend:

• Verify the order of your arguments. Everything after the container name/id is a command to run. So you don't want docker exec $cid -it /bin/sh because that will try to run the command -it in the $cid container. Instead you want docker exec -it $cid /bin/sh

• Look at the command that is failing, everything in the quotes after the exec error (e.g. lsb_release -a in "exec: \"lsb_release -a\") is the binary trying to be run. Make sure that binary exists in your image. E.g. if you are using alpine or busybox, bash may not exist, but /bin/sh does. And that binary is the full string, e.g. you would be able to run something like ls "/usr/bin/lsb_release -a" and see a file with the space and -a in the filename.

• If you're using Windows with Git bash and see a long path prefixed on that command trying to be run, that's Git bash trying to do some automatic conversions of /path/to/binary, you can disable that by doubling the first slash, e.g. //bin/sh.

• If the command you're running is a script in the container, check the first line of that script, containing the #!/path/to/interpreter, make sure that interpreter exists in the image, at that path, and that the script is saved with linux linefeeds (lf, not cr+lf, you won't want the \r showing in the file when read in linux because that becomes part of the command it's looking to execute).

• If you don't have a full path to the binary in the command you're running, check the value of $PATH in the image, and verify the binary exists within one of those directories. E.g. you can docker exec -it $cid /bin/sh and echo $PATH and type some_command to verify some_command is found in your path.

• If your command is not an executable, but rather a shell builtin, you'll need to execute it with a shell instead of directly. That can be done with docker exec -it $cid /bin/sh -c "your_shell_builtin"

View more solutions

Comments

[whites11]

try entering your container with docker run --rm -ti your-image-name sh and find your executable. It is probably only a PATH problem (the directory where your executable is placed in is not in the PATH of the root unser inside the container)

[Uğur Kaya]

I have entered the container with the command that you recommended. The problem is that when I try to do apt-get install ffmpeg, the outcome is:Package ffmpeg is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'ffmpeg' has no installation candidate. However I can get the same package in my ubuntu 16.04 OS. May something be wrong with the OS in the container?

[whites11]

did you run apt-get update?

[Uğur Kaya]

I did run apt-get -y update && apt-get -y upgrade, and inside the container when I try to run lsb_release -a, this time the output is sh: 4: lsb_release: not found, same for ffmpeg: sh: 5: ffmpeg: not found. I run apt-get install libav-tools and get # apt-get install libav-tools Reading package lists... Done Building dependency tree Reading state information... Done libav-tools is already the newest version.. If I find -name "ffmpeg" output is empty.

[Uğur Kaya]

@whites11 I believe you are right, it seems to be a PATH problem, because inside the container, whatever I apt-get install and apt-get update, it is installed in container, yet after all I cannot run the command. Same happened for apt-get install lsb-release, it has installed and still couldn't run the command after installation: sh: 3: lsb-release: not found. Could you please give me a little bit more detailed information about how I can solve PATH problem?

[whites11]

First of all you have to find the absolute path of your executable (using find, maybe). Then, you have 2 options: 1) use the full path of the executable in your docker's CMD (and in general everywhere you are calling an executable) 2) add the directory that contains your binary to the end of the PATH environment variable, such as: export PATH=$PATH:/my/bin/folder

[Uğur Kaya]

Let us continue this discussion in chat.

[That Brazilian Guy]

See also stackoverflow.com/q/27158840/798677

[MD SHAYON]

Get some more solution over here

[O Wigley]

Try this docker exec -ti <container> sh -c <script-abs-path>

[otong]

what if I'm using docker-compose what could be the mistake? I ran using docker-compose -f .\a-docker-compose-file.yml up

[Jonathan Geisler]

@otong Your comment has nothing to do with my answer. Please post it as a new question and give more detail to your specific problem there.

[Indra]

This like works: You might need to run use /bin/bash or /bin/sh

[David]

This does apply also to docker compose and fixed it for me. Thank you very much

[sgauri]

kubectl exec -it <pod_name> /bin/sh worked for me, thanks

[Alejandro703]

I'm pretty sure your problem is that you are using backslashes in \bin\sh. Linux doesn't use those, so it is stripping them out. Use /bin/sh instead. "bash" works because there are no backslashes.

[johnpitchko]

Yes this worked, thank you. I assumed /bin/bash was available in the image. It was not but /bin/sh was and it works good enough for what I need.

[Yunnosch]

While this code may solve the question, including an explanation of how and why this solves the problem would really help to improve the quality of your post, and probably result in more up-votes. Remember that you are answering the question for readers in the future, not just the person asking now. Please edit your answer to add explanations and give an indication of what limitations and assumptions apply.

[Muhammad Faizan Fareed]

I was also getting this kind of error on alpine base image, because I was executing command using bash not from shell. For alpine base image use shell.

[pszaba]

OCI runtime exec failed: exec failed: unable to start container process: exec: "sh": executable file not found in $PATH: unknown