Linux laptop showing a bash prompt
fatmawati achmad zaenuri/

In Linux, all directories and files have access permissions. You can use chmod to set your preferred access rights for different users. But what decides their default permissions? Let’s talk about umask.

Access Permissions

All directories and files have flags called mode bits that decide whether they can be read, written to, or executed. Executing a file means running it like a program or a script. For a directory, you must be able to “execute” a directory to cd into it. Collectively the bit mode settings are called the permissions of the directory or file.

There are three sets of permissions. One set is for the owner of the directory or file. Unless the ownership has been changed with chown, the owner is the person who created the directory or file.

The second set of permissions is for the members of the user group that the directory or file has been assigned to. Usually, this is the user group of the owner.

There’s a third and final set of permissions for “others.” It’s a catch-all for everyone not contained in the first two sets.

By separating out the permissions like this, different capabilities can be given to the three categories. This is how directory and file access is controlled in Linux. Although it is a simple scheme, it provides a flexible and robust way to dictate who can do what with any directory or file.

The Mode Bits

You can see the permissions for files by using the ls command and the -l (long format) option.

ls -l any*

We’ll also look at a directory by adding the -d (directory) option. Without this option, ls would look at the files inside the directory, not at the directory itself.

ls -ld

Using ls to see the permissions on directories and files

At the start of each entry in the ls listing, there is a collection of 10 characters. Here’s a close-up of those characters for a file and for a directory.

The permissions of a file and directory, close up

The file is the top line, the directory is the lower line. The very first character tells us whether we’re looking at a directory or a file. A “d” indicates a directory and a dash “-” indicates a file.

The three sets of permissions are indicated by each group of three characters. From left to right these are the permissions for the owner, the group, and others. In each set of permissions the three characters, from left to right, indicate the setting for the read permission “r”, the write permission “w”, and the execute “x” permission. A letter means the permission is set. A dash “-” means the permission is not set.

For our example file, the 10 characters mean:

  • : This is a file, not a directory.
  • rwx: The owner can read, write, and execute this file.
  • rw-: Other members of the same group this file is assigned to can read and write to the file, but they cannot execute it.
  • r–: Everyone else can only read the file.

For our example directory, the 10 characters mean:

  • d: This is a directory.
  • rwx: The owner can read, write, and execute (cd into) this directory.
  • rwx: Other members of the same group can read, write, and cd into this directory.
  • r-x: Everyone else can cd into this directory, but they can only read files. They cannot delete files, edit files, or create new files.

The permissions are stored in mode bits in the metadata of the directory or file. Each mode bit has a numerical value. They all have a value of zero if they are not set.

  • r: The read bit has a value of 4 if set.
  • w: The write bit has a value of 2 if set.
  • x: The execute bit has a value of 1 if set.

A set of three permissions can be represented by the sum of the bit values. The maximum value is 4+2+1=7, which would set all three permissions in a set to “on.” That means all permutations of all three sets can be captured in a three-digit Octal (base 8) value.

Taking our example file from above, the owner has read, write, and execute permissions, which is 4+2+1=7. Other members of the group the file is in have read and write permissions, which is 4+2=6. The others category only has the read permission set, which is simply 4.

So the permissions for that file can be expressed as 764.

Using the same scheme, the permissions for the directory would be 775. You can see the Octal representation of the permissions using the stat command.

The chmod (change mode bits) command is the tool used to set the permissions on directories and files. But it doesn’t dictate what permissions are set on a directory or file when you create it. A default set of permissions is used for that.

The Default Permissions and umask

The default permissions for a directory are 777, and the default permissions for a file are 666. That gives every user full access to all directories, and the ability to read and write any file. The execute bit is not set on files. You can’t create a file that already has the execute bit set. That could give rise to security risks.

However, if you create a new directory and a new file and look at their permissions, they won’t be set to 777 and 666. We’ll create a file and a directory, then use stat piped through grep to extract the line with the Octal representation of their permissions.

touch umask-article.txt
mkdir howtogeek
stat umask-article.txt | grep "Access: ("
stat howtogeek | grep "Access: ("

default permissions for a directory and file, and the stat output for each of them

They’re set to 775 for the directory and 664 for the file. They’re not set to the global default permissions because another value modifies them, called the umask value.

The umask Value

The umask value is set globally with one value for root and a different one for all other users. But it can be set to a new value for anyone. To see what the current umask setting is, use the umask command.


The umask value for a regular user

And for root:


The umask value for the root user

The permissions on a newly-created directory or file are the result of the umask value modifying the global default permissions.

Just like the mode bits, the umask value represents the same three sets of permissions—owner, group, and others—and represents them as three Octal digits. You’ll sometimes see them written as four digits, with the first digit a zero. That’s a shorthand way to say “this is an octal number.” It’s the right-most three digits that count.

