Umask Calculator
Convert a umask value into default file and directory permissions, or work out the umask you need from the permissions you want.
| Cleared for | Read | Write | Execute |
|---|---|---|---|
| Owner | |||
| Group | ✕ | ||
| Others | ✕ |
Common presets
How to use
- 1 Type a umask value (e.g. 022) to see the default permissions it produces for new files and new directories.
- 2 Switch to "desired permissions → umask" to work backwards from the permissions you want new files to have.
- 3 Click a preset for the common defaults (022, 002, 027, 077).
- 4 Copy the umask value or the ready-to-run umask command.
Key features
- Converts a umask value into the resulting default permissions for new files and directories
- Reverse mode: enter the permissions you want and get the umask that produces them
- Shows numeric and symbolic notation side by side for both files and directories
- One-click presets for the common umask values (022, 002, 027, 077)
What is umask?
chmod changes permissions on a file that already exists. umask decides what permissions a new file or directory gets the moment it's created. When a program creates a file it asks for a base permission, conventionally 666 for files and 777 for directories, and the kernel subtracts the umask from it.
The umask is a mask of bits to clear, not a set of permissions to grant: the result is base AND NOT umask. It can only take permissions away, never add them. Because files start from 666, a new text file is never executable no matter what the umask is. That's why scripts need an explicit chmod +x after creation.
Common Use Cases
Setting up a new server
Work out the umask value that gives you the file and directory defaults you actually want, before deploying an app that creates files at runtime.
Shared team directories
A group-writable umask (002) means every file a teammate creates is automatically group-writable too, without an extra chmod step.
Hardening a sensitive account
A strict umask (077) on a service account means anything it creates (logs, temp files, sockets) starts private by default.
Debugging "why is this file 644 and not 664"
If new files never come out with the permissions you expect, the umask in effect when they were created is almost always the reason.
Understanding why scripts need chmod +x
Files start from a base of 666, which has no execute bit at all, so no umask can ever make a freshly created script executable.
Reading a CI or Docker build log
Build systems often set an explicit umask before writing artifacts. Reverse-engineer what permissions it produces before trusting the output.
Common umask Values
The same mask produces two different results, because files and directories start from a different base.
| umask | New files | New directories | Typical use |
|---|---|---|---|
| 000 | 666 | 777 | No restriction, rarely a good default |
| 002 | 664 | 775 | Group-writable: shared servers and team directories |
| 022 | 644 | 755 | The classic default on most Linux and macOS systems |
| 027 | 640 | 750 | Group reads, everyone else gets nothing |
| 077 | 600 | 700 | Private: the strict setting for sensitive data |
umask is a per-process setting: umask 022 in a shell applies to that shell and everything it launches afterwards. Running umask with no argument prints the current value. To make it permanent it goes in /etc/profile, your ~/.profile, or the PAM configuration, depending on the distribution. It only affects files created after it's set; changing it never touches anything already on disk.