Linux service permissions

Testing as root proves less than it looks

A config test run interactively runs as your user. The service runs as whatever User= says in the unit. A configuration that validates cleanly can still fail to start, and the error will be about a file rather than about the config.

grep -E '^User=' /etc/systemd/system/example.service
stat -c '%U:%G %a' /etc/example/config

If the unit drops privileges and the config is mode 600 owned by root, the daemon cannot read it. Giving the file to the service group and mode 640 keeps it unreadable by everyone else while letting the daemon in.

Log directories are half the problem

Creating the directory with the right owner is not enough if a file inside it was created earlier by root. Ownership of the directory permits creating new files; it does not grant write access to an existing one.

Editors and generators reset ownership

Tools that rewrite a file in place — including stream editors invoked with an in-place flag — may recreate it rather than modify it. Ownership and mode can silently revert. Re-check after any scripted edit to a permission-sensitive file.

Reload versus restart

enable --now starts a unit that is not running. It does nothing to one that already is. After editing configuration, restart explicitly, then confirm the process is actually listening where you expect rather than trusting that the service is "active".