Unable to start container process

Docker Hub
1

Error response from daemon: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error closing exec fds: get handle to /proc/thread-self/fd: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: function not implemented: unknown
Error: failed to start containers: 8810bc44a6wq

Hi everyone,

I was trying to restart my postgres container and is getting above error.
It was working till last week. Then I had to restart docker this week and try container restart.
My linux kernel version is 5.14
runc version is 1.2.5
docker version is 19.03

Any idea why this is happening and please drop if any known solutions

2

Seeing the same thing here:

[me@host ~]$ docker run -i -t --rm dokken/centos-stream-9:sha-03eabbc /bin/bash
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error closing exec fds: get handle to /proc/thread-self/fd: unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: function not implemented

Run 'docker run --help' for more information

Kernel version:

[me@host ~]$ uname -r
5.14.0-460.el9.aarch64

docker-ce version:

[me@host ~]$ rpm -q docker-ce
docker-ce-29.0.2-1.el9.aarch64

docker-ce was updated at 6:16 AM CST this morning:

[me@host ~]$ sudo dnf history list docker-ce 
ID     | Command line              | Date and time    | Action(s)      | Altered
--------------------------------------------------------------------------------
   398 |                           | 2025-11-19 06:16 | Upgrade        |  119 EE
[...]
3

Docker 19.03 is pretty old and not supported, but I see that @amoate has a recent version, but we know there was an update before the issue. Did you also have any update on your system, like updating runc itself? The version you are using is from this february. while the Docker version is more than 4 years old. If runc or containerd was updated in both cases, that component could cause the issue and you could try downgrading it until you figure out a better solution.

4

It turns out this has been happening on our system since Nov 6th 2025; this dnf transaction appears to be the culprit:

[me@host ~]$ sudo dnf history info  391
Transaction ID : 391
Begin time     : Thu 06 Nov 2025 06:50:23 AM CST
Begin rpmdb    : 957e23af59680c9958c3f4faac751ee223992c87404c5317cf6d04ad2ec4fa01
End time       : Thu 06 Nov 2025 06:50:25 AM CST (2 seconds)
End rpmdb      : 672dac9b3c3f30470232c0b2d8a5cd8ff98cc08255766aade883f5e1948c77cf
User           : System <unset>
Return-Code    : Success
Releasever     : 9
Command Line   : 
Persistence    : Unknown
Comment        : 
Packages Altered:
    Upgrade  containerd.io-1.7.28-2.el9.aarch64 @docker_ce_9_aarch64_stable_local
    Upgraded containerd.io-1.7.28-1.el9.aarch64 @@System
    Upgrade  CGSI-gSOAP-1.3.13-1.el9.aarch64    @epel_9_aarch64_local
    Upgraded CGSI-gSOAP-1.3.12-1.el9.aarch64    @@System

So Iā€™m blaming containerd.io-1.7.28-2.el9; I downgraded to containerd.io-1.7.28-1.el9 and:

[me@host ~]$ docker run -i -t --rm dokken/centos-stream-9:sha-03eabbc /bin/bash
[root@9cb5474d4d93 /]#
1 Like
5

Thanks for sharing the result.

@judson2000 can you also share your containerd version?

6

We can now point the blame out our own docker configuration. This changelog entry popped up in a Google search and indicated a problem in seccomp.json:

Background
Due to recent runc security fixes (for CVE-2025-31133, CVE-2025-52881, and CVE-2025-52565), you must manually update your agentsā€™ seccomp profiles so that they will operate properly.

Without this update, your agents will eventually encounter the following error:
unsafe procfs detected: openat2 fsmount:fscontext:proc/thread-self/fd/: <err>

Our docker configurationā€™s seccomp-profile is pointed at /etc/docker/seccomp.json;

[me@host ~]$ sudo cat /etc/docker/daemon.json
{
  [...]
  "seccomp-profile"  : "/etc/docker/seccomp.json",
  [...]
}

Iā€™m not sure what provides/etc/docker/seccomp.json, but itā€™s not directly provided by an RPM:

[me@host ~]$ rpm -q -f /etc/docker/seccomp.json
file /etc/docker/seccomp.json is not owned by any package

The containers-common RPM provides a different /usr/share/containers/seccomp.json

[me@host ~]$ dnf provides '*/seccomp.json'
[...]
containers-common-2:1-8.el9.noarch : Common configuration and documentation for containers
Repo        : AppStream_local
Matched from:
Filename    : /usr/share/containers/seccomp.json
[...]

/usr/share/containers/seccomp.json seems to have a lot more system calls listed in .syscalls.[].names than /etc/docker/seccomp.json, among them openat2:

[me@host ~]$ jq -r -s '[(.[0], .[1]) | .syscalls | map(.names) | add | unique] | .[1] - [.0]' /etc/docker/seccomp.json /usr/share/containers/seccomp.json
[
  [...]
  "openat2",
  [...]
]

So we pointed seccomp-profile to /usr/share/containers/seccomp.json:

[me@host ~]$ cat /etc/docker/daemon.json
{
  "seccomp-profile"  : "/usr/share/containers/seccomp.json",
  [...]
}

And updated to the latest containerd.io:

[me@host ~]$ rpm -q containerd.io
containerd.io-2.1.5-1.el9.aarch64

And restarted the docker service to get it to re-read /etc/docker/daemon.json. Now:

[me@host ~]$ docker run -i -t --rm dokken/centos-stream-9:sha-03eabbc /bin/bash
[root@a957ec0cd80d /]#

Long story short, seccomp.json hast to be modernized at least to include settings for the openat2 system call.

1 Like