Fehler mit Docker Container nach Linux update

L

luak

New Member
Nov 6, 2025
2
0
1
Hallo zusammen.
Ich habe heute meine Linux Maschinen (Ubuntu und Debian, laufen jeweils als CT) in einer Proxmox Umgebung upgedatet.
Seitdem laufen die Docker Container nicht mehr.

Fehler ist:
"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"

Das Thema wird schon sehr stark auf GitHub in verschiedenen Beiträgen diskutiert. Und soll ein Proxmox Problem sein.

Ich bin leider nicht so gut im Linux Thema. Daher kann ich es nicht genau sagen woran es liegt.
Habt Ihr das Problem auch ?
Hat schon jemand eine Lösung dafür ?
 
lynze

Thread 'Docker inside LXC (net.ipv4.ip_unprivileged_port_start error)'

Be careful when updating Docker on Proxmox LXC machines (as far as I know): when you run apt update&&apt upgrade, among other packages, containerd.io is updated to 1.7.28-2~debian.13~trixie, so if you try to launch your containers, you will get the following error:

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
Click to expand...

So your...
  • Like
 
  • Like
Reactions: Johannes S and luak
Nun ja aus der ProxmoxVE Dokumentation zu lxcs:

If you want to run application containers, for example, Docker images, it is recommended that you run them inside a Proxmox QEMU VM. This will give you all the advantages of application containerization, while also providing the benefits that VMs offer, such as strong isolation from the host and the ability to live-migrate, which otherwise isn’t possible with containers.
https://pve.proxmox.com/wiki/Linux_Container
Click to expand...

Es ist ein bekanntes Problem, dass bei größeren Updates docker-Container in LXC-Containern immer mal wieder kaputt gehen. Beide nutzen die gleichen Teile des Kernels, daher ist das im Endeffekt nicht überraschend. Einige Beispiele:

Meistens gab es dann irgendwann dann einen Bugfix oder einen (mehr oder weniger häßlichen) Workaround (meistens lief das auf das Deaktivieren von Sicherheitsmechanismen hinaus, so eine "Lösung" ist keine), womit es dann wieder geht.

Wenn man (wie ich) auf ein derartiges Glücksspiel plus anschließenden Gefrickel keine Lust hat: docker-/podman-Container in einer VM installieren, das ist deutlich stressfreier.

Wenn man (warum auch immer) lieber einen Linux-Container benutzen will, schauen ob die Anleitung der zu betreibenden Software beschreibt, wie man das ganze ohne docker zum Fliegen kriegt, bei pihole oder jellyfin klappt das zum Beispiel ganz gut.
 
  • Like
Reactions: bl1mp, micneu, RolandK and 2 others
Johannes S said:
mehr oder weniger häßlichen) Workaround (meistens lief das auf das Deaktivieren von Sicherheitsmechanismen hinaus, so eine "Lösung" ist keine)
Click to expand...
Damit hast du zu 100% ins schwarze getroffen. Es wird - als Workaround - heftig an "apparmour" herumgedoktort ... :)
 
  • Like
Reactions: Johannes S
Ernst T. said:
Damit hast du zu 100% ins schwarze getroffen. Es wird - als Workaround - heftig an "apparmour" herumgedoktort ... :)
Click to expand...
Genau und weil ich auf solches (nicht nur umständliches, sondern auch potentiell gefährliches) Gefrickel keine Lust habe, lasse ich die Finger von docker-Containern in lxcs ;) Nun kann docker einen natürlich auch in VMs mal durch ein Update kaputt gehen, aber es kommt doch deutlich seltener vor. Im Zweifelsfall verbrauche ich lieber mehr Ressourcen durch VMs als wertvolle Lebenszeit, aber das muss natürlich jede/r für sich selbst entscheiden, was wichtiger ist :)
 
  • Like
