Context
A service cannot read a configuration file even though ls -l shows a readable file. Linux checks more than the final filename. The process needs permission to search every parent directory, and an access control list can limit rights through its effective mask. An administrator's successful read does not establish that the service identity has the same access.
Prepare the exact failing path, operation and service name. Confirm that the path is safe to inspect and that the necessary ACL utilities are installed. Use a non-sensitive fixture for access tests. This workflow concerns discretionary filesystem permissions; mandatory access controls and systemd filesystem restrictions are additional boundaries to inspect if ordinary permissions are sufficient.
Follow the complete pathname
- Identify the runtime identity with
systemctl show example.service -p User -p Group -p SupplementaryGroups. Compare it with the actual process credentials, especially after a recent group change. A running process does not acquire newly assigned supplementary groups merely because the account database changed. Record whether the application delegates file access to a different worker. - Run
namei -l /srv/example/config/settings.iniusing the real path. This displays path components and symlink resolution. Inspect each directory for search permission, conventionally shown as execute permission. Reading a directory's listing and traversing through it are distinct operations. A restrictive deployment parent can block access even when the target file itself looks permissive. - Use
getfaclon the target and relevant parent directories. Compare the named service entry, group entries and mask. An entry that appears to grant read access can have fewer effective rights because of the mask. Inspect default ACLs separately: they influence newly created objects and do not retroactively repair every existing file.
An illustrative deployment regression
In an illustrative document service, a deployment creates /srv/releases/new/config beneath a parent directory searchable only by the deployment group. The configuration file has the expected service ACL, but the service cannot reach it. A recursive permission reset would touch unrelated releases. The demonstrated correction is the required traversal right on the specific deployment path, accompanied by a fix to the release-creation procedure.
| Evidence | What it suggests | Next check |
|---|---|---|
| Target readable, parent restrictive | Path traversal failure | Inspect each parent with namei |
| ACL shows reduced effective rights | Mask constrains an entry | Review intended group-class access |
| Existing files work, new files fail | Creation policy differs | Default ACL, umask and deploy user |
| Shell test works, service fails | Runtime context differs | Process groups and service restrictions |
Correct only the required relationship
Decide which identity needs which operation on which directory. Back up relevant ACL descriptions before editing. Prefer a targeted owner, group or ACL correction over a recursive world-writable mode. If adjusting an ACL mask, review every entry it constrains: increasing it can enable rights for more than the one service under investigation.
Test through an application-owned diagnostic or a narrowly scoped read check as the service account. A substitute identity test is useful, but it may not reproduce a service sandbox or namespace. Verify both the intended allowed operation and an unrelated resource that should remain inaccessible. Confirm that the application can reopen the file after a controlled deployment or restart.
Make file creation reproducible
Record the deployment user, expected parent ownership, default ACL and application writer identity. Monitor permission-denied errors with sanitized paths and correlate them with releases. Include an access check in deployment acceptance so the next release reproduces the working relationship. Clouvenix Linux administration can help document service identities and filesystem access together.