Does umask change permissions of files that already exist?

No. umask is a mask that applies only at the moment a process CREATES a new file or directory. Files already on disk keep their permissions until a command modifies them explicitly (for example, chmod). Changing umask only affects what is created from that point on.

Why do new files not have execute permission by default?

Because the maximum mask the formula starts from is 666, not 777. The system assumes that most files are data rather than programs, and that granting execute should be an explicit user decision (with chmod +x). If you need an executable script, the correct flow is to create it and then add the execute bit — not to expect umask to do it.

No. umask 000 leaves new files at 666 (rw-rw-rw-) and new directories at 777 (rwxrwxrwx), which means every user on the system can read, write and — for directories — modify the contents. It is the opposite of a safe default and essentially has no legitimate use outside short-lived test environments.

How does umask relate to chmod?

They are complementary. umask sets the default permissions for new files and directories. chmod audits and changes the permissions of files that already exist. A coherent workflow uses umask so new files start in a reasonable state and chmod to adjust whatever drifts off that baseline.

Does umask also apply when I use tools like cp or tar?

It depends. cp by default preserves the source file's permissions when it has enough access, so umask does not come into play during a normal copy. tar on extraction may or may not honour umask depending on the flags and the version. Rule of thumb: umask kicks in when a file is created from scratch; when a file is restored from a backup, check permissions with ls -l.

What umask means in Linux and how to choose 022, 027 or 077

How umask sets default permissions on Linux: the 666 & ~umask formula for files and 777 & ~umask for directories, values 022, 027, 077, 002, and how umask complements chmod rather than replacing it.

What umask does

umask is a mask that every process inherits and that sets the permissions new files and directories will land with. It is not a command that runs against existing paths; it is a value in the process environment (shared between the shell and the children it spawns) which the kernel consults whenever open(O_CREAT) or mkdir is invoked. The kernel takes the permissions the process requested, masks them with umask, and stores the result.

That indirection matters because it lets you define session- or service-level defaults without touching each tool. Set umask 077 in your shell and everything created from that terminal lands in 600 / 700 without each program having to know. The price is that the mask affects everything created in that session: pick a value coherent with the user's role.

umask does not modify existing files

The most common misunderstanding, worth clearing up upfront: umask only affects the moment of creation. If you change umask in your session, files already on disk keep the permissions they had. To audit and fix existing permissions — tightening a secret created with lax defaults, narrowing a web directory left too open — the right tool is chmod.

That boundary between defaults and corrections is why ToolsOps ships two calculators: one to reason about defaults (umask) and another to inspect and adjust specific permissions (chmod). Both live in the Linux permissions hub and complement each other: umask for the create flow, chmod for the audit flow.

The formula: files 666 & ~umask, directories 777 & ~umask

For regular files the kernel starts from 666 (rw-rw-rw-) — the maximum applicable to a file without explicitly requesting execute. For directories it starts from 777 (rwxrwxrwx) — the maximum applicable to a directory, including the x bit that allows traversal. It then ANDs with the complement of umask: bits set in umask are subtracted from the maximum.

Worked examples:

umask 022 → files 644 (rw-r--r--), directories 755 (rwxr-xr-x).
umask 027 → files 640 (rw-r-----), directories 750 (rwxr-x---).
umask 077 → files 600 (rw-------), directories 700 (rwx------).
umask 002 → files 664 (rw-rw-r--), directories 775 (rwxrwxr-x).
umask 000 → files 666, directories 777 (unrestricted defaults; not a recommended value).

Why files do not get execute by default

Choosing 666 as the file maximum is not arbitrary: the principle is that execution should be an explicit concession. Creating files with the x bit set by default would mean any piece of data — a freshly downloaded CSV, a YAML pasted to disk, a .sh that has not been reviewed yet — could be executed without action. The system prefers to make you type chmod +x when you actually mean it.

For directories the picture is different: x on a directory is not program execution but the right to enter it (cd, list with stat, etc.), so a maximum of 777 is reasonable. The 666 / 777 asymmetry between files and directories reflects that semantic difference.

Differences between 022, 027, 077, 002 and 000

Each value targets a different usage profile. 022 is the historical default on many distributions for personal environments: the owner keeps full control and the rest of the system can read. 027 tightens that by closing read to “others” but leaves the group with read — handy when a workgroup shares files without exposing them to the whole system. 077 is the strict choice: files only accessible to the owner, no access from outside. 002 is used in collaborative environments where the group also writes — typical on servers where a developer group shares a project tree.

000 is the absence of a mask: everything is permitted. It is the opposite of a safe default and should not be used on workstations or servers. It occasionally shows up in ephemeral test environments; outside that context, no.

What to pick by context

Personal single-user workstation: 022 is reasonable for general use. 077 if you handle sensitive data and want to reduce surface from human error (for example, when you paste a secret into a file).
Multi-user server: 027 as a baseline — preserves read access for the group (useful for monitoring or backup tools in a specific group) while closing access to users outside the project.
Group-shared folders: 002 combined with setgid on the parent directory lets every group member write and makes new files inherit the directory's group. It is the standard pattern for shared repositories.
Secrets and SSH / TLS / GPG keys: 077. Files must belong to the owner only. After creating the key, the right flow is to verify with ls -l that it landed in 600.

umask versus chmod

The two commands coexist because they handle different moments in a file's lifecycle. umask acts when a process asks the kernel to create something; it is preventive, defining the initial state. chmod acts when the file already exists; it is corrective, adjusting the current state.

A coherent routine combines both: a sensible umask at user or service scope (027 or 077 depending on the role), plus a periodic review with chmod when anything drifts. To inspect and adjust specific permissions, the chmod calculator translates between octal, symbolic and the output of ls -l. For the deeper rationale of each chmod mode, the Linux chmod permissions guide covers 755, 644, 777, setuid, setgid and the sticky bit.

How to use the umask calculator

The ToolsOps umask calculator accepts 3-digit octal values and shows the resulting permissions for files and directories in rwx, octal and symbolic notation. It is useful for confirming — before adding a line to /etc/profile, to a systemd unit, or to a Dockerfile — what permissions files created from that context will actually receive. All logic runs in your browser: the value you type never leaves your machine.

Frequently asked questions

Does umask change permissions of files that already exist?: No. umask is a mask that applies only at the moment a process CREATES a new file or directory. Files already on disk keep their permissions until a command modifies them explicitly (for example, chmod). Changing umask only affects what is created from that point on.
Why do new files not have execute permission by default?: Because the maximum mask the formula starts from is 666, not 777. The system assumes that most files are data rather than programs, and that granting execute should be an explicit user decision (with chmod +x). If you need an executable script, the correct flow is to create it and then add the execute bit — not to expect umask to do it.
Is umask 000 safe?: No. umask 000 leaves new files at 666 (rw-rw-rw-) and new directories at 777 (rwxrwxrwx), which means every user on the system can read, write and — for directories — modify the contents. It is the opposite of a safe default and essentially has no legitimate use outside short-lived test environments.
How does umask relate to chmod?: They are complementary. umask sets the default permissions for new files and directories. chmod audits and changes the permissions of files that already exist. A coherent workflow uses umask so new files start in a reasonable state and chmod to adjust whatever drifts off that baseline.
Does umask also apply when I use tools like cp or tar?: It depends. cp by default preserves the source file's permissions when it has enough access, so umask does not come into play during a normal copy. tar on extraction may or may not honour umask depending on the flags and the version. Rule of thumb: umask kicks in when a file is created from scratch; when a file is restored from a backup, check permissions with ls -l.