Reactions: meyergru
ich hab 4 lxc mit docker am Laufen und zwei VM, bis her sogut wie keine Probleme gehabt damit, das mal ein Paket nen Problem verursacht kann ja immer mal passieren aber da kann man ja einfach nen rollback machen und auf nen fix warten, das seh ich nicht so kritisch, kommt halt immer drauf an auf was man Wert legt, da fast alles für den nicht produktiven Homebereich läuft bei mir ist das nicht so tragisch
 
bluesite said:
das Problem lag am containerd.io es gab heute schon ein Update das den Fehler behoben hat
siehe Thread
Click to expand...

Ein Downgrade ist keine Fehlerbehebung.
So wie es aussieht, wird das Problem nicht offiziell behoben werden.

Man hat daher 3 Möglichkeiten:
  1. Man bleibt dauerhaft bei containerd.io Version 1.7.28-1 und verzichtet auf alle weiteren Updates dieses Paketes.
  2. Man stellt von LXC Container auf VM um.
  3. Man entschärft AppArmour wie folgt:
  • Einfügen von "lxc.apparmor.profile=unconfined" in die LXC Config-Datei /etc/pve/lxc/LXCID.conf am Proxmox-Host.
  • Neustart des Containers.
  • Ausführen folgender Befehle als root im LXC Container:
Code: 
% mount --bind /dev/null /sys/module/apparmor/parameters/enabled
% systemctl restart docker

Danach kann man die Docker Container problemlos neu starten, obwohl man eine neuere Containerd.io Version verwendet.

Erklärung des Problems:
In short, the problem is that Proxmox uses lxc.apparmor.profile = generated which uses a profile hardcoded in the LXC binary (which you cannot practically change as an admin). Switching to a different profile results in errors when Docker tries to access /sys/kernel/security/apparmor/profiles (this is a property of a more generic security policy in AppArmor that you cannot disable, that is related to AppArmor profile stacking). The above tricks Docker into not trying to access the file by thinking that AppArmor is disabled.
 
Last edited:
echtarg said:
Einfügen von "lxc.apparmor.profile=unconfined" in die LXC Config-Datei /etc/pve/lxc/LXCID.conf am Proxmox-Host.
Click to expand...
Das ist keine "Entschärfung", sondern deaktiviert AppArmor komplett für den Container. Da kann ich auch meine Alarmanlage ausschalten, weil die ja immer so nervigen Lärm macht, wenn ich das Fenster statt der Tür nutze.

Und nicht updaten ist auch vieles, aber keine vertretbare Lösung, darüber können sich nur Hacker freuen.

bluesite said:
ich hab 4 lxc mit docker am Laufen und zwei VM, bis her sogut wie keine Probleme gehabt damit, das mal ein Paket nen Problem verursacht kann ja immer mal passieren aber da kann man ja einfach nen rollback machen und auf nen fix warten, das seh ich nicht so kritisch, kommt halt immer drauf an auf was man Wert legt, da fast alles für den nicht produktiven Homebereich läuft bei mir ist das nicht so tragisch
Click to expand...
Schön, dass es für dich kein Problem macht oder du mit derartigen Gefrickel leben kannst. Es soll aber Leute geben, denen ihre Lebenszeit wichtiger ist, als Ressoucen auf einen Server zu sparen, der eh die ganze Zeit läuft. Und auch im Homebereich kann es kritische Anwendungen geben, sei es weil sonst die Familie unglücklich ist oder ( wie bei mir ) wichtige Unterlagen im paperless gespeichert sind.

Das ist der Grund, warum ich auf derartige Praktiken allergisch reagiere: Ich unterstelle, dass ich nicht der Einzige bin, dem Zuverlässigkeit sehr wichtig ist, dann sollte man von docker in lxcs die Finger lassen. Auch wenn einen Leute in Foren oder auf reddit sagen, dass das schon klar geht
 
  • Like
Reactions: meyergru and UdoB
echtarg said:
Ein Downgrade ist keine Fehlerbehebung.
So wie es aussieht, wird das Problem nicht offiziell behoben werden.

