umask and Default Permissions

Every time you create a new file or directory in Linux, the system has to decide what permissions to give it before you’ve had a chance to run chmod. That decision is controlled by the umask (user file-creation mask). Understanding umask lets you make new files private by default, shared with your team, or world-readable, all without manually running chmod after every single file you create. Get it wrong on a shared server, and you can accidentally leave sensitive files readable by every user on the box.

Overview / How umask Works

When a program creates a new file or directory, it asks the kernel for a starting set of permission bits. By long-standing convention, programs that create regular files (editors, touch, redirection, compilers) request mode 666 (rw-rw-rw-), and programs that create directories request mode 777 (rwxrwxrwx). Notice that regular files never start with the execute bit — that’s intentional. If every new text file were automatically executable, plain data files and scripts you’re still writing would be runnable by accident. Execute permission on a file has to be granted explicitly with chmod +x.

The umask is a second bitmask, stored per-process and inherited from parent to child (your login shell has one, and every program you launch from it inherits it), that tells the kernel which of those requested bits to strip away at creation time. The kernel computes the final mode as:

final_mode = requested_mode & ~umask

In plain terms: take the requested permissions, and turn off any bit that is set in the umask. This is why umask can only remove permissions, never add them — it is a mask of bits to deny, not a mask of bits to grant. A umask of 000 denies nothing, so files land at the maximum 666 and directories at 777. A umask of 022 denies write access to group and other, so files land at 644 and directories at 755. This calculation happens once, at creation time, inside the kernel’s file-creation code path — it has nothing to do with chmod, which can change permissions on a file at any later time regardless of what umask was in effect when the file was born.

Syntax

umask [-S] [mode]

• umask (no arguments) — prints the current mask in octal, e.g. 0022.
• umask -S — prints the current mask in symbolic form as the permissions it allows, e.g. u=rwx,g=rx,o=rx.
• umask mode — sets a new mask for the current shell (and anything it launches afterward). mode can be octal, such as umask 027, or symbolic.
• umask u=rwx,g=rx,o= (symbolic form) — unlike chmod‘s symbolic syntax, symbolic umask arguments describe the permissions you want new files to end up with, not bits to add or remove.

Examples

Example 1: check the current umask and see how it shapes a freshly created file and directory.

umask
touch notes.txt
mkdir project
ls -l notes.txt
ls -ld project

Output:

0022
-rw-r--r-- 1 alice alice    0 Aug  4 10:02 notes.txt
drwxr-xr-x 2 alice alice 4096 Aug  4 10:02 project

With the common default umask of 022, the file’s requested 666 loses write for group and other, landing at 644. The directory’s requested 777 loses the same bits, landing at 755.

Example 2: temporarily tighten the umask before creating a file that should stay private, such as one holding credentials.

umask 077
touch secrets.env
ls -l secrets.env

Output:

-rw------- 1 alice alice 0 Aug  4 10:05 secrets.env

A umask of 077 strips every permission bit for group and other, so only the owner can read or write the new file. This is a common pattern before writing out a secrets or credentials file.

Example 3: use symbolic umask syntax to set an exact allowed-permission profile, and confirm it with umask -S.

umask -S
umask u=rwx,g=rx,o=
umask -S

Output:

u=rwx,g=rx,o=rx
u=rwx,g=rx,o=

The first umask -S reflects the default 022 mask. After setting a symbolic umask that grants the owner full access, the group read and execute, and others nothing, new directories created afterward would come out as 750 and new files as 640.

How It Works Step by Step

Walking through the math for a umask of 022 creating a regular file:

Step	Binary (owner/group/other)	Octal
Requested mode for a file	110 110 110	666
umask	000 010 010	022
Complement of umask (bits kept)	111 101 101	755
Result: requested AND complement	110 100 100	644

The same math run against a directory’s requested 777 with the same 022 mask produces 755, because directories start from a higher baseline (they need the execute bit to be traversable) but go through the identical bitwise-AND step. This is why, for the same umask, a directory always ends up with the execute bit set for whichever category kept its read bit, while a plain file never does.

Common Mistakes

Mistake 1: assuming a high umask number means "more open" permissions. Because chmod 777 means "everyone gets everything," people sometimes try the same number with umask expecting the same result — it does the opposite.

umask 777
touch open.txt
ls -l open.txt

Output:

---------- 1 alice alice 0 Aug  4 10:10 open.txt

umask 777 strips every single bit, so the new file has no permissions for anyone, including the owner. Fix it by setting permissions explicitly after creation instead of trying to force it through umask:

touch open.txt
chmod 666 open.txt

Mistake 2: expecting umask to change permissions on files that already exist. umask only affects files and directories at the moment they are created — it has no effect afterward.

touch report.csv
umask 077
ls -l report.csv

The permissions on report.csv are exactly what they were before umask 077 ran, because the file already existed. To restrict an existing file, use chmod directly:

chmod 600 report.csv

Mistake 3: setting umask interactively and expecting it to survive a new terminal or reboot. Running umask 027 at a prompt only changes the mask for that shell and anything launched from it. Open a fresh terminal, or log in again, and it reverts to whatever is set in your shell’s startup files (typically 022 from /etc/profile or /etc/login.defs). If you want a umask to persist, it has to be added to a startup file such as ~/.bashrc, not just typed at the prompt.

Best Practices

• Set your preferred umask in ~/.bashrc (per-user) or /etc/profile (system-wide) rather than typing it every session — a one-time umask 027 at the prompt is forgotten the moment you open a new terminal.
• On shared or multi-user systems, prefer 027 or 077 over the common desktop default of 022, so new files aren’t automatically readable by every other account.
• Never set a system-wide umask of 000. If one specific file genuinely needs to be world-writable, grant that with an explicit chmod on that file, not by loosening the mask for everything you create.
• Remember umask has zero effect on files that already exist — use chmod (add -R for a whole tree) to fix permissions retroactively.
• Check root’s umask separately from your own; commands run via sudo or as root use root’s shell umask (often 022), not the umask of the user who invoked sudo.
• For a single sensitive file, tighten the umask only for that command using a subshell, e.g. (umask 077; touch secret.key), so the rest of your session is unaffected.

Practice Exercises

1. Run umask -S to see your shell’s current symbolic mask. Create a new file and a new directory, then use ls -l and ls -ld to confirm the resulting permissions match what the mask predicts.

2. Temporarily set your umask to 027, then create a file named team-notes.txt. Verify with ls -l that the owner has read and write, the group has read-only, and others have no access at all.

3. Without running anything yet, work out on paper what permissions a new file and a new directory would get under a umask of 073. Then actually set that umask and create a test file and directory to check your answer.

Summary

• umask is a per-shell, inherited bitmask that strips permission bits from newly created files and directories — it never adds bits.
• Regular files start from a requested mode of 666 and directories from 777; the kernel computes the final mode as requested & ~umask.
• A common default of 022 yields 644 for files and 755 for directories; 077 yields 600 and 700 for strictly private files.
• umask affects only creation-time permissions — it has no effect on files that already exist; use chmod for those.
• Set umask in a shell startup file like ~/.bashrc to make it persistent, and avoid a system-wide umask of 000.