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

Docker
1

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

(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

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 контейнеры со следующей ошибкой

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

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

2 лайка
start-samohosting ошибка net.ipv4.ip_unprivileged_port_start
LXC vs VM для докера и не только
Porteiner install permission denied
Установка IMMICH в LXC контейнер Proxmox
Вопросы новичков
2

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

Для Alpine Linux

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

В /etc/pve/lxc/XXX.conf

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

Для Ubuntu

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

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

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

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

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

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

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

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

(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)
1 лайк
3

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

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

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

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

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

5

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

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

Оказывается, что данное обсуждение ведется еще с 22 года, но сейчас стало максимально жестко. Proxmox проблему не признают и в очередной раз говорят, что LXC контейнеры не нужны, пользуйте виртуалки т.к. они всем лучше (кроме производительности, естественно), сообщество, естественно, сопротивляется.

LXC внесли правки для исправления данной проблемы, но они нехило так отключают правила AppArrmor, Proxmox считают это не фиксом, а :shit: собачим, и настаивают на использовании 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 к себе из апстрима и когда они это сделают, но они достаточно непрозрачно написали, что данная проблема для них не оказалась неожиданностью и они уже все написали в доке

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

image
image378×301 11 KB

Что несколько повышает привилегии docker внутри LXC контейнера, но в теории, должно компенсироваться AppArmor самого docker

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

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

2 лайка
6

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

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

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

7

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

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

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)

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

1 лайк
8

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

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

Ошибка после start-samohosting
9

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

2 лайка
10

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

3086
3086634×410 22.2 KB

Поправить удалось так: Failed Loading Environment · Issue #12925 · portainer/portainer · GitHub

11

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

image
image1656×481 64.7 KB

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

image
image1655×596 33.1 KB

По итогу сейчас на докере висят два контейнера от Portainer для обеспечения нормальной работы
image

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

image
image1624×241 40.1 KB

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

1 лайк
12

:man_dancing: :man_dancing: :man_dancing:

Подготовка к распаковке …/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 что в свою очередь включает в себя исправление данной проблемы. Вот коммит с фиксом

Мысли по поводу коммита

В отличие от оригинального коммита в 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
image1349×436 38.7 KB

image
image751×372 29.8 KB

5 лайков
13

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

14

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

1 лайк
15

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

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

16

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

image
image775×190 49.2 KB