A umask removes permission bits from every new file and directory. The common default, 022, leaves new files readable by everyone. A umask of 027 removes all access for others, which suits servers where config, logs and uploads should not be world readable. Set it deliberately for services, and test the result.
What the number does
The umask(2) manual says the mask turns off permission bits from the mode a program asks for when creating a file or directory. The typical default is octal 022. When a program requests mode 0666 for a new file, the result is 0644, because 0666 with the 022 bits removed is rw-r--r--.
For directories, programs usually ask for 0777, so 022 gives 0755.
| umask | New file | New directory | Meaning |
|---|---|---|---|
| 022 | 644 | 755 | Group and others can read |
| 027 | 640 | 750 | Group can read, others get nothing |
| 077 | 600 | 700 | Only the owner |
New files do not get the execute bit unless the program asks for it, which is why a typical file ends up at 644 and not 755.
Which to choose
022 is the long standing default and keeps shared tools working. It is a poor fit for a directory of secrets, database dumps or logs that include personal data, where others can read what they should not.
027 is a good server default. Services that share a group can still read each other's files if you intend it, and unrelated local accounts cannot. It breaks setups that depend on world readable output, such as a web server user reading files created by a deploy user who is not in its group. Fix that with group membership and a setgid directory, as in the chmod special bits explainer.
077 suits secrets and personal accounts, but not shared project folders.
Setting it for services
The systemd.exec manual says UMask= controls the file mode creation mask for a unit, takes an octal value, and defaults to 0022 for system units. So a service you do not configure writes world readable files. Add it to your unit:
[Service]
UMask=0027
For login shells, the mask is set by shell and login configuration, which varies by distribution. Check with umask in a fresh login session, in cron jobs and in the shell your deploy tool uses, because they can differ.
Two things that override it
- Default ACLs. The umask(2) manual says that if the parent directory has a default ACL, the umask is ignored and the file takes permissions from the inherited ACL. Run
getfaclon shared directories before blaming the umask. - Explicit modes. A program that calls
chmodafter creating a file, or asks for a mode like 0600, is not changed by your choice in the direction you might expect. A mask can only remove bits, never add them.
A quick audit
List files others can read under sensitive paths:
find /etc/myapp /var/lib/myapp /var/log/myapp -type f -perm -004 -ls
Fix the cause, which is usually the umask or the mode in a deploy script, not only the existing files. Add the check to your host baseline.
Safeguard offers asset discovery and compliance evidence automation, plus a free scan at gold.safeguard.sh/scan.
Quick check
What permissions does a new file get with umask 027?
If the program requests 0666, the file is 0640. Owner read and write, group read, others nothing.
Does the umask apply when a directory has a default ACL?
No. The umask is ignored and the inherited ACL decides the permission bits.
Sources
Last reviewed: 19 October 2026.
