How do I check ACLs and the umask when Linux permissions seem unexpected?
The umask filters permissions requested when a process creates a new object; it does not rewrite existing files. ACLs can grant access to additional named users or groups and may have a mask that limits effective rights. Check both before concluding that ordinary owner/group bits are the whole policy.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Inspect the current creation mask
Run this in the shell or service context responsible for creating the file. A login shell’s mask may differ from a systemd service’s setting.
umask
umask -SThe first form prints the numeric mask; the symbolic form makes the resulting allowed permission classes easier to read.
2. Read the file and parent ACL
The acl utilities package may be needed for getfacl. Inspect the exact file and the parent directory, where a default ACL may influence newly created children.
getfacl -- "$HOME/server-notes" "$HOME/server-notes/notes.txt"Look for named-user or named-group entries, effective permissions and default entries on the directory. This command does not alter ACLs.
Check the result
- The combination of owner/group mode, ACL mask, default ACL and creation context explains the observed access. Record the required access before proposing a scoped correction.
Troubleshooting
- A named ACL entry appears to grant write but writing fails
- Check the ACL mask and every parent directory’s traversal rights.
- Changing umask has no effect on an old file
- That is expected: it affects later creation in that process, not existing filesystem objects.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.