Deutsch
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.
| Mask digit | Permissions removed |
|---|---|
| 0 | None |
| 1 | Execute |
| 2 | Write |
| 3 | Write and execute |
| 4 | Read |
| 5 | Read and execute |
| 6 | Read and write |
| 7 | Read, write and execute |
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:
| Umask | New file | New directory | Typical use |
|---|---|---|---|
| 022 | 644 (rw-r--r--) |
755 (rwxr-xr-x) |
Files that other users may read |
| 002 | 664 (rw-rw-r--) |
775 (rwxrwxr-x) |
Files shared with a trusted group |
| 027 | 640 (rw-r-----) |
750 (rwxr-x---) |
Read access for the group only |
| 077 | 600 (rw-------) |
700 (rwx------) |
Private files and directories |
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:
umaskTo display the corresponding allowed permissions in symbolic form:
umask -SSet a mask for this shell and processes it starts:
umask 027Other 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 ~/.bashrcAdd the mask you chose. For example, if new files should be readable by other users:
umask 022Start 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 ~/.bashrcSystem 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_configIf 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 0027The 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 -tIf validation succeeds, reload the actual SSH service unit. On systems where it is named ssh.service:
sudo systemctl reload sshOther 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@serverAt the SFTP prompt, upload a disposable file that does not already exist at the destination:
put testfile.txtOn the server, inspect the file in its upload directory:
ls -l testfile.txtCompare 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.
