What Is Local Directory Permission Masking? (Chmod Codes)
Local directory permission masking describes how requested access is reduced by a umask when a program creates a file or directory. Existing permissions are controlled separately by mode bits and, where enabled, access-control lists (ACLs). Read, write, and execute mean different things on directories than on files, so check ownership, parent paths, and ACLs before changing a mode.
A directory that looks safe because its files are read-only may still allow someone to delete or rename them. On Unix-like systems, those actions often depend on write and search permission on the parent directory, not on whether the files themselves are writable. That detail makes directory permissions easy to misread.
I treat “permission masking” as two related but different mechanisms: a umask that filters permissions at creation time, and an ACL mask that can limit effective rights in an extended ACL. Neither is a complete access check on its own. Here is how to inspect both and apply the right setting without opening more access than intended.
Plan the Required Directory Access
A directory mode sets permissions for its owner, group, and everyone else. Before choosing a chmod code, decide who needs to list names, reach known entries, create items, or remove them. These are separate actions, and each may require a different permission combination.
On a directory, the three basic bits work this way:
r(read) permits listing entry names.x(execute, often called search) permits traversal and access by a known name, subject to permissions on the rest of the path and the item itself.w(write) permits changing entries, such as creating, deleting, or renaming them, when paired withx.
A person may have x without r: they can reach an entry if they know its name, but cannot list the directory. With r but no x, they may be unable to use the listed names to access entries. To create or remove entries, directory write and search access are generally both needed. Special rules, such as the sticky bit, can further restrict removal.
Read a chmod code
Each permission has a numeric value: read is 4, write is 2, and execute is 1. Add the values for each class to get a digit from 0 through 7. The three digits in a mode such as 750 represent owner, group, and other, in that order.
| Permission | Calculation | Directory meaning |
|---|---|---|
7 | 4 + 2 + 1 | List, search, and change entries |
5 | 4 + 1 | List and search, but do not change entries |
4 | 4 | List names, without search access |
3 | 2 + 1 | Search and change entries, without listing names |
0 | 0 | No access |
For example, 0750 gives the owner full access, the group read and search access, and others no access. The leading zero indicates octal notation in many tools and examples. A mode’s effect still depends on ownership, ACLs, parent directories, and the account making the request.
Check Ownership, ACLs, and Traversal Requirements
A mode is only one part of the access check. First identify the directory’s owner and group, any extended ACL entries, and whether the intended account can traverse every parent directory in the path. These checks help explain why a chmod value may appear correct while an operation still fails.
Start with these commands on Linux systems:
stat -c '%A %a %U:%G %n' -- /path/to/dir
getfacl /path/to/dir
umask
id
namei -l /path/to/dir
stat reports the mode and ownership; getfacl shows ACL entries when the tool and filesystem support them; umask displays the current shell’s mask; and id shows the current account’s groups. namei -l can show permissions along the path. These options are not identical on every Unix-like system. On some systems, use stat options documented for that platform, or inspect a path with ls -ld.
A process needs search permission on each directory in the path to reach a target. For example, access to /home/sam/docs can fail even if docs itself appears permissive, because the account lacks search access on /home or /home/sam.
A POSIX access ACL may add named-user and named-group rules. Its ACL mask limits effective permissions for named users, named groups, and the owning-group entry. It does not limit the owner entry or the other entry. getfacl may show a permission such as rwx alongside a reduced effective: value; the latter reflects the ACL mask.
| What to inspect | Command or check | What it can reveal |
|---|---|---|
| Mode and owner | stat or ls -ld | Owner, group, and mode bits |
| ACL entries | getfacl /path | Named access and ACL mask |
| Current mask | umask | Default filter in that shell |
| Account groups | id | Group membership relevant to access |
| Parent path | namei -l /path | A missing search permission higher up |
Apply Chmod Modes and Umask Deliberately
Use chmod to change permissions on an existing path. Use umask to influence permissions on objects newly created by a process. They solve different problems: changing a shell’s mask does not repair existing directories, and changing a directory’s mode does not set the mask for future creations.
For ordinary creation without an inherited default ACL, the rule is:
effective mode = requested mode & ~umask
The application requests a mode, and the mask clears bits from that request. With umask 022, a typical directory request of 0777 becomes 0755, while a typical file request of 0666 becomes 0644. Programs may request other modes, so these are common examples, not guarantees.
| Requested mode | umask | Result | Typical example |
|---|---|---|---|
0777 | 0022 | 0755 | Directory |
0666 | 0022 | 0644 | File |
0777 | 0027 | 0750 | Directory |
0666 | 0027 | 0640 | File |
To set a shell’s mask for later creations, use a deliberate value, such as:
umask 027
The setting applies to child processes launched from that shell, subject to how the application creates files. It does not change existing objects. To change one existing directory, apply a narrow mode:
chmod 0750 -- /path/to/dir
Check the result with stat and getfacl. Be careful with recursive changes: chmod -R can alter every descendant, including files that need different modes. Review the tree first, and avoid chmod -R 777; it grants broad access and search or execute permission.
If a directory has a POSIX default ACL, new entries may inherit ACL permissions. On Linux, the inherited ACL is constrained by the mode requested by the creating program; the usual umask calculation does not apply in the same way when a default ACL is present. Check the actual ACL and resulting mode rather than assuming the shell mask alone explains the outcome.
Verify Effective Permissions and Denied Operations
After a change, test access as the account that needs it. A mode listing cannot prove that an operation succeeds because ACLs, parent-directory permissions, and other system rules can affect the result. Verify each intended action and avoid testing deletion or renaming where data could be lost.
I use this sequence:
- Recheck ownership, mode, and ACL with
statandgetfacl. - Confirm the account and groups with
id. - Check search access along the full path.
- Test listing, reaching a known name, or creating a temporary entry only if that action is intended.
- Remove the test entry only when the test account is meant to have that ability.
A key edge case: directory write and search permission can allow a user to delete or rename entries even when the files themselves are not writable. A sticky bit, often used on shared temporary directories, adds a restriction on who may remove or rename entries. ACLs can also reduce the effective rights shown by a group-class mode bit.
If an operation is denied, do not immediately add broader permissions. Compare the account’s identity, the parent path, the ACL mask, and the exact operation. A read failure, a traversal failure, and a create failure point to different permission checks.
Worked Directory Scenarios
These examples are practical checks, not reports of a particular installation. They show how to translate a task into a mode and how to confirm the result. Choose values based on the users and operations that are actually required.
Private work directory. One owner needs to list, traverse, and manage entries; group and other users need no access. A typical mode is 0700. After applying it, verify the owner and test access as that owner. If another account needs access, add a carefully scoped ACL or use a suitable shared group rather than opening access to everyone.
Shared team directory. The owner and group need to work with entries, while other users should have no access. 0770 is one possible mode. Confirm that intended users belong to the directory’s group and can search every parent directory. If group members should not delete each other’s entries, consider whether a sticky-bit policy is appropriate and supported for the use case.
Directory with a named-user ACL. Suppose the owner needs full control and a named account needs read and search access. An ACL can grant that account r-x without granting the same access to all others. Inspect the ACL mask afterward: if the named entry shows r-x but its effective rights are lower, the mask is limiting it. Use setfacl only on systems and filesystems that support POSIX ACLs, then verify with getfacl.
These scenarios show why a single chmod code cannot express every sharing policy. Set the basic owner, group, and other mode first, then add ACL entries only when the needed access cannot be expressed clearly with those three classes.
Frequently Asked Questions
These short answers distinguish creation masks, directory mode bits, and ACL behavior. For a specific path, confirm the account, parent-directory access, ownership, mode, and ACL before changing permissions.
What does “local directory permission masking” mean?
It usually means permissions are filtered by a umask at creation time, or by an ACL mask when an extended ACL is present. Check which mechanism applies.
What does chmod 750 mean on a directory?
The owner can list, search, and change entries. The group can list and search. Other users receive no permissions from the mode bits.
Does umask change existing directories?
No. It affects permissions requested for newly created objects by processes using that mask. Use chmod or an ACL change to alter existing access.
Why does umask 022 often produce 755 directories?
A program commonly requests 0777 for a directory. The mask clears group and other write bits, yielding 0755.
Can a user delete a read-only file?
Yes, in many cases. If the user has write and search permission on the parent directory, they may remove or rename the entry even if the file is not writable. Special rules can apply.
What does an ACL mask do?
It caps effective rights for named users, named groups, and the owning-group ACL entry. It does not cap the ACL owner or other entries.
Why does getfacl show lower effective rights than an ACL entry?
The ACL mask may reduce the entry’s effective permissions. Review the mask and the entry together before changing either.
Is chmod -R 777 a good fix for access errors?
No. It grants broad permissions and may expose files or directories. Find the specific missing right, account, or ACL rule and change only the intended path.
How can I check whether a user can reach a directory?
Check search permission on every parent directory, then inspect the target’s owner, mode, and ACL. Test as the intended account when safe.
Does chmod always show the full ACL policy?
No. Mode bits do not show every named ACL entry. Use getfacl where POSIX ACLs are supported.
The reliable method is to define the required actions, inspect the full path and ACL, make the narrowest change, then test as the intended account. Treat umask as a creation-time control, not a repair tool for existing directories.
(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)
