When you create a file -- when you open an empty file with touch, save one in an editor, or an application writes a log file -- the file ends up with a specific permission even though you never ran chmod. That permission is not random; it is decided by a masking value called umask. Knowing how umask works is necessary in order to predict in advance which users on a server will be able to read, write or execute newly created files.

What is umask?

umask is a mask that decides which permissions will be removed from newly created files and directories. The Linux kernel and the standard tools (touch, mkdir, text editors, most applications) first request a base permission when creating a new file or directory: 666 (rw-rw-rw-) for files and 777 (rwxrwxrwx) for directories. These two values are not the permission the file will actually get, only the upper bound. Directories start from 777 because the execute (x) bit means being able to enter the directory; files start from 666 because the execute bit is not wanted by default. umask removes certain bits from that upper bound and produces the value that ends up as the real permission of the file or directory.

The default umask value can differ from distribution to distribution. On some distributions that use the user private group scheme -- the arrangement where every user has a separate group named after them -- the default umask for regular users is usually set to 002, because the only member of that group is the user themselves. On other systems that use a shared group structure the default is usually 022. Most distributions also define a separate default for the root user. For that reason, checking the current umask value first when you log in to a new server is necessary so that you do not make wrong assumptions about that system's permission behaviour.

How the calculation works

The umask calculation is not a simple subtraction but a bitwise AND NOT operation: every bit of the base permission is matched against the inverse of the corresponding bit in the umask. If a bit in the umask value is "1", that bit is removed from the base permission; if it is "0", the base permission stays as it is. Even though the result looks the same as arithmetic subtraction for the standard values (for example 666 - 022 = 644), the real logic is bit masking. A umask consists of three digits and each digit is between 0 and 7; the digits specify which permission bits will be removed for the owner, the group and others respectively. The result that some commonly used umask values leave on files and directories is shown below.

umaskFile permission (from 666)Directory permission (from 777)
000666 (rw-rw-rw-)777 (rwxrwxrwx)
002664 (rw-rw-r--)775 (rwxrwxr-x)
022644 (rw-r--r--)755 (rwxr-xr-x)
027640 (rw-r-----)750 (rwxr-x---)
077600 (rw-------)700 (rwx------)

The umask 022 example step by step

The most widely used umask value is 022, and it is the default for regular users on most Linux distributions. The three digits are for the owner, the group and others respectively: the first digit, 0, removes nothing from the owner; the second and third digits, 2, remove the write (w) bit from the group and from others. For files the base permission was 666 (rw-rw-rw-); once the write bit is removed from the group and others, 644 (rw-r--r--) remains: the owner can read and write, the group and others can only read. For directories the base permission was 777 (rwxrwxrwx); by the same logic, once the write bit is removed from the group and others, 755 (rwxr-xr-x) remains: the owner can create and delete files inside the directory, the group and others can list its contents and enter it but cannot create new files or delete existing ones.

Viewing and changing the current umask value

To see which umask value is active in a terminal session, the umask command is run with no parameters; the command returns the active value in octal (for example 0022).

Shows the umask value in effect in the active shell session.

umask
0022

To change the value, an octal value is given to the umask command. This change applies only to the terminal session in which the command was run; when the session is closed and reopened it goes back to the system or user default.

Sets the umask value in the active session to the given octal value.

umask 022

If you want the change to be applied automatically in every new session, you need to add the umask command to the shell's startup file. For a single user, add the line to the end of ~/.bashrc (or ~/.zshrc or ~/.profile, depending on the shell you use); for all users on the system, edit the UMASK line in /etc/profile or, depending on the distribution, in /etc/login.defs.

umask is not a replacement for chmod

umask and chmod are two different mechanisms that are often confused. umask affects only the permission that new files and directories being created at that moment will get; it has no effect at all on the permissions of files that already exist on the system. chmod, on the other hand, does exactly the opposite: it changes the permission of a specific file or directory already sitting on disk. Setting umask to 027 does not automatically change the permissions of a file created yesterday; to update that file's permission you have to run chmod separately. The two need to be thought about together: umask governs the future, chmod governs the past and the present.

Common mistakes

  • Confusing the umask value with chmod and entering the resulting permission directly (e.g. 644); umask expresses the bits to be removed from the base permission, not the result.
  • Leaving umask far too loose, such as 000, on a shared server; in that case every newly created file becomes readable and writable by all other users on the server.
  • Assuming that a change made with the umask command in a terminal session is permanent; the value resets when the session closes, and for persistence ~/.bashrc or /etc/profile must be edited.
  • Assuming that processes running as services (systemd units, cron jobs, web server processes) automatically inherit the umask value from the shell; those processes may define a separate umask in their own configuration.
  • Thinking that changing umask alone is enough to fix the permissions of files that already exist on disk; for existing files you also have to run chmod (and chmod -R if needed).

Working out in your head what result a umask value will leave on files and directories is error-prone, especially with less common combinations such as 027 or 075. Calculating the value directly and seeing the octal and symbolic notation, instead of running the bit masking by hand, reduces the risk of leaving a wrong permission in a server configuration.