umask

umask (user file-creation mode mask) is a per-process bit mask that tells the Linux kernel which permission bits to remove from every new file and directory a process creates. It does not change existing files; it only shapes the default permissions that new objects receive, which makes it the quiet first line of access control in Linux permissions.

Every process inherits its umask from its parent, so a value set in a login shell, a service unit or a container entrypoint silently governs everything that process writes. Understanding the umask explains why a freshly created file is usually 644 rather than 666, and why shared directories and service output sometimes end up with surprising access rights.

How the umask removes permission bits

The umask works by clearing bits, not by subtracting numbers. When a program calls open(), creat() or mkdir(), it passes a requested mode. The kernel computes the final mode as requested mode AND NOT umask, so any bit that is set in the umask is switched off in the result.

Most programs request `0666` for regular files and `0777` for directories. Execute permission is deliberately left out of the file request, because a new file should not be executable by accident. With the common umask of 022, the group and others lose write permission, producing `644` files and `755` directories.

The following table shows how typical umask values translate into the default permissions of new files and directories when programs use the standard requested modes.

Because the operation is a bitwise mask, arithmetic intuition can mislead. A umask of 033 applied to a file request of 0666 yields 644, not 633, because the execute bits it tries to remove were never requested. Thinking in bits avoids this common error.

Where the umask value comes from

The effective umask is inherited through `fork()` and preserved across exec(), so its value depends on the chain of processes that started a program. Several layers can set or override it, and the last one applied wins for that process and its children.

The umask command is a shell builtin, not a separate program, because a child process cannot change the mask of its parent. Running umask without arguments prints the current value, umask -S prints it in symbolic form such as u=rwx,g=rx,o=rx, and umask 027 sets a new value for the current shell.

Since kernel 4.7, the current mask of any process can also be read from the `Umask:` field in `/proc/PID/status`, which is the most reliable way to verify what a running daemon actually uses.

How umask relates to chmod, ACLs and setgid directories

The umask is a creation-time default, whereas chmod changes the mode of an existing object explicitly. The two complement each other: the umask sets the starting point, and chmod or chown adjust individual files later. Neighboring mechanisms in Linux permissions interact with the umask in specific ways.

The interaction with default ACLs surprises many administrators. When a parent directory carries a default access control list, the kernel ignores the umask for new entries in that directory and derives their permissions from the inherited ACL instead. This makes default ACLs the more precise tool for shared directories.

A setgid directory solves a different problem: it makes new files inherit the directory group rather than the creator’s primary group. Group collaboration typically needs both a setgid bit and a group-friendly umask such as 002, otherwise colleagues share a group but still lack write permission.

Choosing a umask for users and services

The right umask follows from who should read new data by default. A restrictive value protects confidentiality but can break collaboration and web serving, while a permissive value eases sharing at the cost of exposure. The decision table below summarizes common situations.

For daemons, the `UMask=` setting in a systemd unit is preferable to editing shell profiles, because services do not read interactive startup files. The systemd default for services is 0022, so a service that writes sensitive output should declare `UMask=0077` explicitly.

Common mistakes and misconceptions

Most umask problems come from wrong assumptions about scope or arithmetic. The following points cover the errors seen most often in administration practice.

• Expecting retroactive effect: changing the umask never alters files that already exist; use chmod for those.
• Subtracting instead of masking: the result is a bitwise operation, so decimal subtraction gives wrong answers for odd values.
• Editing the wrong file: a value set in ~/.bashrc does not reach services, cron jobs or graphical sessions started elsewhere.
• Forgetting explicit modes: programs that request 0600 or call chmod themselves are only narrowed by the umask, never widened.
• Ignoring default ACLs: inside a directory with a default ACL, the umask has no effect on new entries.

A further subtlety concerns copy and archive tools. Commands such as cp -p, rsync -p or tar -p preserve source modes, and some extract operations apply the umask only when preservation is off, so the same archive can produce different permissions for different users.

Explained without jargon

Imagine every new file starts life with all doors open. The umask is a list of doors to lock automatically before anyone can walk in. It does not touch rooms that already exist; it only decides how new ones look on day one.

If your umask locks the write door for everyone except you, then others can look at your new files but cannot change them. Locking more doors keeps things private, and locking fewer doors makes sharing easier. The key point is simple: the umask sets safe defaults so you do not have to fix permissions by hand after every file.

A typical use case

A small engineering team keeps shared build scripts in /srv/project on a Linux server. Developers keep complaining that they cannot edit files a colleague created yesterday, even though everyone belongs to the `devteam` group. Inspection shows the files are 644 and owned by each author’s personal group.

The administrator sets the setgid bit on `/srv/project` so new files inherit the devteam group, and changes the login umask from 022 to `002` through `pam_umask`. Existing files are corrected once with chgrp -R devteam and chmod -R g+w. The nightly build service, which runs under systemd, receives UMask=0002 in its unit file.

From then on, every new file appears as 664 and every new directory as 775 with the correct group. Permission complaints stop, and nobody needs to run chmod after saving a file.