cli: docker: Error response from daemon: oci runtime error: container_linux.go:262: starting container process caused "open /proc/self/fd: no such file or directory".

@ThaSami current version of Fedora 31 switched to using cgroupsV2 by default, which is not yet supported by the container runtimes (and kubernetes); work is in progress on this, but not yet complete, and not yet production ready. To disable v2 cgroups, run:

sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

And restart your machine.

@jakubzloczewski double-check the exact command you’re running to start your container; from that output, it looks like you passed the -d option after the name of the image you’re trying to run. Because of that, -d is used as the command to run inside the container, thus will fail;

docker run busybox -d
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"-d\": executable file not found in $PATH": unknown.

The -d (--detach) option is an option for docker run, so must be passed before the name of the image you’re running;

docker run -d busybox

Getting this on Mac OSX Catalina still.

any solution for this issue ? oci runtime error: container_linux.go:265: starting container process caused "exec:

still getting this, 2 years later and 40+ reactions on macOS catalina, stuff like this makes me doubt the time I save with docker for development… 🙃

same issue, running same version and on Fedora 25 here too.

I had the same issue on a host running Ubuntu and needed to use:

sudo update-grub "systemd.unified_cgroup_hierarchy=0"

For anyone else that is on Ubuntu so doesn’t have grubby

Isn’t this because you try to define the volume twice? This volume is already defined in the nginx docker file.

If I mount the volume on run it works “docker run -d -p 80:80 -v $PWD:/usr/share/nginx/html nginx”

For me the error occurred when I was trying to execute command to run my startup script command: bash startup.sh. Problem was that my image build was made on alpine linux which uses ash as shell instead of bash. Just double check that you are referring to correct shell interpreter.

It is also may be caused by modified credentials (on Windows). When you have changed your system password, Docker cannot automatically determine it. You should go to Settings\Shared Drives and Reset credentials.

Hey everyone, what about this error please. i execute this command “sudo docker run hello-world” , it gives me this error

<<< docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused “process_linux.go:449: container init caused "rootfs_linux.go:58: mounting \"proc\" to rootfs \"/var/lib/docker/overlay2/63492ef766e4b2f1ae17d5b6abc40fc07b910caeb46a570fdd43d25c82694a04/merged\" at \"/proc\" caused \"permission denied\""”: unknown. ERRO[0003] error waiting for container: context canceled >>>

not working even after restart the computer.

VOLUME [".","/usr/share/nginx/html"]

@suiwenfeng What exactly are you trying to do with that line? Using the JSON notation for VOLUME in this case attempts to define two volumes; one at "." (current working-directory), and one at "/usr/share/nginx/html" (which is already defined as a volume in the base image)

The first (".") is what’s causing the issue here, because the working-dir for the nginx image is /, which effectively would try to create a volume for the whole container (which isn’t allowed / won’t work). You can find the current working-directory for the image using the following;

$ docker run --rm nginx pwd
/

Interesting bit here, is that there is some validation in the daemon, but it’s missing validation for certain cases. For example, these Dockerfiles all build without producing an error during build;

FROM nginx
VOLUME ["/"]

FROM nginx
VOLUME /

FROM nginx
VOLUME ["."]

FROM nginx
VOLUME .

But starting a container from any of the above (as expected) won’t work;

docker: Error response from daemon: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"open /dev/ptmx: no such file or directory\"": unknown.

When defining a volume at runtime, the following correctly produces a validation error;

$ docker run -it --rm -v myvolume:/ nginx 
docker: Error response from daemon: invalid volume specification: 'myvolume:/': invalid mount config for type "volume": invalid specification: destination can't be '/'.
See 'docker run --help'.

But only specifying the “container path” does not perform the correct validation, thus results in the same “cryptic” error;

$ docker run -it --rm -v / nginx
docker: Error response from daemon: OCI runtime create failed: container_linux.go:296: starting container process caused "process_linux.go:398: container init caused \"open /dev/ptmx: no such file or directory\"": unknown.

same with “Version 2.0.0.0-mac78 (28905)” I’ve tried reset to factory settings but still got:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"-d\": executable file not found in $PATH": unknown.

I am experiencing the same under Ubuntu 20.04 with zfs on root after a reboot. I have reinstalled docker and cannot get my containers up.

docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused “exec: "/entrypoint.sh": stat /entrypoint.sh: no such file or directory”: unknown.

@ThaSami current version of Fedora 31 switched to using cgroupsV2 by default, which is not yet supported by the container runtimes (and kubernetes); work is in progress on this, but not yet complete, and not yet production ready. To disable v2 cgroups, run:

sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

And restart your machine.

The solution worked like a charm for Fedora 31.

@ThaSami current version of Fedora 31 switched to using cgroupsV2 by default, which is not yet supported by the container runtimes (and kubernetes); work is in progress on this, but not yet complete, and not yet production ready. To disable v2 cgroups, run:

sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"

And restart your machine.

Thanks for your fix. I’m on Fedora 31, and docker works with latest docker documentation for fedora: https://docs.docker.com/install/linux/docker-ce/fedora/#install-docker

@pumba-lt your error looks different; from the error (copied the important parts below):

