I'm using a prebuilt container from Dockerhub. When I run the container it acts like it's in a folder called workspace, since my run command sudo docker run -it shubhamgoel/birds:bigbang bash returns root#eg2e775g0a1b:/workspace#
I don't know how to navigate to the correct folder. I need to run this container in a folder /home/s/ucmr.
If I do
sudo docker run -it shubhamgoel/birds:bigbang bash -c "cd:/home/s/ucmr"
I get
bash: cd:/home/s/ucmr: No such file or directory
How do I navigate to the correct folder with this prebuilt container? Thank you.
__
Edit: I've tried
sudo docker run -v /kitty:/dog --name kittycat -it shubhamgoel/birds:bigbang
and when I search for 'dog' on my disk there's no such folder. Also when I type in mkdir frog and search for 'frog' on my disk there's no such folder...
docker run -it shubhamgoel/birds:bigbang bash -c "cd:/home/s/ucmr" is wrong for 2 reasons. The first one has already been covered by the other answer (wrong syntax with cd command). The other is that using the -it docker option with a non-interactive bash is kind of meaningless. The -c bash option just means "execute whatever there is between the double quotes and return to the caller", this last part makes the interactivity vanish.
A first naive solution, but still working, could be creating another shell like this:
docker run -it shubhamgoel/birds:bigbang bash -c "cd /home/s/ucmr && bash"
However, docker is far smarter and flexible and lets you override some Dockerfile directive, for instance the WORKDIR:
docker run -it -w="/home/s/ucmr" shubhamgoel/birds:bigbang bash
I create docker container with
sudo docker run -it ubuntu /bin/bash
in book The docker book I read
The container only runs for as long as the command we specified, /bin/bash , is running.
didn't I created terminal with option -it and /bin/bash isn't required? will anything change if I don't pass any command in docker run?
You will get the same behavior if you run
sudo docker run -it ubuntu
because the ubuntu docker image specifies /bin/bash as the default command. You can see that in the ubuntu Dockerfile. As #tadman wrote in their answer, providing a command (like /bin/bash) overrides the default CMD.
In addition, -it does not imply a bash terminal. -t allocates a pseudo-tty, and -i keeps STDIN open even if not attached. See the documentation for further details.
That's an override to the default CMD specification. You can run a container with defaults, that's perfectly normal, but /bin/bash is a trick to pop open a shell so you can walk around and check out the built container to see if it's been assembled and configured correctly.
I'm new to Docker.
I have a simple DockerFile:
FROM ubuntu:12.04
CMD echo "Test"
I built the image using the docker build command (docker build -t dt_test .).
All that I want to do is run the docker image interactively on Git bash. The path in git has been set up to include the docker toolbox.
When I run the interactive docker run command: "docker run -it dt_test"
it gives me an ERROR:
the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'
So I've tried prefixing the run command with winpty, and it executes the command but doesn't show me the interactive shell. When I type something, I cant see any of the commands that I'm typing into the terminal. I have to then type "reset" and then it sets the terminal back to normal. So I guess the winpty command isn't working
Questions:
Is there something wrong with the "winpty docker run -it dt_test" command and why doesn't it work?
How can I fix this issue to make my file run interactively?
FYI: When I run the docker file non interactively it seems to work fine. shows "Test" in the terminal according to the Dockerfile.
Looks to be the same as the input device is not a TTY.
Try without the -t:
docker run -i dt_test
And to run it with a different entrypoint (like bash):
docker run -i --entrypoint bash dt_test
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!
This happened to me on windows. See below for any of the commands that match your case.
NOTE
You will need to run the commands that match your case below using the correct shell in your container i.e. /bin/bash or /bin/sh. Using sh instead of bash or vice versa will also give you this error. So, confirm that you are using the right shell, or just try both shells and see the one that works.
For these examples, I will be using sh
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
docker exec -it <container-id> /bin/sh
docker exec -it <containerId> sh
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
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
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"
I solved this with this commands:
Run the container:
docker run -d <image-name>
List containers:
docker ps -a
Use the container ID:
docker exec -it <container-id> /bin/sh
I was running into this issue and it turned out that I needed to do this:
docker run ${image_name} bash -c "${command}"
You can use another shell to execute the same command:
Error I get when i execute:
[jenkins#localhost jenkins_data]$ docker exec -it mysqldb \bin\bash
OCI runtime exec failed: exec failed: container_linux.go:345: starting container process caused "exec: \"binsh\": executable file not found in $PATH": unknown
Solution:
When I execute it with below command, using bash shell it works:
[jenkins#localhost jenkins_data]$ docker exec -it mysqldb bash
root#<container-ID>:/#
What I did to solve was simply:
Run docker ps -a
Check for the command of the container (mine started with /bin/sh)
Run docker-compose exec < name_of_service > /bin/sh (if that is what started your command
This is for solving when using docker compose
I was running a container in a docker-compose.
entrypoint:
- ls
worked, but
entrypoint:
- ls tests
did not.
It's because the arguments have to be on separate lines.. 🤦♂
entrypoint:
- ls
- tests
This has happened to me. My issue was caused when I didn't mount Docker file system correctly, so I configured the Disk Image Location and re-bind File sharing mount, and this now worked correctly.
For reference, I use Docker Desktop in Windows.
In my case i saved the docker image and instead of load-ing it on the other machine i imported it which are very different and lead me to an error similar to this.
you have to run like below:
docker exec sh -c 'echo "$ENV_NAME"'
I had windows line endings in a shell script. change to LF dos2unix
If you got this error when using the docker run command, you may have made a simple syntax error.
Example
Incorrect:
docker run myimage -p 3838:3838
docker: Error response from daemon: failed to create shim: OCI runtime create
failed: container_linux.go:380: starting container process caused:
exec: "-p": executable file not found in $PATH: unknown.
ERRO[0000] error waiting for container: context canceled
Correct (options go before image name):
docker run -p 3838:3838 myimage
I have a docker file as follows:
FROM scratch
ARG VERSION=NOT_SET
ENV VERSION $VERSION
COPY foobar foobar
COPY foobar-*.yaml /etc/
COPY jwt/ /etc/jwt/
EXPOSE 8082
ENTRYPOINT ["./foobar"]
CMD ["-config", "/etc/foobar-local.yaml"]
Now, docker ps shows the following:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
653a9b287eb6 7693481.dkr.ecr.us-east-1.amazonaws.com/foobar:0.0.1 "./foobar -config /e" About a minute ago Up About a minute foobar
When I try to exec to this container with the following command:
sudo docker exec -it 653a9b287eb6 /bin/bash
it shows the following error:
rpc error: code = 2 desc = oci runtime error:
exec failed: exec: "/bin/bash": stat /bin/bash: no such file or directory
You need to add a shell to your empty base image (SCRATCH) in order to attach to it.
Right now, your image only include an executable, which is not enough.
As mentioned in issue 17896
FROM scratch literally is an empty, zero-byte image / filesystem, where you add everything yourself.
See for example, the hello-world which, produces an image that's 860 bytes total.
If you need a shell to attach to it through docker exec, start from a small image like Alpine (which has only /bin/sh though: you would need apk add bash to add bash, as commented below by user2915097).
If you are using Kubernetes, I have a repo that installs busybox on FROM scratch -image: https://github.com/phzfi/scratch-debug
In principle, by using the same process, you can also install busybox and shell on any other docker container, but I need to still make a script for debugging e.g. docker-compose and swarm orchestrators.