# Сломалась связка LXC-\>Docker с новыми версиями runc/containerd (например, Alpine v3.22, Ubuntu 24.04)

**URL:** <https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245>\
**Category:** Docker\
**Created:** [06.Ноябрь.2025 09:09:03 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245 "2025-11-06T09:09:03Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [06.Ноябрь.2025 09:09:03 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/1 "2025-11-06T09:09:03Z")

</div>

Сегодня после обновления пакетов в alpine 3.22

```auto
(1/11) Upgrading alpine-conf (3.20.0-r0 -> 3.20.0-r1)
(2/11) Upgrading runc (1.3.0-r3 -> 1.3.3-r0)
(3/11) Upgrading containerd (2.1.3-r2 -> 2.1.3-r3)
(4/11) Upgrading pcre2 (10.43-r1 -> 10.46-r0)
(5/11) Upgrading containerd-openrc (2.1.3-r2 -> 2.1.3-r3)
(6/11) Upgrading docker-engine (28.3.3-r2 -> 28.3.3-r3)
(7/11) Upgrading docker-openrc (28.3.3-r2 -> 28.3.3-r3)
(8/11) Upgrading docker-cli (28.3.3-r2 -> 28.3.3-r3)
(9/11) Upgrading docker-cli-buildx (0.24.0-r2 -> 0.24.0-r3)
(10/11) Upgrading docker (28.3.3-r2 -> 28.3.3-r3)
(11/11) Upgrading docker-cli-compose (2.36.2-r2 -> 2.36.2-r3)

```

И в ubuntu 24.04

```auto
containerd.io/noble 1.7.28-2~ubuntu.24.04~noble amd64 [upgradable from: 1.7.28-1~ubuntu.24.04~noble]
docker-ce-cli/noble 5:28.5.2-1~ubuntu.24.04~noble amd64 [upgradable from: 5:28.5.1-1~ubuntu.24.04~noble]
docker-ce-rootless-extras/noble 5:28.5.2-1~ubuntu.24.04~noble amd64 [upgradable from: 5:28.5.1-1~ubuntu.24.04~noble]
docker-ce/noble 5:28.5.2-1~ubuntu.24.04~noble amd64 [upgradable from: 5:28.5.1-1~ubuntu.24.04~noble]
docker-compose-plugin/noble 2.40.3-1~ubuntu.24.04~noble amd64 [upgradable from: 2.40.0-1~ubuntu.24.04~noble]

```

Перестали запускаться docker контейнеры со следующей ошибкой

```auto
traefik-pve-01:~# docker run --rm -it alpine:3.20 sh
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 3: permission denied

Run 'docker run --help' for more information

```

Аналогичное поведение на Ubuntu 24.04

- Вот [обсуждение](https://www.reddit.com/r/docker/comments/1op6e1a/impossible_to_run_docker/) на редите, там про debian говорится
- И вот [CVE](https://github.com/opencontainers/runc/issues/4968) в runc
- [Баг в Proxmox](https://bugzilla.proxmox.com/show_bug.cgi?id=7006)

Пока в процессе исправления

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [06.Ноябрь.2025 09:23:32 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/2 "2025-11-06T09:23:32Z")

</div>

Пока в качестве временного решения заработало добавление

**Для Alpine Linux**

```auto
lxc.apparmor.profile: unconfined
lxc.cap.drop:

```

В `/etc/pve/lxc/XXX.conf`

- `unconfined` снимает ограничения AppArmor.
- `lxc.cap.drop:` убирает сброс capability, включая доступ к sysctl.

**Для Ubuntu**

```auto
lxc.apparmor.profile: unconfined
lxc.cap.drop:

```

Исправляет данную проблему, но вылазит следующая

```auto
docker: Error response from daemon: Could not check if docker-default AppArmor profile was loaded: open /sys/kernel/security/apparmor/profiles: permission denied

```

Предлагается отключать apparmor для docker

```auto
docker run --rm --security-opt apparmor=unconfined alpine sh

```

Рабочие варианты не завелись

**Решил временно проблему откатом всего контейнера из бэкапа, благо у меня их на Ubuntu осталось несколько штук**  
Можно попобовать откатиться командой `apt install package=version`, но мне пока не до этого

Откатиться на старые версии пакетов на Alpine не смог т.к. они уже удалены из репозитория

**UPD 2025-11-09**  
Прилетело обновление в Alpine, но не помогло

```auto
(1/2) Upgrading containerd (2.1.3-r3 -> 2.1.5-r0)
(2/2) Upgrading containerd-openrc (2.1.3-r3 -> 2.1.5-r0)

```

---

<div class="post-metadata">

**Author:** ![Visteras](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/visteras/32/3129_2.png) [@Visteras](https://forum.samohosting.ru/u/Visteras)\
**Post date:** [07.Ноябрь.2025 07:14:12 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/3 "2025-11-07T07:14:12Z")

</div>

Вот вроде еще вариант советуют:

```auto
lxc.mount.entry: /dev/null sys/module/apparmor/parameters/enabled none bind 0 0
lxc.apparmor.profile: unconfined

```

> <https://github.com/opencontainers/runc/issues/4968#issuecomment-3500856059>
>
> \# TL; DR
> 
> This is caused by a design flaw in AppArmor when running runc (or Dock…er/Podman/containerd) inside a nested container that has an AppArmor profile applied (the very short explanation is that AppArmor incorrectly thinks that when runc accesses \`/proc/sys/...\` that it is accessing \`/sys/...\` and it rejects the access attempt because it violates the configured AppArmor policy).
> 
> We currently cannot work around this issue within runc, so other projects need to modify their AppArmor profiles to avoid this problem. As of 2025-11-17:
> 
> \* Incus has already been patched (in https://github.com/lxc/incus/pull/2624). You can switch to the daily builds to get a fixed version of Incus while you wait for the next release which will contain the fix (Incus 6.19).
> \* Proxmox has released a patched version of \`lxc-pve\` (\`6.0.5-2\`) which resolves the issue. Updating to this package (or newer) will resolve the issue.
> \* \*Direct\* users of LXC will still need to make use of the below workarounds (users of the default profile need to modify \`/etc/apparmor.d/abstractions/lxc/container-base\`, users of \`lxc.apparmor.profile = generated\` need to disable AppArmor or switch to the non-generated profile). The issue is being tracked in https://github.com/lxc/lxc/issues/4606.
> 
> \<details\>
> \<summary\>\<h2\>Outdated Workarounds\</h2\>\</summary\>
> 
> \## PLEASE DO NOT LEAVE COMMENTS IF THESE SOLUTIONS WORKED FOR YOU ##
> 
> \## LXC Users ##
> 
> This section applies to \*direct\* users of LXC.
> 
> You need to relax the \`/sys\` restrictions of the AppArmor profile used for LXC containers. The simplest way is to comment out all of the \`deny /sys\` lines in \`/etc/apparmor.d/abstractions/container-base\`:
> 
> \`\`\`
> % sudo sed -i.old '/deny \\/sys/ s/^/#/g' /etc/apparmor.d/abstractions/lxc/container-base
> % sudo apparmor\_parser -r /etc/apparmor.d/lxc-containers
> % # This should've worked, but you may need to restart your LXC containers.
> \`\`\`
> 
> This will disable the problematic \`/sys\` rules. You can also be more strategic by only changing the \`deny /sys/\[^fdc\]\*{,/\*\*} wklx\` rule to \`deny /sys/\[^fdcn\]\*{,/\*\*} wklx\` (to permit the \`net.ipv4.ip\_unprivileged\_port\_start\` sysctl to be written to) but this requires a bit more care.
> 
> If you use \`lxc.apparmor.profile = generated\` then unfortunately you will need to disable AppArmor (using \`lxc.apparmor.profile = unconfined\`) and wait for an LXC patch that fixes their internal hardcoded AppArmor profile. (This is the same boat Proxmox users find themselves in --see that section for some additional information.)
> 
> \## Incus Users ##
> 
> Incus generates its own AppArmor rules which you cannot directly modify. However, Incus has already been patched (in https://github.com/lxc/incus/pull/2624) so if you switch to the daily builds then the problem should already be resolved for you. Unfortunately there is no \`raw.lxc.\*\` workaround possible.
> 
> \## Proxmox Users ##
> 
> Similar to Incus, Proxmox generates its own AppArmor rules (using \`lxc.appamor.profile = generated\`) which you also cannot directly modify. However, Proxmox has released \`lxc-pve-6.0.5-2\` which includes a patch to resolve this issue.
> 
> \> \[!NOTE\]
> \> \[A bug report was opened for Proxmox\](https://bugzilla.proxmox.com/show\_bug.cgi?id=7006), along with \[a patch\](https://lore.proxmox.com/pve-devel/20251113130914.789691-1-f.gruenbichler@proxmox.com) which has been released in the repos. https://github.com/lxc/lxc/issues/4606 is tracking the issue for upstream LXC to improve its \`lxc.apparmor.profile = generated\` handling for nested containers.
> 
> As Proxmox makes use of \`lxc.apparmor.profile = generated\`, the above mitigations do not work (modifying the profiles in \`/etc/apparmor.d\` doesn't do anything because a new profile is generated automatically based on hard-coded strings in LXC). You instead need to add the following configuration to \`/etc/pve/lxc/$ctr.conf\`:
> 
> \`\`\`
> lxc.apparmor.profile: unconfined
> lxc.mount.entry: /dev/null sys/module/apparmor/parameters/enabled none bind 0 0
> \`\`\`
> 
> And restart the container.
> 
> The \`/dev/null\` bind-mount is needed in order to trick Docker into thinking that AppArmor is disabled on the system. If you do not include this line, you may see the error \`Error response from daemon: Could not check if docker-default AppArmor profile was loaded: open /sys/kernel/security/apparmor/profiles: permission denied\`. This is caused by a non-configurable security policy within AppArmor related to namespace nesting -- the only real solution for this is for the generated profile by LXC be fixed.
> 
> \> \[!NOTE\]
> \> The \`/dev/null\` bind mount may be unnecessary for some guests (some users have reported that Debian guests just work with \`lxc.apparmor.profile = unconfined\`).
> 
> \> \[!NOTE\]
> \> In principle you could configure a different AppArmor profile based on \`lxc-container-default-with-nesting\` and use that instead, but based on my testing the default profile doesn't permit \`overlayfs\` mounts -- fixing that is left as an exercise for the reader.
> 
> \## Regarding Downgrades ##
> 
> A lot of people have commented that they will just downgrade runc. If you are going to do this (instead of the far less drastic workarounds we've outlined above), please do not go overboard. runc \*\*1.2.7\*\* and \*\*1.3.2\*\* are the latest releases that \*do not\* contain the security patches which caused these errors. Downgrading to earlier versions than that (especially something as old as runc 1.1.0) is overkill and is needlessly opening yourself up to 4-year-old vulnerabilities.
> 
> I also want to re-iterate that while AppArmor can in principle protect against some attacks, by downgrading you are \*\*intentionally\*\* opening yourself up to actual attacks that we know exist (\*\*AND CAN BYPASS APPARMOR\*\* in the case of CVE-2025-52881).
> 
> \</details\>
> 
> \<details\>
> \<summary\>\<h2\>Detailed Analysis\</h2\>\</summary\>
> 
> There is an issue that has been reported when running runc inside LXC where the AppArmor profile for LXC causes permission errors when we try to re-open fds for procfs operations.
> 
> This was reported in https://github.com/containerd/containerd/issues/12484, https://github.com/moby/moby/issues/51405, and https://github.com/lxc/incus/issues/2623. Here is my breakdown of the cause:
> 
> \> Okay, I've figured it out. This is really dumb. tl;dr: This is really an AppArmor bug (or even a design flaw if you prefer).
> \> 
> \> For context, the file we are trying to write to is \`/proc/sys/net/ipv4/ip\_unprivileged\_port\_start\`. @stgraber figured out that the problematic AppArmor rules are the rules they have which block writing to most \*\*\`/sys\`\*\* files. How is it possible that one affects the other?
> \> 
> \> Well, the problem is that runc now uses a detached mount of \`procfs\` to operate on (this avoids mount race attacks). Because detached mounts have not been attached to the filesystem, \`d\_name\` (the kernel's facility for generating names for dentries) just generates a name that looks like \`/foo\` if you try to open a file \`foo\` inside the detached \`procfs\` mount. AFAICS this is what AppArmor uses to determine what file you are trying to write to (because AppArmor is path-based, and \`d\_name\` is the only way to get pathnames from dentries).
> \> 
> \> This means that when we try to write to \`/proc/sys/net/ipv4/ip\_unprivileged\_port\_start\`, AppArmor sees this as us trying to write to \`/sys/net/ipv4/ip\_unprivileged\_port\_start\` which is forbidden by the \`/sys\` denial rules. I have attached a program that can show this behaviour using a detached \`tmpfs\` mount, it's very trivial to trigger:
> \> 
> \> \`\`\`
> \> % ./aa-bug &
> \> c1:~ # ./aa-bug &
> \> fd: /proc/2061/fd/5
> \> \[1\] 2061
> \> c1:~ # mkdir /proc/2061/fd/5/sys
> \> c1:~ # mkdir /proc/2061/fd/5/sys/foo
> \> mkdir: cannot create directory ‘/proc/2061/fd/5/sys/foo’: Permission denied
> \> \`\`\`
> \> 
> \> \[aa-bug.go.txt\](https://github.com/user-attachments/files/23379918/aa-bug.go.txt)
> \> 
> \> There is a trivial workaround for this particular sysctl:
> \> 
> \> \`\`\`
> \> - deny /sys/\[^fdck\]\*{,/\*\*} wklx,
> \> + deny /sys/\[^fdckn\]\*{,/\*\*} wklx,
> \> \`\`\`
> \> 
> \> (In \`/etc/apparmor.d/abstractions/lxc/container-base\`.)
> \> 
> \> But this doesn't help in the general case for all sysctls. @stgraber has just submitted https://github.com/lxc/incus/pull/2624 which just removes these rules entirely. I think AppArmor should not do this, because it's incredibly broken (literally any detached mount could match against a rule by accident), but this is unfortunately how AppArmor's design works.
> \> 
> \> From runc's side, we could in theory use this to our advantage -- if we created a \`tmpfs\` with a subpath like \`.go-away-apparmor\` and then attached our procfs mount to that path, we might be able to subvert AppArmor. However, this has a risk of causing lifetime issues that would require a rework of how we do lookups -- the \`tmpfs\` must not be closed after we attach to it because it will lazy-unmount the procfs... 
> 
> \_Originally posted by @cyphar in \[#12484\](https://github.com/containerd/containerd/issues/12484#issuecomment-3494405793)\_
> 
> \</details\>

---

<div class="post-metadata">

**Author:** ![Visteras](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/visteras/32/3129_2.png) [@Visteras](https://forum.samohosting.ru/u/Visteras)\
**Post date:** [08.Ноябрь.2025 07:11:07 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/4 "2025-11-08T07:11:07Z")

</div>

Короче я для себя более простым образом решил сделать. Вот с этой версией [containerd.io](http://containerd.io) все работает корректно:

```auto
  - "containerd.io=1.7.28-1~debian.13~trixie"

```

В этом случае runc будет `runc version 1.3.0`, что тоже уберет проблему. Когда все починят просто уберу зависимость от конкретной версии `containerd.io`.

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [09.Ноябрь.2025 19:26:07 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/5 "2025-11-09T19:26:07Z")

</div>

В общем, чуть более глубоко погрузился в суть проблемы.

А подоплеку я описал еще 7 июля в соответствующем посте

> [@LXC vs VM для докера и не только](https://forum.samohosting.ru/t/lxc-vs-vm-dlya-dokera-i-ne-tolko/488):
>
> Навеено [статьей](https://pve.proxmox.com/wiki/Linux_Container) в официальной документации Что такое LXC контейнеры (CT в терминологии PVE) Это контейнеризация в Linux, которая работает аналогично docker, но при этом, если внутри docker контейнера по-умолчанию крутится 1 процесс, то LXC держит полноценный init (да?) c SSH и прочими ништяками, но при этом ядро ОС одно как для контейнера, так и для хоста Что такое KVM (VM в терминологии PVE) Это паравиртуализированная виртуальная машина, которая с точки зрения гостя является полностью независ…

Оказывается, что данное обсуждение ведется еще с 22 года, но сейчас стало максимально жестко. Proxmox проблему не признают и в очередной раз говорят, что LXC контейнеры не нужны, пользуйте виртуалки т.к. они всем лучше (кроме производительности, естественно), сообщество, естественно, [сопротивляется](https://bugzilla.proxmox.com/show_bug.cgi?id=7006#c3).

LXC [внесли правки](https://github.com/lxc/incus/pull/2624) для исправления данной проблемы, но они нехило так отключают правила AppArrmor, Proxmox считают это не фиксом, а 💩 собачим, и настаивают на использовании VM вместо CT, ну а если вы все еще хотите это использовать контейнеры, то вот там официальная дока

> **keyctl= (_default =_ 0)**  
> For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container. By default unprivileged containers will see this system call as non-existent. This is mostly a workaround for systemd-networkd, as it will treat it as a fatal error when some keyctl() operations are denied by the kernel due to lacking permissions. Essentially, you can choose between running systemd-networkd or docker.

Я не знаю, вольют ли Proxmox вышеобозначенный [PR](https://github.com/lxc/incus/pull/2624) к себе из апстрима и когда они это сделают, но они достаточно непрозрачно написали, что данная проблема для них не оказалась неожиданностью и они уже все написали в доке

Поэтому, на ближайшее время мы приходим к тому, что для запуска докера внутри CT контейнера надо выставлять вот такие опции

 ![image](https://forum.samohosting.ru/uploads/default/original/2X/0/0eeac2511f207f172b5defa8d20c31f7da134069.png)  
Что несколько повышает привилегии docker внутри LXC контейнера, но в теории, должно компенсироваться AppArmor самого docker

Либо даунгрейдить [containerd.io](http://containerd.io), но это тупиковая ветвь развития и не факт, что docker выкатят исправления со своей стороны

В Alpine мне это помогло, а в ubuntu все равно не хочет работать, пока разбираюсь с этим

---

<div class="post-metadata">

**Author:** ![Zandrex](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/zandrex/32/1181_2.png) [@Zandrex](https://forum.samohosting.ru/u/Zandrex)\
**Post date:** [10.Ноябрь.2025 10:13:29 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/6 "2025-11-10T10:13:29Z")

</div>

> [@Visteras](#):
>
> Вот вроде еще вариант советуют:
> 
> ```auto
> lxc.mount.entry: /dev/null sys/module/apparmor/parameters/enabled none bind 0 0
> lxc.apparmor.profile: unconfined
> 
> ```

Только сегодня столкнулся с данной проблемой.  
Помогло решение в виде этих дополнительных строк в конфиге контейнера

После этого сделал бекапы всех контейнеров, чтобы можно было откатиться 😅

Откат на “containerd.io=1.7.28-1~debian.13~trixie” почему-то не сработал - ругался, что не находит эту версию

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [10.Ноябрь.2025 10:28:32 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/7 "2025-11-10T10:28:32Z")

</div>

> [@Zandrex](#):
>
> Откат на “containerd.io=1.7.28-1~debian.13~trixie” почему-то не сработал - ругался, что не находит эту версию

а точно debian 13 стоит в контейнере?

Можно вот так посмотреть историю

```auto
root@netbox:~# cat /var/log/apt/history.log | grep containerd
Upgrade: containerd.io:amd64 (1.7.28-1~ubuntu.24.04~noble, 1.7.29-1~ubuntu.24.04~noble), docker-compose-plugin:amd64 (2.40.0-1~ubuntu.24.04~noble, 2.40.3-1~ubuntu.24.04~noble), docker-ce-cli:amd64 (5:28.5.1-1~ubuntu.24.04~noble, 5:28.5.2-1~ubuntu.24.04~noble), docker-ce:amd64 (5:28.5.1-1~ubuntu.24.04~noble, 5:28.5.2-1~ubuntu.24.04~noble), docker-ce-rootless-extras:amd64 (5:28.5.1-1~ubuntu.24.04~noble, 5:28.5.2-1~ubuntu.24.04~noble)
Commandline: apt install containerd.io=1.7.28-1~ubuntu.24.04~noble
Downgrade: containerd.io:amd64 (1.7.29-1~ubuntu.24.04~noble, 1.7.28-1~ubuntu.24.04~noble)

```

Тут видим, что в начале произошло обновление с одной версии на другую, а потом я из этого лога скопировал предыдущую версию и принудительно сдоунгрейдился на нее

---

<div class="post-metadata">

**Author:** ![Zandrex](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/zandrex/32/1181_2.png) [@Zandrex](https://forum.samohosting.ru/u/Zandrex)\
**Post date:** [10.Ноябрь.2025 10:39:03 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/8 "2025-11-10T10:39:03Z")

</div>

> [@KRom](#):
>
> Можно вот так посмотреть историю

Ага, увидел - не то пытался поставить. Причем помню, что версию пытался менять на 12, а вот про названия этих версий, который указываются дополнительно, забыл.

`Upgrade: containerd.io:amd64 (1.7.27-1, 1.7.29-1~debian.12~bookworm)`

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [10.Ноябрь.2025 22:36:19 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/9 "2025-11-10T22:36:19Z")

</div>

Видео на эту тему от tailscale

[![](https://forum.samohosting.ru/uploads/default/original/2X/5/5a32ac662837cc796960877449896db361048b26.jpeg "Docker containers not starting in LXCs recently? Here's a quick fix for you.") ](https://www.youtube.com/watch?v=5EFGHAcXh3c)

---

<div class="post-metadata">

**Author:** ![pavel.tryapinkov](https://forum.samohosting.ru/letter_avatar_proxy/v4/letter/p/e495f1/32.png) [@pavel.tryapinkov](https://forum.samohosting.ru/u/pavel.tryapinkov)\
**Post date:** [11.Ноябрь.2025 21:30:10 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/10 "2025-11-11T21:30:10Z")

</div>

При установке portainer, бил тоже ошибку.

 ![3086](https://forum.samohosting.ru/uploads/default/original/2X/a/abdfb0a5673602280377ca1ce6fa453e0ee14175.png)  
Поправить удалось так: [Failed Loading Environment · Issue #12925 · portainer/portainer · GitHub](https://github.com/portainer/portainer/issues/12925#issuecomment-3516549977)

---

<div class="post-metadata">

**Author:** ![Zandrex](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/zandrex/32/1181_2.png) [@Zandrex](https://forum.samohosting.ru/u/Zandrex)\
**Post date:** [12.Ноябрь.2025 10:38:29 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/11 "2025-11-12T10:38:29Z")

</div>

Оо… только вчера целый день промучился с этой ошибкой, правами на докер и на файл docker.sock и прочее..

 ![image](https://forum.samohosting.ru/uploads/default/original/2X/3/36d7d633c9126b7c833356f4a6090586ec1f50c7.png)

По итогу перед окончательным прощанием с Portainer решил подключиться через его агент и о чудо

 ![image](https://forum.samohosting.ru/uploads/default/original/2X/1/105fbf809c265b5922e262a48bf209022c6b77c2.png)  
По итогу сейчас на докере висят два контейнера от Portainer для обеспечения нормальной работы  
 ![image](https://forum.samohosting.ru/uploads/default/optimized/2X/f/fa858d67a9c559bab5460d619ecbacf6dcd71e08_2_690x45.png)

Тут даже видно, что методы подключения разные

 ![image](https://forum.samohosting.ru/uploads/default/original/2X/1/1e0ed8684a864970bab2e141cf66147e8048ddc4.png)

PS. Помня про проблему с Docker в LXC-контейнерах я всю эту систему изначально начал делать на VM, но чтобы сконнектить все ушло полдня…

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [17.Ноябрь.2025 02:12:32 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/12 "2025-11-17T02:12:32Z")

</div>

🕺 🕺 🕺

```auto
Подготовка к распаковке …/24-lxc-pve_6.0.5-3_amd64.deb …
Распаковывается lxc-pve (6.0.5-3) на замену (6.0.5-1) …

```

Обновление PVE 9.0.15 включает в себя lxc-pve 6.0.5-3 что в свою очередь включает в себя исправление данной проблемы. Вот [коммит с фиксом](https://lore.proxmox.com/pve-devel/20251113130914.789691-1-f.gruenbichler@proxmox.com/T/#u)

> **Мысли по поводу коммита**
>
> В отличие от оригинального коммита в LXC PVE решили проблему кардинально и пробросили весь `/proc` и `/sys` в контейнер, собственно, коммит называется
> 
> **skip /proc and /sys restrictions if nesting is enabled**  
> Что видится довольно таки существенным снижением безопасности
> 
> Далее комментарий к коммиту
> 
> > if nesting is enabled, it is already possible to mount a fresh instance of  
> > procfs and sysfs inside the container. protecting the original one does not  
> > make much sense in such a scenario, the kernel already protects the bits that  
> > are off-limits for unprivileged users anyway..
> > 
> > this fixes an issue with certain nested container setups, such as a recent  
> > enough runc nested inside LXC.
> 
> Т.е. предполагается, что ядро само будет разруливать доступ (запрет на запись) ФС для непривилегированных пользователей, а мы помним, что для непривилегированных контейнеров `unprivileged: 1` пользователь `root` имеет фактический id на хосте `100000`

Проверил на Alpine и Ubuntu - все работает как и должно. включать `keyctl` не надо, возможно, что надо будет перезапустить контейнеры для применения настроек.

- Можно откатывать отключение `apparmor` в настройках контейнера
- Можно обновлять `containerd.io` до последней версии

Поздравляю всех самохостят с данным событием.

11 дней потребовалось Proxmox для раскатки хотфикса. В тестовой сборке пользователи уже 14 ноября отписывались, что все поправили.

P.S.  
В качестве моральной компенсации за страдания и переход с LXC на VM в новой версии PVE добавили отображение IP адресаов LXC контейнеров как это реализовано для VM и даже лучше

> **Скриншоты**
>
> ![image](https://forum.samohosting.ru/uploads/default/original/2X/5/55fb4e9faf726fb61937279fa28cf99571681c33.png)  
> ![image](https://forum.samohosting.ru/uploads/default/original/2X/e/eb500826c16288a3fc53e439822fe7e26109539b.png)

---

<div class="post-metadata">

**Author:** ![Aleksei](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/aleksei/32/1578_2.png) [@Aleksei](https://forum.samohosting.ru/u/Aleksei)\
**Post date:** [17.Ноябрь.2025 09:59:03 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/13 "2025-11-17T09:59:03Z")

</div>

Обновляться через?  
apt dist-upgrade

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [17.Ноябрь.2025 10:00:26 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/14 "2025-11-17T10:00:26Z")

</div>

Да, стандартными средствами, или так или в веб интерфейсе.

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [25.Ноябрь.2025 19:47:44 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/15 "2025-11-25T19:47:44Z")

</div>

Только что выяснил, что проблему то поправили в PVE 9, а вот в 8.4.14 она наблюдается и Proxmox что-то не торопятся ее исправлять.

Еще один поводу обновить свое окружение до 9 версии

---

<div class="post-metadata">

**Author:** ![KRom](https://forum.samohosting.ru/user_avatar/forum.samohosting.ru/krom/32/362_2.png) [@KRom](https://forum.samohosting.ru/u/KRom)\
**Post date:** [07.Декабрь.2025 23:42:09 UTC](https://forum.samohosting.ru/t/slomalas-svyazka-lxc-docker-s-novymi-versiyami-runc-containerd-naprimer-alpine-v3-22-ubuntu-24-04/1245/16 "2025-12-07T23:42:09Z")

</div>

В PVE 8 прилетели обновления, возможно, что поправили работу с докером

 ![image](https://forum.samohosting.ru/uploads/default/original/2X/6/6c3006cffb632c82b541d547a3fdf76c658d9ad4.png)