Снятие ограничений для Docker в Incus на Debian 13

[Admin]

Снятие ограничений для Docker в Incus на Debian 13

Введение

При запуске Docker внутри контейнера Incus (LXC) на Debian 13 можно столкнуться с ошибкой:

OCI runtime create failed:
open sysctl net.ipv4.ip_unprivileged_port_start file: permission denied

Эта ошибка возникает не из-за Docker, а из-за ограничений безопасности LXC-контейнера.

В данной статье объясняется, что именно блокируется и почему команда:

incus config set incus-jitsi security.privileged true
incus restart incus-jitsi

решает проблему.

---

Архитектура по умолчанию

Стандартная схема:

Host Debian 13
 └── Incus container (unprivileged)
       └── Docker
             └── Docker containers

По умолчанию Incus создаёт непривилегированные контейнеры (unprivileged).

Это означает:

• UID 0 внутри контейнера ≠ root на хосте
• используется user namespace
• запрещена запись в ряд файлов /proc/sys
• запрещены некоторые операции с cgroups
• ограничены сетевые sysctl

---

Почему Docker не запускался

Docker использует:

• namespaces
• cgroups
• overlayfs
• изменение sysctl
• runtime runc

При запуске контейнера runc применяет стандартные параметры OCI, включая попытку изменить:

/proc/sys/net/ipv4/ip_unprivileged_port_start

В unprivileged LXC:

• доступ к этому sysctl запрещён
• запись блокируется механизмами user namespace + AppArmor
• Docker получает permission denied

Даже если внутри контейнера вы root — это "виртуальный" root.

---

Что делает security.privileged true

Команда:

incus config set incus-jitsi security.privileged true

переключает контейнер в privileged режим.

После перезапуска:

incus restart incus-jitsi

контейнер:

• больше не использует user namespace
• UID 0 внутри контейнера = UID 0 на хосте
• получает расширенные права к /proc
• может изменять sysctl
• получает доступ к большему набору kernel capabilities
• снимаются ограничения на часть cgroup операций

Фактически контейнер становится максимально близким к полноценной виртуальной машине по правам (но без собственного ядра).

---

Почему это помогло Docker

После включения privileged:

• runc смог записать sysctl
• не произошло блокировки при reopen fd
• container init завершился успешно
• Docker-контейнер стартовал

То есть проблема была не в Docker, а в том, что LXC запрещал операции, необходимые для запуска вложенной контейнеризации.

---

Что именно было снято

При переходе в privileged режим:

Ограничение	До	После
User namespace	включён	отключён
UID mapping	remapped	прямой
Запись в /proc/sys	ограничена	разрешена
Kernel capabilities	урезаны	расширены
Работа Docker	частично блокируется	работает

---

Важное предупреждение

security.privileged=true снижает безопасность.

Контейнер:

• получает почти полный root-доступ к хосту
• может потенциально повлиять на систему
• не изолирован так строго, как unprivileged

Для production-систем рекомендуется:

• использовать security.nesting=true вместо privileged
• или запускать Docker в Incus VM (--vm)
• или запускать Docker непосредственно на хосте

---

Когда допустимо использовать privileged

• лабораторные стенды
• тестовые окружения
• разработка
• домашний сервер

Для публичных сервисов (например, Jitsi Meet) лучше рассмотреть VM.

---

Итог

Команда:

incus config set <container> security.privileged true

снимает ограничения user namespace и расширяет права контейнера до уровня, необходимого для полноценной работы Docker внутри Incus.

Это решает проблему запуска, но делает контейнер менее безопасным.

Оптимальный баланс между работоспособностью и безопасностью — security.nesting=true без privileged режима.