Linux umask Explained with Examples

When you touch notes.txt, Linux does not leave every permission bit set. The creating program passes a requested mode to the kernel; the process umask then clears selected bits from that request. Common utilities typically request up to 0666 for regular files and 0777 for directories. umask is a creation-time mask—it does not set final permissions directly, and it does not change files that already exist.

What Is umask?

umask is the file mode creation mask for a process. Every open(), mkdir(), and similar create call supplies a mode argument; the kernel normally computes requested_mode & ~umask.

• Programs choose the requested mode (a program can pass 0600, 0640, or 0700 instead of 0666).
• Common utilities typically request up to 0666 for regular files and 0777 for directories.
• umask removes bits from that request; it does not force every create to start at 666 or 777.
• The result becomes the new file or directory mode.

umask applies only when something is created. Running chmod on an existing path is a separate mechanism. See Linux file permissions for owner, group, and chmod workflows.

umask Quick Reference

Understand Base File and Directory Permissions

For teaching calculations, use the modes most CLI tools request when they create paths:

Ordinary touch and many open() calls request no execute bits on files (0666, not 0777). umask clears bits from whatever mode was requested—it cannot add execute on a create that did not ask for it. That is why a restrictive umask alone never turns a data file into an executable program.

How umask Calculates Permissions

Permissions are removed with a bitwise AND against the complement of the mask—not ordinary decimal subtraction.

The figure shows the file create path: base mode, bits cleared by the mask, and the mode stored on the new inode.

The diagram uses the common file example (666 requested, 022 mask, 644 result). Directories are usually created with a 777 request, so the same mask yields a different final octal mode even though umask clears the same permission classes.

base:  666   (rw-rw-rw-)
mask:  022   (clear group write and other write)
final: 644   (rw-r--r--)

Mask 022 does not clear other execute (001); the resulting file is still 644 because a typical file create never requests execute bits. Linux applies the mask by clearing bits present in the requested creation mode.

In notation: final = requested_mode & ~umask.

For many common masks such as 022, 027, and 077, the arithmetic shortcut “subtract the umask digits from the base” matches the bitmask result. That shortcut breaks for masks where cleared bits do not line up with simple digit subtraction, so learn the bitmask model first.

Calculate umask for Directories

Directories are usually created with a 777 request. With umask 027:

base:  777   (rwxrwxrwx)
mask:  027   (clear group write, other read, other write, other execute)
final: 750   (rwxr-x---)

Check the Current umask

Read the mask for your current shell session:

umask

0022

Leading zeroes are optional in output; 0022 and 22 mean the same mask on typical shells.

Symbolic form shows which bits remain in the mask itself (not the resulting file mode):

umask -S

u=rwx,g=rx,o=rx

umask -S describes the mask: bits not cleared are shown. A numeric 022 mask often prints as u=rwx,g=rx,o=rx because those are the bits umask leaves untouched before ANDing with the base mode.

Change umask for the Current Shell

Set a more restrictive session mask and create test objects in a throwaway directory:

umask 027

umask prints nothing on success, so create paths and read their modes:

mkdir -p /tmp/umasklab && cd /tmp/umasklab

Create a file under the new mask:

touch file027

Create a directory the same way:

mkdir dir027

Read octal modes for both paths:

stat -c '%a %n' file027 dir027

640 file027
750 dir027

640 and 750 match the quick-reference row for umask 027. The setting lasts until you exit the shell or run umask again.

Set umask with Symbolic Syntax

Bash and other POSIX shells accept symbolic umask, similar in spirit to chmod symbols but applied to the mask itself:

umask u=rwx,g=rx,o=

Confirm the numeric value:

umask

0027

Create a file to verify the mode:

touch symfile && stat -c '%a %n' symfile

640 symfile

Symbolic syntax is useful in profile snippets when 027 is less readable than g-w,o-rwx for your team.

Configure a Persistent User umask

Shell startup files set umask for future interactive sessions. There is no single file on every distribution—login and non-login shells source different paths.

On RHEL-family systems, /etc/bashrc often sets umask 022 when the current mask is 0 for non-login interactive bash. A line such as umask 027 in ~/.bashrc applies to new interactive shells that source that file.

Login versus non-login matters: an SSH session may read ~/.bash_profile first, while sudo bash might read only ~/.bashrc. After you edit a startup file, open a new login or interactive shell and run umask—existing sessions keep the old value.

Configure a System-Wide umask

System defaults vary by distribution and by whether PAM is involved.

On this RHEL 10 lab host, /etc/login.defs documents the default UMASK used by useradd and related tools:

grep ^UMASK /etc/login.defs

UMASK		022

/etc/bashrc guards non-login interactive shells:

grep -n umask /etc/bashrc

