Keep declared service state writable under ProtectSystem=strict

Identify the service’s real write locations before weakening a systemd filesystem restriction.

Source facts

The systemd version 257 manual describes ProtectSystem=strict as making the filesystem hierarchy read-only for a service, except for specified API filesystem subtrees. StateDirectory, LogsDirectory, and related directory settings exclude their managed locations from that restriction. ReadWritePaths can also define exceptions. The manual notes that filesystem namespace support is required and that these settings have limitations; a unit-file directive alone is not proof of effective confinement.

Source: systemd project — systemd.exec manual source, version 257.

Applicability

Use this guide for Linux system services with compatible systemd behavior. Check the installed systemd manual and execution environment, especially inside containers or user-service configurations.

DSE recommendation

DSE recommends inventorying durable state, cache, logs, runtime files, and configuration separately. Prefer the appropriate managed directory setting for a service’s declared data, with ownership and application paths reviewed together. Keep any remaining writable exception limited to a documented requirement. Avoid opening an entire filesystem tree because one write failed. Preserve the previous unit configuration and arrange a maintenance window that includes the application’s normal restart and recovery operations.

Verification

In a representative test environment, verify that legitimate state and log writes succeed and an unrelated write is denied. Restart the service and check retained state. Record the effective unit, runtime environment, expected paths, and observed failures before accepting the restriction.

Official reference

systemd project — systemd.exec manual source, version 257. Reviewed October 14, 2026.