Every new file and directory gets permissions automatically. The umask (user file-creation mask) decides which permission bits are removed from the default. It’s why your new files are usually 644 and directories 755, and why shared team folders sometimes end up unwritable.

Check the current umask

umask          # 0022
umask -S       # u=rwx,g=rx,o=rx (symbolic: what is ALLOWED)

How it’s calculated

Programs create files with a base mode, usually:

  • 666 (rw-rw-rw-) for files, since execute isn’t added by default;
  • 777 (rwxrwxrwx) for directories.

The umask removes bits from that base:

umask New files New directories Typical use
022 644 rw-r--r-- 755 rwxr-xr-x Default on most systems
002 664 rw-rw-r-- 775 rwxrwxr-x Shared group work
027 640 rw-r----- 750 rwxr-x--- Servers: no access for others
077 600 rw------- 700 rwx------ Private: only the owner

It’s a bit mask, not subtraction. The result is base AND NOT umask. With the common values above, subtraction gives the same answer.

The leading 0 is for the special bits (setuid, setgid, sticky), which umask normally leaves alone.

Change it for the current shell

umask 027
touch test && ls -l test     # -rw-r----- …

This lasts until the shell exits.

Set it permanently

For one user, add it to ~/.bashrc or ~/.profile:

umask 027

System-wide defaults come from:

  • /etc/login.defs: UMASK 022, applied through PAM (pam_umask) on many distributions;
  • /etc/profile or /etc/profile.d/*.sh for login shells.

With USERGROUPS_ENAB yes in login.defs (the default on Debian and Ubuntu), users whose primary group has the same name as the user effectively get 002, the user-private-group scheme. It’s safe because nobody else is in that group.

umask for services (systemd)

Services don’t read your shell profile. Set the umask in the unit file:

[Service]
UMask=0027

Examples:

  • An app that writes uploads which Nginx (in the group) must read: UMask=0027 gives 640 files and 750 directories.
  • A team deploy process: UMask=0002.

Apply it with sudo systemctl daemon-reload && sudo systemctl restart app. For PHP-FPM pools there’s no umask directive, so set UMask= on the php-fpm service with a drop-in (systemctl edit php8.3-fpm).

umask in scripts

Scripts that create sensitive files should set a strict umask first, so there’s no moment when the file is readable by others:

#!/usr/bin/env bash
umask 077
mysqldump shop > /var/backups/shop.sql     # created as 600 from the start

That’s better than creating the file and then running chmod 600, which leaves a short window. A subshell limits the change: ( umask 077; command ).

Shared directories: umask + setgid

For a team folder where everyone edits each other’s files, you need:

  1. a common group, with the directory set to chown :team and chmod 2775 (setgid makes new files inherit the group);
  2. a umask of 002 for team members, so new files are group-writable.
sudo chmod 2775 /srv/shared
echo 'umask 002' >> ~/.bashrc

If one member keeps 022, their files come out 644 and others can’t edit them. Default ACLs solve this regardless of individual umasks:

sudo setfacl -d -m g:team:rwX /srv/shared

See ACLs and Linux groups.

Things umask doesn’t do

  • It doesn’t change existing files. Use chmod for those. See chmod.
  • It can’t add permissions. If a program creates a file with mode 600, no umask makes it 644.
  • Copying with cp -a or extracting with tar -p preserves the original permissions instead of applying the umask.
  • scp and rsync uploads may use the remote side’s umask or the source’s permissions, depending on the options.

Quick reference

Task Command
Show umask / umask -S
Set for session umask 027
Set for user add to ~/.bashrc
System default UMASK in /etc/login.defs
For a service UMask=0027 in the systemd unit
Strict in a script umask 077 at the top

Related: Linux file permissions and setuid, setgid and sticky bit.

  • Linux
  • Permissions
  • Security