69:    # Set default umask for non-login shell only if it is set to 0
70:    [ `umask` -eq 0 ] && umask 022

PAM-enabled systems may also apply pam_umask (see comments in login.defs). Test the active mechanism on the host you administer before you copy one file path from a blog post.

Not every process reads shell profiles. Daemons, cron jobs, and systemd timers use their own unit settings or libc defaults unless you configure them explicitly.

Configure umask for a systemd Service

Shell profile umask does not control long-running services. Set UMask= in the service unit:

[Service]
UMask=0027
ExecStart=...

A one-shot test unit with UMask=0027 on this host created /tmp/umask-demo-file at mode 640 and /tmp/umask-demo-dir at 750.

systemd documents UMask= in systemd.exec with a default of 0022 for system services when unset. Compare with sshd, which reports UMask=0022 on this VM.

Some programs go a step further and set a mask internally, which is why editing a profile has no effect on them. OpenSSH SFTP is the usual example, because internal-sftp does not read the user's ~/.bashrc the way an interactive shell does, so a per-user mask belongs in ForceCommand internal-sftp -u instead. Set SFTP umask covers that configuration. When a service ignores the shell umask, fix the unit or the application rather than the user profile.

When to Use umask

umask, chmod, and ACLs answer three different questions, and reaching for the wrong one is why permissions seem to keep coming back wrong. Start from what you are actually trying to control:

umask is the right tool when the answer to "what permissions should new files here have?" is the same for everything in the session, whether that is your login shell, a build job, a backup script, or a service unit. It sets policy for the future, costs nothing at runtime, and is inherited by every child process, which is what you want for a default and exactly what you do not want for a one-off correction.

The difference from chmod is timing rather than syntax. umask removes bits from the mode a program requests while the object is being created, whereas chmod sets the owner, group, and other bits directly on something that already exists. That is why a restrictive umask cannot repair a tree that is already world-readable: set the mask so new objects come out right from here on, then fix what already exists in one pass with chmod -R.

ACLs are the case where the quick-reference table stops predicting the result. Normally the kernel computes the new mode from the application's requested permissions and the process umask. When the parent directory carries a default ACL, that inherited ACL is used instead of the usual umask calculation, and permissions the application never requested are still removed afterwards.

The symptom is specific: you set umask 027, yet new objects inside an ACL-managed directory refuse to come out 640 and 750. Run getfacl on the parent to check for a default ACL before you go hunting through profile files. Linux ACL examples covers that administration, while this article stays with umask and the standard permission bits.

Common umask Mistakes

Practical umask Examples

Three policies using typical 0666 / 0777 requests, tested in subshells on this host:

Personal private work (077) — owner only:

bash -c 'umask 077; d=/tmp/umasklab; mkdir -p "$d"; touch "$d/file077"; mkdir "$d/dir077"; stat -c "%a %n" "$d/file077" "$d/dir077"'

600 /tmp/umasklab/file077
700 /tmp/umasklab/dir077

Shared project directory (002) — group read/write on new objects:

bash -c 'umask 002; d=/tmp/umasklab; mkdir -p "$d"; touch "$d/file002"; mkdir "$d/dir002"; stat -c "%a %n" "$d/file002" "$d/dir002"'

664 /tmp/umasklab/file002
775 /tmp/umasklab/dir002

Admin account with tighter other access (027) — group read, no other access:

bash -c 'umask 027; d=/tmp/umasklab; mkdir -p "$d"; touch "$d/file027"; mkdir "$d/dir027"; stat -c "%a %n" "$d/file027" "$d/dir027"'

640 /tmp/umasklab/file027
750 /tmp/umasklab/dir027

Pick the mask that matches collaboration needs on your system—not a single global “correct” value for every server.

References

• umask(2) — Linux manual page
• bash(1) umask builtin — GNU manual
• systemd.exec — UMask=
• Red Hat Enterprise Linux 9 — Managing file system permissions and umask

Summary

Linux umask controls which permission bits are cleared when a process creates a file or directory. The kernel normally applies final = requested_mode & ~umask. Common utilities typically request up to 0666 for files and 0777 for directories, but the creating application chooses the mode argument—umask does not force every create to begin at those values.

On this lab host, umask 022 is the common default (644 files, 755 directories with those typical requests), while 027, 077, and 002 trade group and other access for tighter or more collaborative layouts. Session umask affects only the current shell; persistent values live in shell startup files that vary by login versus interactive sessions, and system-wide defaults on RHEL may appear in login.defs, bashrc, or PAM.

systemd services ignore ~/.bashrc—configure UMask= in the unit when a daemon needs a specific default. SFTP and other applications may set their own masks. When results still look wrong after umask checks, compare with chmod on existing files and check whether a parent directory default ACL replaced normal umask behavior.