служба не работает права изоляция диск

Read-only file system в журнале службы

Сообщение Read-only file system (номер 30, EROFS) значит, что запись запрещена не правами, а самой файловой системой. У служб systemd источника два: параметры изоляции в unit-файле и настоящее монтирование только для чтения — в том числе аварийное, из-за ошибок диска.

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

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

Изоляция unit-файла запрещает запись

ProtectSystem=strict делает весь корень доступным только для чтения, ProtectSystem=full — /usr и /boot, ReadOnlyPaths= — указанные пути. Права на диске при этом не меняются, и снаружи всё выглядит нормально.
Раздел смонтирован только для чтения

Так задано в /etc/fstab или так смонтирован образ. Частый случай для служб, которым нужно писать в /usr или в каталог со статикой.
Файловая система ушла в режим только для чтения из-за ошибок

При ошибках ввода-вывода ядро переводит раздел в защитный режим. Это уже не настройка, а авария: с диском или контроллером что-то не так.
Служба работает в контейнере с неизменяемым корнем

Образы часто запускают только для чтения, оставляя изменяемыми отдельные точки монтирования.

Диагностика

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

Показывает, действительно ли раздел смонтирован только для чтения.

findmnt -T /путь -o TARGET,SOURCE,FSTYPE,OPTIONS

Если монтирование в порядке, причина в изоляции самого unit-файла.

systemctl show myapp.service | grep -E "Protect|ReadOnly|ReadWrite"

Отличает настройку от аварии: при ошибках диска в журнале ядра всегда есть след.

journalctl -k -b --no-pager | grep -iE "I/O error|EXT4-fs error"

Решение

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

1. Изоляция unit-файла запрещает запись

Почему происходит: ProtectSystem=strict делает весь корень доступным только для чтения, ProtectSystem=full — /usr и /boot, ReadOnlyPaths= — указанные пути. Права на диске при этом не меняются, и снаружи всё выглядит нормально.

Как проверить

Посмотрите параметры изоляции службы.

systemctl show myapp.service | grep -E "ProtectSystem|ProtectHome|ReadOnlyPaths|ReadWritePaths"

Как исправить

Разрешите нужный путь через ReadWritePaths= или переведите данные в каталог службы: StateDirectory= всегда доступен для записи.

sudo systemctl edit myapp.service   # ReadWritePaths=/var/lib/myapp

2. Раздел смонтирован только для чтения

Почему происходит: Так задано в /etc/fstab или так смонтирован образ. Частый случай для служб, которым нужно писать в /usr или в каталог со статикой.

Как проверить

Посмотрите параметры монтирования нужного пути.

findmnt -T /путь -o TARGET,SOURCE,FSTYPE,OPTIONS

Как исправить

Перемонтируйте раздел для чтения и записи, если это допустимо, либо перенесите изменяемые данные на другой раздел.

sudo mount -o remount,rw /путь

3. Файловая система ушла в режим только для чтения из-за ошибок

Почему происходит: При ошибках ввода-вывода ядро переводит раздел в защитный режим. Это уже не настройка, а авария: с диском или контроллером что-то не так.

Как проверить

Посмотрите записи ядра и состояние диска.

journalctl -k -b --no-pager | grep -iE "I/O error|remount|EXT4-fs error|ata[0-9]"
sudo smartctl -H /dev/sda 2>/dev/null | head

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

4. Служба работает в контейнере с неизменяемым корнем

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

Как проверить

Определите окружение и разрешённые для записи пути.

systemd-detect-virt
mount | grep -E " / | /var " | head

Как исправить: Объявите нужный каталог томом или временной файловой системой в описании контейнера.

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

Служба с жёсткой изоляцией пытается писать в /etc. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

× myapp.service - My application
     Active: failed (Result: exit-code) since Mon 2026-09-15 16:14:02 MSK; 1s ago

myapp[7200]: error: cannot write /etc/myapp/state.json: read-only file system
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

Тут виновата не файловая система, а ProtectSystem=strict в unit-файле: для службы корень стал доступен только для чтения.

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

Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
status=226/NAMESPACE в systemd Код 226/NAMESPACE: не удалось настроить пространства имён монтирования, UTS или IPC. Частая причина — путь в ReadOnlyPaths= или ProtectHome=.
status=241/CONFIGURATION_DIRECTORY в systemd Код 241/CONFIGURATION_DIRECTORY: не удалось подготовить каталог настроек службы в /etc из ConfigurationDirectory=.
No space left on device в журнале службы Нет места на устройстве: разбор по свободным блокам, по inode, по журналу systemd и по удалённым, но открытым файлам.
Operation not permitted в журнале службы Операция запрещена: не хватает возможностей процесса, мешает seccomp или модуль безопасности. Отличие от Permission denied.
status=209/STDOUT в systemd Код 209/STDOUT: systemd не смог настроить стандартный вывод службы. Чаще всего виноват путь в StandardOutput=append: или file:.
status=210/CHROOT в systemd Код 210/CHROOT: не удалось сменить корневой каталог из RootDirectory= или подключить образ RootImage=.
status=218/CAPABILITIES в systemd Код 218/CAPABILITIES: не удалось применить набор возможностей процесса из CapabilityBoundingSet= или AmbientCapabilities=.

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

docker.service 7

Источники

systemd.exec(5)
ProtectSystem=, ReadOnlyPaths=, ReadWritePaths= и их влияние на запись. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено на ProtectSystem=strict и на разделе, смонтированном с ro. собственная проверка, systemd 255
сверено 15 сентября 2026