Start with the path that failed and the identity of the process using it. Inspect the current mode with ls -l or stat, confirm user and group membership with id, and check inherited rules with getfacl. Use chmod only when existing mode bits are wrong. Change umask only when future files or directories are created with the wrong defaults.
A current path fails: check owner, group, mode bits, parent-directory execute permission, and ACLs before changing anything. Use chmod only when the existing mode is the cause; use chown or chgrp when ownership is wrong.
Every new file is created wrong: inspect the creating shell, service, or container process and its umask. With umask 022, new files commonly become 644 and directories 755. A umask change never repairs files that already exist.
chmod changes permissions on existing files; umask controls default permissions for files and directories created later by the current process or its children.
When you need to check a value before posting an answer, writing deployment notes, or changing a server, use the Umask Calculator for Linux defaults for new-file defaults and the Chmod Calculator for existing files for explicit modes.
Focused value breakdowns are available for umask 0022 / 022, umask 0027 / 027, and umask 0077 / 077. Use the short chmod vs umask comparison when you only need to choose between the commands; stay on this page when ownership, groups, parent directories, setgid, or ACLs may be involved.
Run the checks in this order before changing a production directory, Docker bind mount, shared team folder, or Syncthing path.
| Question | Command | Decision |
|---|---|---|
| Does the target already exist? | ls -l path |
If the mode on disk is wrong, use chmod. If only future files are wrong, inspect umask instead. |
| What owner, group, and mode are on disk? | stat -c "%U %G %a %n" path |
Use the octal mode to decide whether the problem is chmod, ownership, or group access. |
| Who is the running process? | id or id service-user |
If the process is not in the expected group, chmod alone will not fix the write path. |
| Are ACLs overriding the simple rwx view? | getfacl path |
Default ACLs can control new files inside shared directories even when umask looks correct. |
| Are newly created files wrong? | umask |
Set the mask in the shell, service unit, container environment, or application startup path that creates the files. |
umask is the file mode creation mask used by Unix-like systems, including Linux and macOS. It does not add permissions. It removes permission bits from the maximum mode requested when a process creates a file or directory. In everyday shell work, regular files commonly start from 666 and directories commonly start from 777. The mask then blocks selected bits.
That is why umask 022 creates files 644 and directories 755 in common cases. The group and others lose write permission. The owner keeps read and write on files, and read, write, and execute on directories. Directories keep execute bits because execute on a directory means search or traverse permission: without it, users cannot enter the directory or resolve files inside it.
umask is usually set per shell session or process. A login shell, service manager, container entrypoint, CI job, or daemon can have a different mask. Child processes inherit the current mask unless it is changed. Changing umask does not repair existing files, and it does not guarantee that every application will request the broadest possible mode. Some tools deliberately create private files with a narrower mode regardless of your shell default.
chmod changes the permission mode of files and directories that already exist. You can set modes with octal values such as chmod 755 app.sh, with symbolic operations such as chmod u+x app.sh, or recursively with caution. It does not control future creation defaults. It does not change file ownership; use chown when the user or group owner is wrong.
The three octal digits usually describe owner, group, and others. Read is 4, write is 2, execute is 1. Add them to get each digit. For example, 7 is read plus write plus execute, 5 is read plus execute, and 4 is read only. That makes 755 equal to owner rwx, group r-x, and others r-x.
Use WebUtilsLab Chmod Calculator when you want to convert checkboxes or rwx notation into octal before copying a command. It is especially useful when comparing 644, 755, 700, 600, and risky 777 cases.
| Question | Use umask | Use chmod |
|---|---|---|
| Does the file already exist? | No. umask affects future files and directories. | Yes. chmod changes current permission bits. |
| What does it control? | Default permission mask inherited by a process. | Actual mode on a file or directory. |
| Common example | umask 022 produces files 644 and directories 755. |
chmod 755 script.sh makes an existing script executable. |
| Best fit | Deploy user defaults, service output, generated files, shared team directories. | Fixing a specific file, setting a script executable, correcting web assets. |
| Common mistake | Expecting umask to change files that already exist. | Using recursive chmod when the real problem is future file creation. |
Use this table as a permission sanity check before changing a login profile, service unit, container entrypoint, or deployment script. The exact result assumes common file creation defaults: files from 666 and directories from 777.
| Umask | New files | New directories | Typical use |
|---|---|---|---|
0022 / 022 |
644 / rw-r--r-- |
755 / rwxr-xr-x |
Common default where files can be read by group and others, but only the owner writes. |
0002 / 002 |
664 / rw-rw-r-- |
775 / rwxrwxr-x |
Trusted shared groups where collaborators need group write access. |
0027 / 027 |
640 / rw-r----- |
750 / rwxr-x--- |
Team-private output where the group may read or enter, and others get no access. |
0077 / 077 |
600 / rw------- |
700 / rwx------ |
Owner-only defaults for private notes, secrets, generated reports, and service output. |
A normal file is not created executable by default. Start from 666, then remove group write and other write with 022. The result is 644, or rw-r--r--.
umask 022
touch demo-file
mkdir demo-dir
ls -l demo-file
ls -ld demo-dirOn Linux you can inspect octal modes with stat -c "%a %n" demo-file demo-dir. On macOS, use stat -f "%Lp %N" demo-file demo-dir.
If a script already exists and fails with permission denied because it is not executable, umask is the wrong tool. Use chmod on the file that exists.
ls -l deploy.sh
chmod 755 deploy.sh
./deploy.shIf the script is private to one user, chmod 700 deploy.sh may be more appropriate than 755. The right mode depends on who should read or execute it.
A team deployment user may need group-writable files so other members of the same Unix group can update generated assets. In that case, a common choice is umask 002, producing files 664 and directories 775. This only makes sense when group ownership and membership are correct.
umask 002
touch shared.log
mkdir shared-cache
stat -c "%a %n" shared.log shared-cacheIf the file still cannot be written by teammates, check the group owner with ls -l, confirm membership with id, and inspect inherited rules with getfacl. Use chgrp, chown, a setgid directory, or a default ACL when ownership inheritance is the real problem.
For service accounts that generate sensitive files, umask 077 is often safer. It usually creates files as 600 and directories as 700. That keeps group and others out by default.
umask 077
touch private-report.txt
mkdir private-cache
stat -c "%a %n" private-report.txt private-cacheUse the umask 0077 / 077 section of the calculator when you want a focused breakdown of this private default.
Use umask 027 when a service should let the owning user write, let the trusted group read or enter, and block everyone else. A common case is a build or report job that writes artifacts for an operations group but should not expose them to other local users.
umask 027
touch team-report.txt
mkdir team-cache
stat -c "%U %G %a %n" team-report.txt team-cache
idIf group members cannot read the result, first confirm the file group and user membership. Do not switch to chmod 777; fix the group owner, setgid parent directory, or default ACL so the next files inherit the intended team access.
| Symptom | Likely cause | What to check |
|---|---|---|
| New files are 644, but you expected 755. | Regular files normally start from 666, so execute bits are not added by umask. | Use chmod +x file or set an explicit mode in the creating program. |
| Changing umask did not fix old files. | umask only affects future creation. | Use chmod for existing files and directories. |
| Group members still cannot write. | Group ownership, group membership, setgid behavior, or default ACL inheritance may be wrong. | Check stat -c "%U %G %a %n", id, getfacl, and whether the directory should use a setgid bit or default ACL. |
| A service creates files with a different mode than your shell. | The service runs with its own environment and inherited mask. | Check the service manager, container entrypoint, startup script, or application settings. |
| You are tempted to use chmod 777. | The underlying ownership or group model is unclear. | Fix owner, group, directory execute bits, and write scope instead of opening access to everyone. |
Recursive chmod is powerful and easy to over-apply. A common pattern is to set directories and files separately because directories need execute permission for traversal while normal files usually do not need execute permission.
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;Do not paste broad recursive commands into an unknown directory. Print the target list first, confirm you are in the right path, and check whether symbolic links, mounted volumes, generated caches, or uploaded files need different handling.
Last verified July 10, 2026. The commands on this page assume a Linux host with GNU-style command output and POSIX ACL tools. Command flags and ACL behavior can differ on macOS, BSD, network filesystems, and filesystems without ACL support.
umask(2) manual for process masks, file creation, inheritance, and the effect of default ACLs.chmod, stat, id, chown, and chgrp behavior.acl(5) manual for access ACLs, default ACL inheritance, and their relationship with mode bits.Use these pages together when you need an answer you can link from a ticket, forum reply, GitHub issue, or deployment note.
No. umask controls default permissions for new files and directories created after the mask is set. chmod changes permission bits on files or directories that already exist.
Common file creation starts from 666 and directory creation starts from 777. umask 022 removes write permission from group and others, so files become 644 and directories become 755.
No. umask only affects future file and directory creation by that process or by child processes that inherit the mask.
Usually no. chmod 777 gives everyone read, write, and execute access. Check ownership, group membership, directory execute bits, and the specific command that failed first.
For common Linux and Unix shell use, 077 and 0077 describe the same permission mask. The extra leading zero is octal notation.
Regular files normally start from 666, not 777, so execute bits are not added by default. Use chmod +x on scripts that should be executable.
No. chmod changes permission bits. Use chown to change the user or group owner.
umask 077 is a common owner-only default for private output because new files usually become 600 and new directories usually become 700.