What Is umask in Linux? Permissions and Examples

umask controls which permission bits a process removes when it creates a file or directory. It helps you choose whether new files are private, readable by a group, or readable by other users. It does not change permissions on files that already exist.

On a VPS or dedicated server, check the mask used by the process that creates the files. Your interactive shell, an SFTP session, and a system service can each use a different value.

How umask affects new permissions

Applications commonly request 666 for new regular files and 777 for new directories. The mask removes bits from that requested mode. It cannot grant permissions the application did not request.

With umask 022, a typical new file becomes 644: the owner can read and write, while the group and other users can read. A typical new directory becomes 755: the owner can read, write, and traverse it; the group and others can read and traverse it.

This is a bitwise operation, not ordinary subtraction. For example, umask 033 also produces 644 from a requested file mode of 666, because that file mode has no execute bits to remove. Default directory access-control lists (ACLs) can also affect the result on Linux.

Read an octal mask

The three permission digits apply to the owner, group, and other users, in that order. Each digit combines read (4), write (2), and execute (1) bits. A set bit in a mask means that permission is removed.

A mask of 027 removes nothing from the owner's requested permissions, removes write from the group, and removes all permissions from other users. Shells may display this as 0027 with a leading zero.

Choose a mask for the files you create

These examples assume requested modes of 666 for files and 777 for directories, with no default ACL changing the result:

Use 077 for files that should be private to their owner, such as credentials. It does not add execute permission to regular files, and privileged processes may still access the data. Directory permissions, ACLs, and later permission changes matter too.

For shared web files, 002 may be suitable when the deployment user and service belong to the intended group. When configuring Nginx or Apache, confirm that the service can traverse the parent directories and read the files it needs. Use 027 when the group should read files without changing them.

Check and change the shell mask

Display the mask for your current shell:

umask

To display the corresponding allowed permissions in symbolic form:

umask -S

Set a mask for this shell and processes it starts:

umask 027

Other running shells and services keep their own settings. Record the previous value if you want to restore it after testing.

Make a shell setting persistent

For interactive Bash shells, a user setting often belongs in ~/.bashrc. Login shells may instead read ~/.bash_profile or ~/.profile; inspect which files your setup loads before editing.

nano ~/.bashrc

Add the mask you chose. For example, if new files should be readable by other users:

umask 022

Start a new shell and check umask. You can also reload the file in the current Bash shell, which runs all commands in that file:

source ~/.bashrc

System defaults may come from /etc/profile, PAM configuration, or settings such as /etc/login.defs, depending on the distribution and login method. A later setting can replace an earlier one; there is no universal rule that a system value always overrides a user value.

Set a mask for SFTP uploads

An SFTP-only session may not read your shell startup files. OpenSSH's SFTP server accepts a separate -u mask.

Before editing SSH configuration, keep an existing administrator session open and confirm that you have console recovery access:

sudo nano /etc/ssh/sshd_config

If your installation uses the external SFTP server at this path, replace its existing Subsystem sftp line rather than adding a duplicate:

Subsystem sftp /usr/lib/openssh/sftp-server -u 0027

The binary path varies by distribution. If the existing subsystem uses internal-sftp, keep that implementation and add -u 0027 to its line instead.

For a user who should have SFTP access only, a matching block can set a separate mask:

Match User webapp
    ForceCommand internal-sftp -u 0027

ForceCommand also restricts that user's normal SSH shell commands. Use it only when SFTP-only access is intended, and check the placement and scope of the Match block.

Validate the configuration before reloading:

sudo sshd -t

If validation succeeds, reload the actual SSH service unit. On systems where it is named ssh.service:

sudo systemctl reload ssh

Other distributions use sshd.service. Confirm the name on your server. Open a second session and test access before closing the original administrator session.

Connect from your client:

sftp user@server

At the SFTP prompt, upload a disposable file that does not already exist at the destination:

put testfile.txt

On the server, inspect the file in its upload directory:

ls -l testfile.txt

Compare the result with the client's requested permissions and the server mask. A client that preserves permissions or changes them after upload may produce a different result.

Set a mask for a systemd service

A systemd service does not normally inherit your interactive shell's mask. Set UMask in a service override when the service needs a different default:

sudo systemctl edit nginx.service

For example:

[Service]
UMask=0022

Reload the unit definitions, then restart the service during an appropriate maintenance window:

sudo systemctl daemon-reload
sudo systemctl restart nginx

The restart applies the mask to the new service process. Check service health and permissions on newly created files. See the systemd.exec documentation for the directive's scope.

Test the result with new files

Use a directory you control and filenames that do not already exist. touch will not reset an existing file's permissions, so reusing an old test file can hide the effect of a new mask.

umask
touch testfile.txt
mkdir testdir
ls -l testfile.txt
ls -ld testdir

Compare the output with the table above. With 022, expect 644 for the file and 755 for the directory under the stated assumptions. With 027, expect 640 and 750.

If results differ, check the creating process, parent directory ACLs, application-specific modes, and any later chmod operation. For group access, confirm membership:

groups username

Review existing permissions separately

Changing the mask affects future creation. It does not repair files that are already too widely accessible. This command lists world-writable regular files beneath /home that your account can inspect:

find /home -type f -perm -002

Investigate each result before changing permissions. Avoid a blanket mask of 000 for ordinary shared-server work: it removes no permission bits and can allow world-writable files when an application requests them. Whether someone can delete a file also depends on the containing directory's permissions.

Choose a mask for the actual readers and writers, test it through the same shell or service that creates the files, and review sensitive files independently. A mask is one part of access control alongside ownership, groups, ACLs, and authentication.