Docker fails to run on Debian (bullseye) after update "unable to start container process: error during container init: open sysctl net.ipv4.ip_unprivileged_port_start file: reopen fd 8: permission denied: unknown"

Docker Engine General
,
1

Fatal Docker Error after running an apt-get update.
No containers were [re]started and they returned the following error when trying to start manually:

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: open sysctl net.ipv4.ip_unprivileged_port_start file: reopen fd 8: permission denied: unknown

Tested with docker run hello world and it showed the same error.

Environment:

Proxmox 8.4.14
LXC running Debian GNU/Linux 11 (bullseye) x86_64
Kernel: 6.8.12-11-pve

After checked against an alternate LXC with working docker (pre-update).

apt-cache policy docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin | grep -i installed

Updated LXC:

docker-ce Installed: 5:28.5.2-1~debian.11~bullseye
docker-ce-cli Installed: 5:28.5.2-1~debian.11~bullseye
containerd.io Installed: 1.7.29-1~debian.11~bullseye
docker-buildx-plugin Installed: 0.29.1-1~debian.11~bullseye
docker-compose-plugin Installed: 2.40.3-1~debian.11~bullseye

The working LXC:

docker-ce Installed: 5:28.0.0-1~debian.11~bullseye
docker-ce-cli Installed: 5:28.0.0-1~debian.11~bullseye
containerd.io Installed: 1.7.25-1
docker-buildx-plugin Installed: 0.21.0-1~debian.11~bullseye
docker-compose-plugin Installed: 2.33.0-1~debian.11~bullseye

Rolled back each in turn followed by a systemctl restart docker ; docker run hello world until it ran without error..

It wasn’t until I rolled back docker-ce and containerd.io that the hello world test was successful.
docker-ce on it’s own didn’t fix it and containerd.io on it’s own didn’t fix it. It needed to be both

So, I went through the apt-cache for all the versions and this is the newest combination that works.

docker-ce=5:28.3.3-1~debian.11~bullseye
containerd.io=1.7.28-1~debian.11~bullseye

This and future caused docker containers to fail.

docker-ce=5:28.4.0-1~debian.11~bullseye
containerd.io=1.7.28-2~debian.11~bullseye

C

1 Like
2

As of this moment this is what I have to keep it running and prevent it from updating

sudo apt-get install docker-ce=5:28.3.3-1~debian.11~bullseye containerd.io=1.7.28-1~debian.11~bullseye
sudo apt-mark hold docker-ce=5:28.3.3-1~debian.11~bullseye containerd.io=1.7.28-1~debian.11~bullseye
1 Like
3

Thank you for sharing it with the community.

Though, please do mention that you are using Proxmox 8, as we lately had topics about Proxmox 9 where people tried to run docker-ce on the hypervisor itself. It was (is still?) not working due to differences between vanilla Debian 13 and Proxmox 9.

If you want to raise an issue, so the developers can see it, you might want to post it where devs can notice it: in docker’s upstream project Moby:

4

I had the same issue with an LXC Debian 12 container on Proxmox 9. The fix worked, just had to change it for Debain 12. Thanks for figuring this out!!!

1 Like
5

Same issue here with Debian Bookworm running in an unprivileged LXC on Proxmox 8.4.14.
Ran apt-get and apt-mark commands and now works.

6

Debian 13 and LXC. Yeah this is really annoying, hope there’s a permanent fix that isn’t holding back packages and not being able to upgrade containerd. io. The follwing is enough.

apt-hold containerd.io
apt install containerd.io=1.7.28-1~debian.13~trixie

ps. this is still a problem with the newest version (from 12th of november 2025)

docker-ce-cli amd64 5:29.0.0-1~debian.13~trixie
containerd. io amd64 2.1.5-1~debian.13~trixie
docker-ce amd64 5:29.0.0-1~debian.13~trixie
docker-ce-rootless-extras amd64 5:29.0.0-1~debian.13~trixie

pps. it is also possible to solve this by running apt-mark hold runc, but isn’t recommended (due to it being further in the execution stack - as I understand it.)

ppps. it is also possible to run lxc-container config with lxc.apparmor.profile: unconfined but isn’t recommended since this lowers security. Can be done if services only available on LAN (read: not Internet facing).

7

Hi meyay
It’s Proxmox 8 (.4.14) as per my initial post :slight_smile:
I wouldn’t dare put docker on the node. I save all that for LXC and VMs :slight_smile:

I’ll follow you advice and raise it as an issue if someone hasn’t already beaten me to it.

1 Like
8

Thanks for checking the latest.

I agree the apt-mark hold isn’t ideal, but I did it purely to allow other packages to update without breaking docker.

9

Raised in Github as requested/suggested

1 Like
10

Last update from me (probably)
The issue was closed in Github as a duplicate, but I followed the trail and it seems to be caused by a [mis]configuration error in AppArmour.

The Hotfix to resolve it is to switch off AppArmour
This should be safe to do as long as you don’t install 3rd party containers.

If you run third-party images or allow untrusted users access to spawn containers, DO NOT downgrade . This [AppArmour] update was a security update which fixed THREE container escape vulnerabilities that can be triggered by untrusted images or docker build .

The Hotfix:
Log into the LXC and run:

sudo mount --bind /dev/null /sys/module/apparmor/parameters/enabled
sudo systemctl restart docker

Then add adding the below setting in the host/node: /etc/pve/lxc/[LXC].conf

lxc.apparmor.profile=unconfined

Restart the LXC, unhold the 2 docker components, app update and docker still works :raising_hands:

Github investigation for reference

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.