Man hat daher 3 Möglichkeiten:
  1. Man bleibt dauerhaft bei containerd.io Version 1.7.28-1 und verzichtet auf alle weiteren Updates dieses Paketes.
  2. Man stellt von LXC Container auf VM um.
  3. Man entschärft AppArmour wie folgt:
  • Einfügen von "lxc.apparmor.profile=unconfined" in die LXC Config-Datei /etc/pve/lxc/LXCID.conf am Proxmox-Host.
  • Neustart des Containers.
  • Ausführen folgender Befehle als root im LXC Container:
Code: 
% mount --bind /dev/null /sys/module/apparmor/parameters/enabled[/INDENT][/INDENT][/INDENT]
[INDENT][INDENT][INDENT]% systemctl restart docker

Danach kann man die Docker Container problemlos neu starten, obwohl man eine neuere Containerd.io Version verwendet.

Erklärung des Problems:
In short, the problem is that Proxmox uses lxc.apparmor.profile = generated which uses a profile hardcoded in the LXC binary (which you cannot practically change as an admin). Switching to a different profile results in errors when Docker tries to access /sys/kernel/security/apparmor/profiles (this is a property of a more generic security policy in AppArmor that you cannot disable, that is related to AppArmor profile stacking). The above tricks Docker into not trying to access the file by thinking that AppArmor is disabled.
Click to expand...
es gab doch schon ein Update des Pakets danach lief bei mir wieder alles ohne Probleme, ich brauch es im lxc da ich sonst meine Grafikkarte nicht nutzen kann im Kontainer und keine Slots frei habe um eine zweite Karte einbauen zu können.

containerd.io/trixie,now 1.7.29-1~debian.13~trixie amd64 [installiert]

Und ich habe keinen gezwungen das er docker in einem lxc laufen lässt das kann ja jeder machen wie er möchte
 
Last edited:
bluesite said:
es gab doch schon ein Update des Pakets danach lief bei mir wieder alles ohne Probleme, ich brauch es im lxc da ich sonst meine Grafikkarte nicht nutzen kann im Kontainer und keine Slots frei habe um eine zweite Karte einbauen zu können.

containerd.io/trixie,now 1.7.29-1~debian.13~trixie amd64 [installiert]

Und ich habe keinen gezwungen das er docker in einem lxc laufen lässt das kann ja jeder machen wie er möchte
Click to expand...
wo wurde was veröffentlicht ? Meine bisherigen Update versuche bringen leider nichts
 
containerd.io/trixie,now 1.7.29-1~debian.13~trixie amd64 [installiert] <- das hier hatte ich gestern installiert
containerd.io/trixie 1.7.28-2~debian.13~trixie amd64 <- das hier war fehlerhaft und kam am 5.11. raus
containerd.io/trixie 1.7.28-1~debian.13~trixie amd64

ich habe allerdings eigene Docker quellen drin bei mir

Code: 
Types: deb
URIs: https://download.docker.com/linux/debian/
Suites: trixie
Components: stable
Signed-By: /etc/apt/keyrings/docker.gpg
 
Ab containerd.io 1.7.29 läuft es nicht mehr im LXC container.

Lösen muss das Problem AppArmor, allerdings ist das leider sehr unwahrscheinlich.

Somit bleiben die 3 von mir oben geschilderten Möglichkeiten. Mit einer davon muss man künftig leben, will man Docker im LXC container ausführen.
 
Eventuell einfach mal aufhören mit Container in Container. Wenn man statt LXC so wie es empfohlen wird, eine VM für Docker nutzt, habe ich noch nie Probleme gehabt.
 
  • Like
Reactions: meyergru, Johannes S and UdoB
lynze

Thread 'Docker inside LXC (net.ipv4.ip_unprivileged_port_start error)'

Be careful when updating Docker on Proxmox LXC machines (as far as I know): when you run apt update&&apt upgrade, among other packages, containerd.io is updated to 1.7.28-2~debian.13~trixie, so if you try to launch your containers, you will get the following error:

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
Click to expand...

So your...
  • Like

Tutorals Docker Compose Fix Debian oder Ubuntu Bug

apt install docker.io

