When you create a new file or directory on your server, the system automatically assigns permissions to it. These permissions determine who can read, write, or execute that file. There’s a setting called umask that controls the default permissions.
Whether you’re managing a basic VPS or dedicated server, getting this right matters because it directly affects your server’s security and how different users can interact with your files.
We’re going to walk you through everything you need to know. You’ll learn what it does, how to check your current settings, and how to adjust them for different scenarios on your server.
Understanding Umask and Permission Control
Umask stands for user file-creation mode mask.
When you create a new file, the system starts with default permissions of 666 (read and write for everyone). For directories, it starts with 777 (read, write, and execute for everyone). This value then subtracts specific permissions from these defaults.
Let’s say it equals 022. When you create a new file, it removes permissions through bitwise masking. With this setting, the result is 644. The owner keeps read and write (6), while group and others lose write permission, leaving them with read only (4).
The same logic applies to directories. With 022, a new directory gets 755 permissions. The owner has full control, but the group and others can only read and enter the directory.
Breaking Down Octal Notation
Umask uses octal notation, a number system based on the digits 0-7. Each digit represents a combination of three permission types: read, write, and execute.
For example, 7 means full permissions (4+2+1), while 6 means read and write only (4+2).
These values have three digits. The first digit controls permissions for the file owner. The second digit affects the group. The third digit applies to everyone else on the system.
When you see 022, you’re looking at three separate instructions. The 0 means don’t remove any permissions from the owner. Every 2 means remove write permission (the value 2) from both the group and others.
Here’s what each octal digit means in terms of removed permissions:
- 0: No restrictions
- 1: Removes execute (x)
- 2: Removes write (w)
- 3: Removes write and execute (wx)
- 4: Removes read (r)
- 5: Removes read and execute (rx)
- 6: Removes read and write (rw)
- 7: Removes all permissions (rwx)
Common Umask Values You’ll Encounter
Different values serve different purposes. Understanding the common ones helps you choose the right setting for your needs.
The value 022 is the most widely used default on Linux systems. It gives the owner full control while allowing others to read files and access directories. This works well for general server environments where you want some level of openness without compromising the owner’s exclusive write access. A setting of 002 works well for collaborative environments. It allows group members to modify files alongside the owner. Only users outside the group are restricted to read only access. You’ll see this in development teams where multiple people need to work on the same files.
For maximum security, 077 removes all permissions for anyone except the owner. When you create a file with this setting, only you can read, write, or execute it. Nobody else on the system can even view the contents. This is essential for sensitive data like private keys or configuration files containing passwords.
The value 027 offers a middle ground for security-conscious setups. The owner gets full access, group members can read and execute, but everyone else is completely locked out.
Checking Your Current Umask
Check your current value:
umask
The command displays your current umask value.
For most users, this lives in files like .bashrc, .bash_profile, or .profile in your home directory.
System-wide values may live in /etc/profile or /etc/login.defs. These apply to all users unless they override them with personal settings.
To see your setting in symbolic notation instead of numbers, use:
umask -S
The command displays permissions in human-readable symbolic format.
How to Change Your Umask
Temporary Changes
To set a temporary value, simply type the command followed by your desired value:
umask 027
The umask changes immediately for this session only.
Permanent Changes
For most systems running Bash, you’ll edit .bashrc or .profile in your home directory.
Open the file with a text editor:
nano ~/.bashrc
The text editor opens, displaying the file contents.
Add a new line:
umask 022
This line sets the default umask for all new terminal sessions.
Save the file and exit the editor. For the change to take effect in your current session, reload the configuration file:
source ~/.bashrc
The configuration file reloads, applying your changes immediately.
If you’re setting this for a system-wide default that applies to all users, you’ll need root access. Edit /etc/profile or the appropriate system configuration file.
Setting Umask for SSH and SFTP
Edit SSH daemon config:
sudo nano /etc/ssh/sshd_config
The editor opens the SSH configuration file.
Add for all SFTP users:
Subsystem sftp /usr/lib/openssh/sftp-server -u 0027
This configuration applies umask 027 to all SFTP connections.
For per-user control, add a Match block:
Match User webapp
ForceCommand internal-sftp -u 0027
This block applies a specific umask only to the webapp user.
Restart SSH to apply changes:
sudo systemctl restart sshd
The SSH service restarts and applies the new configuration.
Verify SFTP applies the setting by creating a test file:
sftp user@server
put testfile.txt
The file uploads to the server with the configured permissions.
Exit SFTP and check permissions on the server:
ls -l testfile.txt
The output confirms the umask is correctly applied to SFTP uploads.
Practical Scenarios and Recommendations
For a general-purpose server where you’re the primary user, 022 is your best starting point. It protects your files from being modified by others while still allowing them to be read. This strikes a balance between security and usability.
When configuring Nginx or Apache, and multiple users need to collaborate on files, consider 002. This allows your development team or deployment processes to work with shared files. Just make sure everyone who needs access is in the appropriate group. If you’re handling sensitive data like customer information, financial records, or private keys, switch to 077. This ensures that only you can access these files. No other user on the system can even see what’s inside them, regardless of their privileges.
For application servers where you want the group to read files but not modify them, 027 provides good security. The application can run under a specific group and read necessary files, but only you can make changes. Database servers often benefit from 027 as well. This allows the database process to read configuration files while preventing unauthorized modifications that could compromise your data.
Services and Daemons
System services ignore shell settings. Configure in service files directly.
Edit the service configuration:
sudo systemctl edit nginx.service
The command opens an override file in your default editor.
Add the UMask directive:
[Service]
UMask=0022
This directive sets the umask for the service process.
Apply changes and restart:
sudo systemctl daemon-reload
The system reloads all unit files and applies configuration changes.
sudo systemctl restart nginx
The Nginx service restarts with the new umask setting applied.
Full options are available in systemd.exec documentation for advanced service configuration.
Security Best Practices
Security starts with the principle of least privilege. Give users and processes only the permissions they absolutely need to function. Your settings should reflect this philosophy.
Never use 000. This creates files with full permissions for everyone, which is a security disaster waiting to happen. Anyone on the system could read, modify, or delete your files.
For sensitive directories, use 027 or 077 even if 022 seems adequate.
Use find commands to locate files with overly permissive settings:
find /home -type f -perm -002
The command searches for and lists all world-writable files.
You can then investigate and correct these as needed.
Educate anyone who has access to your server about what this setting does and why it matters. A team member who doesn’t understand it might inadvertently change it to something insecure or create files with inappropriate permissions.
Consider implementing different values for different users based on their roles. A developer might use 002 for collaborative work, while an administrator handling sensitive configurations should use 077.
Testing and Verifying Your Umask
Verify your setting works correctly:
touch testfile.txt
The command creates an empty file for permission testing.
Check its permissions with ls -l:
ls -l testfile.txt
The output shows the file was created with the expected permissions.
Learn more about Linux file permissions for a deeper understanding of the permission string format.
This means the owner has read and write (rw-), while the group and others have read only (r–).
Create a test directory:
mkdir testdir
The command creates a new directory with default permissions applied.
Check its permissions:
ls -ld testdir
The output confirms the umask is correctly applied to new directories.
The owner has full permissions (rwx), while others can read and execute but not write (r-x).
Here’s how different values affect newly created files and directories:
| Umask | New File | New Directory | Use Case |
|---|---|---|---|
| 022 | 644 (rw-r--r--) | 755 (rwxr-xr-x) | General server admin |
| 002 | 664 (rw-rw-r--) | 775 (rwxrwxr-x) | Team collaboration |
| 027 | 640 (rw-r-----) | 750 (rwxr-x---) | Restricted group access |
| 077 | 600 (rw-------) | 700 (rwx------) | Sensitive data only |
If your permissions don’t match expectations, check that your command worked correctly:
umask
The command confirms your current umask setting.
Make sure you either reload your configuration file or start a new session after making permanent changes.
Common Issues and Solutions
If files get created with unexpected permissions, check whether the application creating them respects the setting. Some programs explicitly set their own permissions and ignore it entirely. Web servers and databases often do this for their data files.
When your changes don’t persist after logging in, verify that you edited the correct configuration file. Different shells and login methods use different files. Make sure you’re modifying the one that actually loads during your login process.
System-level settings override user-level values. If you’re setting it in your .bashrc but the system sets a different value in /etc/profile after your file runs, the system value wins. Check the order of file execution and adjust accordingly.
For applications running as services, remember they might not use your shell configuration at all. Service files and daemon startup scripts often need their own settings. Check the service configuration or startup script for these processes.
If group permissions don’t work as expected, verify that all involved users are actually members of the correct group:
groups username
The command displays all groups the specified user belongs to.
Moving Forward with Umask
Verify your settings and test them by creating some files. This hands-on practice will help solidify your understanding and ensure your server is configured the way you intend.
Remember that this is just one layer of your security strategy. Combine it with proper user management, regular permission audits, and strong authentication to build comprehensive server security.