The umask value cannot add permissions. It can only remove—or mask out—permissions. That’s why the default permissions are so liberal. They’re designed to be reduced to sensible levels by the application of the umask value.

One set of default permissions isn’t going to suit all users, nor will it suit all scenarios. For example, directories and files created by root are going to need more restrictive permissions than the average user. And even an average user doesn’t want everyone in the others category able to see and change their files.

How umask Masks Out Permissions

Subtracting the mask value from the default permissions gives you the actual permissions. In other words, if a permission is set in the umask value it will not be set in the permissions applied to the directory or file.

The umask values work as an inverse of the usual permission values.

  • 0: No permissions are removed.
  • 1: The execute bit is unset in the permissions.
  • 2: The write bit is unset in the permissions.
  • 4: The read bit is unset in the permissions.

The default permissions of 777 for directories and 666 for files were modified by the umask value of 002 to yield the eventual permissions of 775 and 664 on our test directory and file.

stat umask-article.txt | grep "Access: ("
stat howtogeek | grep "Access: ("

The eventual permissions on a directory and file

This removes the write permission from the others category on both the directory and the file.

if root creates a directory, their umask value of 022 is applied. The write permission is removed for the others category and for the group category too.

sudo mkdir root-dir
stat howtogeek | grep "Access: ("

The permission when root creates a directory

We can see that the default permissions of 777 have been reduced to 755.

RELATED: How to Audit Your Linux System's Security with Lynis

Changing the Default umask Value

There are different umask values for login shells and non-login shells. Login shells are the shells that let you log in, either locally or remotely over SSH. A non-login shell is a shell inside a terminal window when you’re already logged in.

Be very careful if you change the login shell umask. Don’t increase the permissions and lower your security. If anything, you should be inclined to reduce them and make them more restrictive.

On Ubuntu and Manjaro, the umask settings can be found in these files:

  • Login Shell umask: For the login shell default umask value: /etc/profile
  • Non-Login Shell: For the non-login shell default umask value: /etc/bash.bashrc

On Fedora, the umask settings can be found in these files:

  • Login Shell umask: For the log in shell default umask value: /etc/profile
  • Non-Login Shell: For the non-login shell default umask value: /etc/bashrc

If you don’t have a pressing need to change these, it’s best to leave them alone.

The preferred way is to set a new umask value for any individual user accounts that need to differ from the default. A new umask setting can be put in a user’s “.bashrc” file in their home directory.

gedit .bashrc

Opening the .bashrc file in an editor

Add your umask setting near the top of the file.

Adding the umask value to the .bashrc file

Save the file and close the editor. open a new terminal window and check the umask value with the umask command.


Checking the new umask value

The new value is active.

RELATED: How to Connect to an SSH Server from Windows, macOS, or Linux

Short-Term Changes to umask

If you have a short-term requirement for a different umask value, you can change it for your current session using the umask command. Perhaps you’re going to create a directory tree and some files and you want to have increased security on them.

You could set the umask value to 077, then check the new value is active.

umask 077

Setting a temporary umask value

Setting the mask to have a value of 7 in the group and others categories means all permissions are stripped from those categories. No one but you (and root) will be able to enter the new directories and read and edit your files.

mkdir secure-dir
ls -ld secure-dir

Creating a new directory in a session with a temporary umask value

The only permissions are for the directory owner.

mkdir secure-file.txt
ls -ld secure-file.txt

Creating a new file in a session with a temporary umask value

The file is secure against snooping from any other users. Closing your terminal window discards the temporary umask setting.

Other Ways umask Is Used

Linux allows some processes to inherit system umask values, or to be given their own umask settings. For example, useradd uses a umask setting to create new users’ home directories.

A umask value can be applied to a filesystem too.

less /etc/fstab

Looking at the /etc/fstab file with less

On this computer, the “/boot/efi” filesystem has a umask setting of 077 applied to it.

The umask setting in the /etc/fstab file

Looking at the filesystem mount point with ls we can verify that the umask value has removed all permissions from everyone apart from the owner, root.

ls /boot/efi -ld

Using ls to see the permissions on the "/boot./efi" filesystem mount point

umask and Permissions Need Each Other

Default permissions are applied to a directory or file after they’ve been transformed by the umask value. It will be very rare that you need to change the umask value permanently for a user, but temporarily setting your umask value to give a tighter set of permissions while you create a collection of sensitive directories or documents is a fast and easy way to bolster their security.

RELATED: How to Secure Your Linux Server with a UFW Firewall

Profile Photo for Dave McKay Dave McKay
Dave McKay first used computers when punched paper tape was in vogue, and he has been programming ever since. After over 30 years in the IT industry, he is now a full-time technology journalist. During his career, he has worked as a freelance programmer, manager of an international software development team, an IT services project manager, and, most recently, as a Data Protection Officer. His writing has been published by,,, and Dave is a Linux evangelist and open source advocate.
Read Full Bio »