umask Calculator
See exactly what permissions a umask yields for new files and directories — and work backwards from the permissions you want to the umask you need.
New files (base 666)
New directories (base 777)
Permission breakdown
Reverse lookup
How to use this tool
- Type your umask in octal — three digits is normal, four if you are setting the special-permission digit.
- Read the two panels: files start from a base of
666and directories from777, which is why the same umask gives different results. - Use the breakdown table to see exactly which of read, write and execute each class ends up with.
- Use Reverse lookup when you know the permissions you want and need the umask that produces them.
- If the reverse lookup warns you, the permissions you asked for are not reachable with a umask at all — you need
chmod.
A umask is a mask of permission bits to remove. This is the single most important thing to understand about it, and the thing that makes it confusing: it never grants a permission, it only takes one away. The kernel computes the final mode as the base permission ANDed with the complement of the umask.
The base differs by object type. Regular files are created with a base of 666 (read and write for everyone, no execute) and directories with 777. This is a deliberate safety decision: a newly created file should never be executable by accident. It is also why the familiar umask 022 produces 644 on a file but 755 on a directory — the execute bit was never in the file’s base to remove.
That asymmetry explains a common frustration: no umask will ever give you an executable file. If you want 755 on a script, the umask cannot do it — you need chmod +x. The reverse lookup on this page detects that case explicitly and tells you, rather than silently handing back a umask that does not do what you asked.
The three umask values worth knowing by heart: 022 is the general-purpose default, giving the owner write access and everyone else read-only. 002 is the group-collaboration setting, letting group members write too, which suits shared project directories with setgid. 077 is the lockdown setting — owner only, nothing for group or others — and is what you want for anything containing keys or credentials.
Where you set it matters more than most people expect. A umask in ~/.bashrc applies only to interactive shells, so a cron job or a systemd service will not see it — a recurring source of files that come out with the wrong permissions in automation. For services, set UMask= in the systemd unit. For system-wide defaults, use /etc/login.defs or a PAM configuration. Note too that umask is inherited by child processes, so a daemon carries whatever mask the process that spawned it had.
Frequently asked questions
Why does umask 022 give 644 on files but 755 on directories?
Because the starting points differ. Files begin at 666 and directories at 777. Removing 022 from 666 gives 644; removing it from 777 gives 755. Files never start with the execute bit, by design.
Can a umask make a file executable?
No, never. A umask only clears bits, and the file base of 666 contains no execute bit to keep. Use chmod +x. The reverse lookup on this page flags any target permission that is unreachable for this reason.
Where should I set umask so it applies to a service?
Not in ~/.bashrc — that only affects interactive shells, so cron jobs and systemd services will ignore it. Use UMask=0027 in the systemd unit file, or set it in the service’s own configuration. This is a frequent cause of automation writing files with unexpected permissions.
What is the fourth digit for?
It masks the special permission bits: setuid (4), setgid (2) and the sticky bit (1). A umask of 0022 is the same as 022; the leading zero simply clears nothing from that group.
What umask should I use for sensitive files?
077. It strips every permission from group and others, so new files come out 600 and directories 700 — owner only. That is the right default for a directory holding SSH keys, tokens or credentials.