fehler
/tmp/apt-dpkg-install-gYJjDA/08-docker-buildx_0.13.1+ds1-3_amd64.deb

Sub-process /usr/bin/dpkg returned an error code(1)

sudo dpkg --configure -a


apt update && apt upgrade

apt dist-upgrade

Habe das so wieder zu laufen bekommen.
 
  • Like
Reactions: gr3n
Falk R. said:
Eventuell einfach mal aufhören mit Container in Container. Wenn man statt LXC so wie es empfohlen wird, eine VM für Docker nutzt, habe ich noch nie Probleme gehabt.
Click to expand...
Wenn man das kann, ich habe seit vielen Jahren Proxmox bei Netcup auf einem Root Server laufen, leider wird aber die Virtualisierung nicht weitergereicht so das nur LXC möglich ist. Warum nutze ich das? separieren von Diensten und Datensicherung mit Proxmox (alles privater kram). Ich denke für mich ist der beste Weg auf Docker zu verzichten.
 
talos said:
Wenn man das kann, ich habe seit vielen Jahren Proxmox bei Netcup auf einem Root Server laufen, leider wird aber die Virtualisierung nicht weitergereicht so das nur LXC möglich ist. Warum nutze ich das? separieren von Diensten und Datensicherung mit Proxmox (alles privater kram). Ich denke für mich ist der beste Weg auf Docker zu verzichten.
Click to expand...
Das ist dann die korrekte Schlussfolgerung oder den Anbieter wechseln. ;)
 
  • Like
Reactions: Johannes S
echtarg said:
Ein Downgrade ist keine Fehlerbehebung.
So wie es aussieht, wird das Problem nicht offiziell behoben werden.

Man hat daher 3 Möglichkeiten:
  1. Man bleibt dauerhaft bei containerd.io Version 1.7.28-1 und verzichtet auf alle weiteren Updates dieses Paketes.
  2. Man stellt von LXC Container auf VM um.
  3. Man entschärft AppArmour wie folgt:
  • Einfügen von "lxc.apparmor.profile=unconfined" in die LXC Config-Datei /etc/pve/lxc/LXCID.conf am Proxmox-Host.
  • Neustart des Containers.
  • Ausführen folgender Befehle als root im LXC Container:
Code: 
% mount --bind /dev/null /sys/module/apparmor/parameters/enabled[/INDENT]
[INDENT]% systemctl restart docker

Danach kann man die Docker Container problemlos neu starten, obwohl man eine neuere Containerd.io Version verwendet.

Erklärung des Problems:
In short, the problem is that Proxmox uses lxc.apparmor.profile = generated which uses a profile hardcoded in the LXC binary (which you cannot practically change as an admin). Switching to a different profile results in errors when Docker tries to access /sys/kernel/security/apparmor/profiles (this is a property of a more generic security policy in AppArmor that you cannot disable, that is related to AppArmor profile stacking). The above tricks Docker into not trying to access the file by thinking that AppArmor is disabled.
Click to expand...
Hi @echtarg
Ich habe dasselbe Problem mit meiner Paperless Installation unter docker in einem Debian lxc. Ich würde das gerne auf eine VM umziehen. Hast Du einen Tipp, wie das am besten geht?
 
FlyByWire said:
Ich habe dasselbe Problem mit meiner Paperless Installation unter docker in einem Debian lxc. Ich würde das gerne auf eine VM umziehen. Hast Du einen Tipp, wie das am besten geht?
Click to expand...

VM mit beliebiger Linux VM aufsetzen ( ich nehme dafür gerne Debians cloud images: https://www.thomas-krenn.com/de/wiki/Cloud_Init_Templates_in_Proxmox_VE_-_Quickstart Das Tutorial verweist aber noch auf Debian12, besser Debian 13 nehmen), da dann docker installieren ( https://docs.docker.com/engine/install/debian/ ) und damit dann die Anleitung von paperless abarbeiten ( https://docs.paperless-ngx.com/setup/ ).
 
Last edited:
  • Like
Reactions: meyergru and FlyByWire
You must log in or register to reply here.
Top Bottom