Understanding umask: Default File Permissions in Linux

What Is umask and What Problem It Solves

Every time you create a new file or directory on a Linux system, the operating system needs to decide what permissions to assign it. Should it be readable by everyone? Writable only by you? Executable? The umask (user file-creation mode mask) is the mechanism that answers this question.

Without umask, every newly created file would have the maximum permissions the creating program requests, which is typically 666 for files and 777 for directories. That would mean every new file is world-readable and world-writable by default -- a clear security problem on any multi-user system. The umask acts as a filter, automatically removing (masking out) permissions that you do not want applied to new files.

Think of umask as a set of permissions that are subtracted from the maximum. It defines what permissions should be denied by default, not what should be granted.

How umask Works: The Calculation

The actual permission assigned to a new file or directory is calculated by starting with the base permissions and removing the bits specified by the umask. The base permissions differ for files and directories:

• Files: Base permission is 666 (read and write for everyone, no execute). Programs do not typically need execute permission when first created.
• Directories: Base permission is 777 (read, write, and execute for everyone). Directories need the execute bit to allow traversal with cd.

The formula is straightforward: final permission = base permission AND NOT umask. In practice, you can think of it as subtracting each umask digit from the corresponding base digit, though the actual operation is a bitwise AND with the complement.

The subtraction analogy works for most common cases, but it is technically a bitwise operation. For example, a umask of 033 applied to a base of 666 gives 644 (not 633), because the execute bit cannot be subtracted from a base that does not have it. Use our umask calculator to experiment with different values and see the exact results.

Reading the umask: The umask Command

To check the current umask value, simply run the umask command in your terminal:

# Display current umask in octal
$ umask
0022

# Display in symbolic notation
$ umask -S
u=rwx,g=rx,o=rx

The output 0022 has four digits. The leading zero is the special permissions mask (setuid, setgid, sticky), which is almost always zero. The remaining three digits are the owner, group, and others masks respectively.

The symbolic output (umask -S) shows the resulting permissions for directories (not the mask itself). This can be easier to read: u=rwx,g=rx,o=rx tells you directly that new directories will get 755.

Common umask Values

Different environments call for different umask settings. Here are the three most common values and when to use each:

022 -- The System Default

This is the default umask on most Linux distributions. It removes write permission for group and others, resulting in:

• Files: 644 (rw-r--r--) -- owner reads/writes, everyone else reads
• Directories: 755 (rwxr-xr-x) -- owner has full access, everyone else can read and traverse

This strikes a balance between usability and security: your files are readable by others (useful for web servers and shared systems) but not writable (preventing accidental or malicious modification).

002 -- Group-Friendly

This umask only removes write permission for others, keeping it for the group:

• Files: 664 (rw-rw-r--) -- owner and group read/write, others read
• Directories: 775 (rwxrwxr-x) -- owner and group have full access, others can read and traverse

This is ideal for collaborative development environments where team members share a group. Combined with the setgid bit on shared directories, it ensures all team members can modify each other's files.

077 -- Private / Restrictive

This umask removes all permissions for group and others:

• Files: 600 (rw-------) -- only owner can read and write
• Directories: 700 (rwx------) -- only owner can access

This is the most secure option, appropriate for systems handling sensitive data, multi-tenant servers, or any environment where files should be private by default. It is also common in security-hardened configurations and compliance environments.

Setting umask: Temporary vs Permanent

Temporary (Current Session Only)

To change the umask for your current shell session, simply run the umask command with the desired value:

# Set for current session only
umask 077

# Verify it took effect
umask
0077

This change lasts only until you close the terminal or start a new session. It is useful for one-off tasks where you need different default permissions.

Permanent (Persists Across Sessions)

To make a umask change permanent, add it to a shell configuration file. The right file depends on the scope you want:

# Per-user: add to ~/.bashrc or ~/.profile
echo "umask 022" >> ~/.bashrc

# System-wide: add to /etc/profile or /etc/login.defs
# Edit as root:
sudo echo "umask 022" >> /etc/profile

# On systems using PAM, you can also configure:
# /etc/pam.d/common-session
# session optional pam_umask.so umask=022

# For login.defs (affects login sessions):
# UMASK 022

The order of precedence matters: values in ~/.bashrc override /etc/profile, and PAM settings can override both. When debugging umask issues, check all these locations to find where the active value is being set.

umask in Practice: New File and Directory Defaults

Let us walk through exactly what happens when you create files and directories with different umask values:

Security Implications

The choice of umask has direct security consequences. A permissive umask (000 or 002) means that newly created files -- including log files, temporary files, and configuration files -- are readable or writable by others by default. If a process writes sensitive data (like tokens, passwords, or session data) to a file, a permissive umask could expose that data to every user on the system.

Security-hardened Linux configurations (such as CIS benchmarks) typically recommend a umask of 027 or 077. This ensures that sensitive files are never accidentally exposed. The trade-off is that team members may need to explicitly grant group access to shared files, but this is generally preferred over accidental exposure.

Pay special attention to umask in automated scripts and service configurations. A cron job might inherit a different umask than your interactive shell, leading to files created by automated processes having unexpected permissions.

Docker and Container umask Considerations

Containers add another layer of complexity to umask management. By default, Docker containers inherit the umask from the Docker daemon, which is typically 022. However, this can lead to unexpected behavior:

• Volume mounts: Files created inside a container on a mounted volume use the container's umask, but the host filesystem enforces its own permission rules. This frequently causes permission conflicts, especially when the container runs as root but the host user is non-root.
• Multi-stage builds: Each RUN instruction in a Dockerfile inherits the umask from the build environment. If your build creates configuration files or certificates, set the umask explicitly before those steps.
• Entrypoint scripts: It is good practice to set the umask explicitly at the beginning of container entrypoint scripts, especially for containers that handle sensitive data:

#!/bin/bash
# Set restrictive umask for the container process
umask 027

# Continue with application startup
exec "$@"

Some container orchestration platforms (like Kubernetes) allow setting the umask via security contexts or init containers. For Kubernetes, the securityContext.fsGroup field and supplemental groups can also affect how volume permissions work.

Try It Yourself

The umask calculation can be confusing until you see it in action. Use the Umask tab in our chmod calculator to experiment with different umask values and instantly see the resulting file and directory permissions. You can also do reverse lookups -- enter the permissions you want and let the tool calculate the required umask.