Log appends but cannot be recreated: check the directory ACL
Appending to a file needs no new name in its directory; creating one does. Compare the access ACL with the inherited defaults before widening anything.
A log that keeps growing stops growing the moment something recreates it, and the error says permission denied. The tempting conclusion is that the log file itself needs more permissions, yet the file may already be writable by the same account. Appending to an existing name and creating a new one are different checks, and only the second one consults the directory.
Append and create are different checks
Opening an existing file for append needs write access on that file plus search access along every directory in its path. Creating a file needs write and search on the containing directory, because the operation adds a name to it. Replacing a file through a rename touches both directories and their sticky-bit rules as well.
| Operation | What must permit it | Typical failure message |
|---|---|---|
| Append to an existing log | File write access, path traversal | Permission denied on the file |
| Create a missing log | Directory write and search access | Permission denied on the path |
| Rename a replacement into place | Both directories, plus sticky restrictions | Permission denied or operation not permitted |
An already-open descriptor adds a fourth case. A process can hold a writable handle opened before it dropped privileges and still fail to reopen the same path under its later identity. The successful appends and the failed creation can both be true, at the same moment, for the same process.
Default ACLs inherit, they do not grant
An entry beginning with the default prefix describes what new objects inherit from the directory. It grants nothing to the directory itself, and it does not repair the ACL of a file that already exists.
namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.logRead the access entries separately from the default ones, and read the mask. A named entry that lists full rights can still be limited by the mask, which is why the effective comment matters more than the letters on the first line.
Use the resolved path rather than the path in the configuration. A symlink, a mount point or a rotated directory can put the real file somewhere the permission you granted never reaches. Walk the path with the name tool first, then compare each level against the account in question. Guessing at the top-level directory is how a fix lands one level too high.
Identify who writes at that moment
Check the service unit, its drop-ins and the daemon's own account settings before changing anything. The process that appends and the process that recreates may be different: a rotation helper, a status writer and a web reader rarely share an identity.
A test run from a root shell does not reproduce a restricted service, and it will succeed while the service keeps failing. Reproduce the failing operation under the same unit, with the same account and the same sandbox settings. If you cannot, start the unit with a temporary shell and check the identity it reports. Anything else measures your terminal rather than the service.
If creation really is required, grant the writer access to the dedicated log directory and keep read access for consumers separate. Making a shared account or a whole application tree writable to satisfy one logging call trades a small problem for a large one.
Rotate without reintroducing it
Whoever recreates the file decides its owner and mode for the next cycle, so coordinate the fix with the rotation configuration. A replacement created under a different account, or with a fresh ACL, brings the failure back after a successful correction.
Set the mode and the group on creation, not afterwards, and verify the next rotation rather than the next append. An append only repeats the test that already passed. If the rotation tool offers a create-mode setting, use it instead of a post-creation chmod. The gap between creation and chmod is precisely when the next write can fail.
When truncation fails anyway, stop adding permissions
A failure to truncate a file you can write is not explained by directory permissions, and adding more of them will not help. Look at the attributes and the confinement instead: an append-only attribute permits writes only in append mode, and a read-only mount or a service sandbox can deny an operation that the ACL allows.
Check the unit's filesystem restrictions and the mount options for the path, then reproduce the exact operation that failed. Expanding a permission that was never consulted only hides which restriction was real. Remove one restriction at a time in a throwaway unit, and revert it before changing anything permanent.