SystemdDoctor
служба не работает частое изоляция пространства имён пути

status=226/NAMESPACE в systemd

Код 226/NAMESPACE systemd выдаёт, когда не сумел собрать изолированное представление файловой системы для службы. Это самый частый код среди «параметров безопасности»: обычно в ReadWritePaths=, ReadOnlyPaths= или BindPaths= указан путь, которого нет.

Что это значит

Перед запуском службы systemd создаёт для неё отдельное пространство имён монтирования и раскладывает в нём то, что описано параметрами изоляции: ProtectSystem=, ProtectHome=, PrivateTmp=, списки путей для чтения и записи. Любая невозможность выполнить один из шагов даёт 226.

Отдельно стоит помнить про порядок: сначала строится пространство имён, потом открывается вывод и запускается программа. Поэтому 226 приходит раньше, чем ошибки доступа к файлам внутри программы.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Путь из ReadWritePaths= или ReadOnlyPaths= не существует

    systemd пытается подключить указанный путь внутрь пространства имён. Несуществующий путь даёт отказ, если перед ним не стоит дефис.

  2. Ядро или контейнер не позволяют создать пространство имён

    Во вложенном контейнере без CAP_SYS_ADMIN построение пространства имён монтирования запрещено. Именно поэтому unit с ProtectSystem=strict работает на обычной машине и падает в контейнере.

  3. Противоречие между параметрами изоляции

    Например ProtectSystem=strict вместе с записью в /usr, или ProtectHome=yes при WorkingDirectory= в домашнем каталоге. Собрать такое пространство имён нельзя.

  4. Указано PrivateTmp=yes, а /tmp занят своим монтированием

    Если /tmp примонтирован особым образом (например только для чтения), подменить его на приватный каталог не получается.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

systemd называет проблемный путь прямо в сообщении — это самый быстрый способ найти виновника.

journalctl -xeu myapp.service --no-pager -n 30

Все параметры изоляции в одном выводе, включая пришедшие из drop-in.

systemctl show myapp.service | grep -E "Protect|Private|Paths|Temporary"

Показывает, какие настройки изоляции действуют у службы, и помогает понять, какую из них добавили последней.

sudo systemd-analyze security myapp.service | head -20

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Путь из ReadWritePaths= или ReadOnlyPaths= не существует
Почему происходит
systemd пытается подключить указанный путь внутрь пространства имён. Несуществующий путь даёт отказ, если перед ним не стоит дефис.
Как проверить
Посмотрите списки путей и проверьте каждый. 
systemctl show myapp.service | grep -E "ReadWritePaths|ReadOnlyPaths|InaccessiblePaths|BindPaths"
Как исправить
Создайте каталог или сделайте путь необязательным, поставив перед ним дефис: ReadWritePaths=-/var/lib/myapp. 
sudo install -d -o app -g app /var/lib/myapp
2. Ядро или контейнер не позволяют создать пространство имён
Почему происходит
Во вложенном контейнере без CAP_SYS_ADMIN построение пространства имён монтирования запрещено. Именно поэтому unit с ProtectSystem=strict работает на обычной машине и падает в контейнере.
Как проверить
Определите окружение. 
systemd-detect-virt
systemctl show myapp.service -p ProtectSystem -p PrivateTmp
Как исправить
Ослабьте изоляцию для этого окружения (ProtectSystem=no, PrivateTmp=no) или дайте контейнеру необходимые права.
3. Противоречие между параметрами изоляции
Почему происходит
Например ProtectSystem=strict вместе с записью в /usr, или ProtectHome=yes при WorkingDirectory= в домашнем каталоге. Собрать такое пространство имён нельзя.
Как проверить
Сопоставьте параметры изоляции с тем, куда служба обращается. 
systemctl show myapp.service | grep -E "Protect|Private|Temporary"
Как исправить
Разрешите нужные пути точечно через ReadWritePaths= вместо ослабления изоляции целиком.
4. Указано PrivateTmp=yes, а /tmp занят своим монтированием
Почему происходит
Если /tmp примонтирован особым образом (например только для чтения), подменить его на приватный каталог не получается.
Как проверить
Посмотрите монтирования /tmp. 
findmnt /tmp
Как исправить
Исправьте монтирование /tmp или отключите приватный /tmp для этой службы.

Пример вывода

В ReadWritePaths= указан несуществующий каталог. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

× myapp.service - My application
     Active: failed (Result: exit-code) since Mon 2026-09-14 22:01:37 MSK; 1s ago
    Process: 22040 ExecStart=/usr/local/bin/myapp (code=exited, status=226/NAMESPACE)

systemd[22040]: myapp.service: Failed to set up mount namespacing: /var/lib/myapp: No such file or directory
systemd[22040]: myapp.service: Failed at step NAMESPACE spawning /usr/local/bin/myapp: No such file or directory

Частые вопросы

Почему unit работает на сервере, но падает с 226 в контейнере?

Потому что построение пространства имён монтирования требует прав, которых в контейнере обычно нет. Для контейнера параметры изоляции приходится ослаблять: сам контейнер уже даёт изоляцию.

Связанные ошибки

  • status=210/CHROOT в systemd Код 210/CHROOT: не удалось сменить корневой каталог из RootDirectory= или подключить образ RootImage=.
  • status=225/NETWORK в systemd Код 225/NETWORK: не удалось создать сетевое пространство имён для службы при PrivateNetwork=yes или NetworkNamespacePath=.
  • status=233/RUNTIME_DIRECTORY в systemd Код 233/RUNTIME_DIRECTORY: не удалось подготовить каталог службы в /run из RuntimeDirectory=. Права, режим, удаление при остановке.
  • status=209/STDOUT в systemd Код 209/STDOUT: systemd не смог настроить стандартный вывод службы. Чаще всего виноват путь в StandardOutput=append: или file:.
  • Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
  • No such file or directory в журнале службы Служба не находит файл или каталог. Разбор: путь, момент запуска, изоляция unit-файла, символические ссылки, приватный /tmp.
  • status=200/CHDIR в systemd Код 200/CHDIR означает, что systemd не смог перейти в каталог из WorkingDirectory= до запуска программы. Причины и решение.
  • status=203/EXEC в systemd Код 203/EXEC означает, что systemd не смог выполнить программу из ExecStart=. Разбор причин: путь, права, интерпретатор, синтаксис оболочки.

Где встречается чаще всего

Источники

  • systemd.exec(5)
    226 EXIT_NAMESPACE: не удалось настроить пространства имён монтирования, UTS или IPC.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на ReadWritePaths с несуществующим каталогом и на ProtectSystem=strict внутри контейнера.     собственная проверка, systemd 255
    сверено 15 сентября 2026