mounting "/var/jenkins_home/workspace/docker-platform_stage.localhost_/docker/nginx-frontend/nginx.test.conf" to rootfs 
at "/var/lib/docker/overlay2/81cb11389790f97d5026133a05e4f555d499963dd614e082072276ca6a362bc6/merged/etc/nginx/nginx.conf"
caused "not a directory """: unknown: 
Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

That error indicates that likely the nginx.test.conf file did not exist on the daemon host. If you were attempting to mount a file using the -v <host-path>:<container-path> option, and <host-path> doesn’t exist on the daemon host, docker will assume you want to bind-mount a directory, and create the directory if it doesn’t exist. It then bind-mounts the directory in the container at <container-path>, which will fail if <container-path> is a file (because you cannot mount a directory on top of a file). That’s the last part of the error message:

Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.

• check if the file /var/jenkins_home/workspace/docker-platform_stage.localhost_/docker/nginx-frontend/nginx.test.conf exists on the daemon host
• if it didn’t exist, docker now created a directory at the path above; remove that directory and replace it with the file you’re trying to mount
• you can also use the --mount flag instead of -v / --volume: the --mount flag will not automatically create a directory if the host-path is missing, but instead produce an error, so that you’re aware the path (file/directory) on the host is missing.

Bind-mounting always happens from the host where the daemon runs, so even though the file may be present on your “client” machine; if that machine is a local machine, and not the machine where the daemon runs, bind-mounting won’t work.

Also note that if you are running docker-in-docker, the “daemon host” may be the container in which the daemon is running.

sudo update-grub "systemd.unified_cgroup_hierarchy=0" not helped. @tomwj

ubuntu 20.04:

$ sudo update-grub "systemd.unified_cgroup_hierarchy=0"
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-53-generic
Found initrd image: /boot/initrd.img-5.4.0-53-generic
Found linux image: /boot/vmlinuz-5.4.0-52-generic
Found initrd image: /boot/initrd.img-5.4.0-52-generic
Found Windows Boot Manager on /dev/sdb1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings
done


$ docker run --gpus all nvcr.io/nvidia/mxnet:20.10-py3
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"process_linux.go:432: running prestart hook 0 caused \\\"error running hook: exit status 1, stdout: , stderr: nvidia-container-cli: initialization error: nvml error: driver not loaded\\\\n\\\"\"": unknown.
ERRO[0000] error waiting for container: context canceled

@minaee docker flags should be put before the image name, otherwise they’re passed to the container as arguments for the container’s main process:

docker run [options] [image name] [arguments for container's process]

So in your case;

sudo docker run -it --rm busybox

same error here when running Hello-world docker version… Docker on Fedora 31

[ThaSami@localhost ~]$ docker run hello-world docker: Error response from daemon: OCI runtime create failed: container_linux.go:346: starting container process caused “process_linux.go:297: applying cgroup configuration for process caused "open /sys/fs/cgroup/docker/cpuset.cpus.effective: no such file or directory"”: unknown. ERRO[0009] error waiting for container: context canceled

I had the docker: Error response from daemon: oci runtime error: container_linux.go when trying to do:

sudo docker run hello-world

In my setup I’m using docker installed in WSL 1.

First of all I upgraded my Ubuntu VM from WSL 1 to 2, then inside WSL I did:

sudo apt update
sudo apt upgrade

Finally, I was able to run the sudo docker run hello-world and build every other Dockerfile.

sudo update-grub "systemd.unified_cgroup_hierarchy=0" not helped. @tomwj

ubuntu 20.04:

$ sudo update-grub "systemd.unified_cgroup_hierarchy=0"
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-53-generic
Found initrd image: /boot/initrd.img-5.4.0-53-generic
Found linux image: /boot/vmlinuz-5.4.0-52-generic
Found initrd image: /boot/initrd.img-5.4.0-52-generic
Found Windows Boot Manager on /dev/sdb1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings
done


$ docker run --gpus all nvcr.io/nvidia/mxnet:20.10-py3
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"process_linux.go:432: running prestart hook 0 caused \\\"error running hook: exit status 1, stdout: , stderr: nvidia-container-cli: initialization error: nvml error: driver not loaded\\\\n\\\"\"": unknown.
ERRO[0000] error waiting for container: context canceled

Same error on ubuntu 20.04

Had the same issue here on Manjaro 20.0.1 -> Docker version 19.03.8-ce -> Container centos:7

Solved it by doing: chmod+x entrypoint.sh from the host.

@akivanctp the original error reported is an invalid volume path (/ cannot be used as a volume). For other situations, see my comment above: TL;DR make sure that, when using bind-mounts, the path that you’re trying to mount exists.

same error, same arm64, same docker version

unsubscribe

This issue is a little old – but why not comment anyway ^_^

Earlier, I assigned a new mount on my system under /etc/fstab. When I unmounted ,I noticed the mounts were busy. I didn’t think of it and tried to mount again. The newly added mount was fine. I just ignored it and went on.

I later ran a container with a volume mount point (option -v ) on a local (not connected to any local mount points, btw) I got this lovely and inviting error. I discovered it was me who caused the error when I modified /etc/fstab and messed with the mounts. I nifty reboot helped when umounting failed.

Hope this helps.

looks some symlink removed from /dev, and the mobylinux crashed? so i have to reinstall docker?