Linux decides file access by comparing two things: the credentials of the process making the request, and the owner, group, mode bits and ACL attached to the file. The path leading to the file matters too. Most “permission denied” puzzles come from looking at only one of these. This guide explains the model from the process outward. It covers what chmod 755 and chmod 644 mean, how to change an owner or group, and why a file can be inaccessible when its permissions look right. It also gives an inspection-first workflow so you don’t reach for chmod -R 777.
How does Linux decide who can access a file?
Internally, Linux uses numeric user and group IDs. Account names such as alice or www-data are human-readable labels mapped to those numbers. A running process carries several identities: real and effective IDs, filesystem IDs, and supplementary groups. For ordinary file permission checks, the filesystem user and group IDs and the supplementary groups matter most. The Linux credentials documentation notes that the filesystem IDs normally track the effective IDs, although Linux-specific calls can make them differ.
The practical consequence is that a file’s owner and group are separate from the identity of whoever is trying to open it. When you type a command, the process runs with your credentials. When a web server, container, cron job or sudo command runs, the process has its own credentials, which may be quite different from yours. “I can read it” says nothing about whether the service can.
How do Linux file permissions work?
Three classes, three bits each
Every file has a mode with three classes: user (the owner), group, and other. Each class has read (r), write (w) and execute (x) bits. ls -l shows them as a string like -rw-r-----: the first character is the file type, then owner, group and other triplets.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
The GNU chmod manual summarizes the symbolic letters this way: “The letters rwxXst select file mode bits for the affected users.” Besides the basic bits, a mode can carry special set-ID and sticky bits (the s and t in that sentence).
What the bits mean on files versus directories
| Bit | On a file | On a directory |
|---|---|---|
| Read (r) | Read the contents | List the names inside |
| Write (w) | Modify the contents | Change directory entries (create, remove, rename), subject to other controls |
| Execute (x) | Run it as a program | Search/traverse: reach things by name inside it |
The chmod manual describes execute on a directory explicitly as “search”. That is why a perfectly readable file can be unreachable: you need search permission on every directory along its path.
What do chmod 755 and chmod 644 mean?
In octal notation each class is one digit: read is 4, write is 2, execute is 1, and you add them up. Three digits give owner, group and other in that order.
| Mode | Owner | Group | Other | Typical use |
|---|---|---|---|---|
| 644 | rw- (4+2) | r– (4) | r– (4) | Ordinary files readable by everyone, writable only by the owner |
| 755 | rwx (4+2+1) | r-x (4+1) | r-x (4+1) | Programs and directories that everyone may run or traverse, but only the owner may modify |
| 640 | rw- | r– | — | Files shared with one group and hidden from everyone else |
| 600 | rw- | — | — | Private to the owner |
Note that 644 is not “more permissive than 600” across the board. Compared with 600, it adds read access for group and other, but it grants them no write access.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Symbolic form
GNU chmod also accepts symbolic modes, which change specific bits without replacing the rest:
chmod 640 file: set exactly owner read/write, group read, other nothing.chmod u+x script: add execute for the owner and leave all other bits untouched.
How do I change a file’s owner or group?
chmod changes mode bits only. It never changes who owns the file. Ownership is handled by chown:
chown user path: change the owner.chown user:group path: change owner and group together.chown :group path: change only the group (GNUchownaccepts a group-only form).
Whether the request succeeds depends on the caller’s privileges and system policy, so ownership changes commonly require administrator rights. Check the result with ls -l path or stat path, which also shows the numeric mode.
What does umask do to new files?
umask is a creation mask. When a program calls open, mkdir or a similar creation call, the mask turns off permission bits that the program requested. The Linux umask(2) manual gives the standard example: a requested mode of 0666 with a mask of 022 gives 0644, “because 0666 & ~022 = 0644; i.e., rw-r–r–.”
That is an example, not a guarantee. A program can request a different starting mode, and your shell’s mask may not be 022. Run umask with no arguments to see the current value.
There is an important exception. If the parent directory has a default ACL, new children inherit it and the umask is ignored, although permissions absent from the creation mode are still turned off. This is why files created in a shared directory sometimes don’t match the “0666 minus umask” arithmetic.
Rank #4
When are the three classes not enough? ACLs
An access ACL can add entries for named users and named groups, beyond the single owner, single group and everyone else. ACL permissions are a superset of the traditional bits. When an ACL mask exists, the group-class bits in the mode correspond to that mask. The mask can cap the effective permissions of named user and group entries, so an entry can look generous yet grant less than it appears to.
- Use
getfacl pathto see the entries and the mask, where ACL tools and filesystem support are present. - Access ACLs apply to an existing object. Default ACLs live on directories and shape the permissions of newly created children.
- If you edit ACLs, verify afterward with
getfacland by testing as the affected identity.
As a result, ls -l alone does not tell the whole ACL story, and the group column may not reflect what a named entry or the mask actually allows.
Why can’t I access a file even though its permissions look correct?
Work through the checks in this order. Each step rules out one layer before you change anything.
Best Value
- Confirm the exact path and the failing identity. If a service, container, scheduled job or
sudocommand is involved, it is that process’s credentials that count, not yours. - Inspect the process identity. Run
idin the relevant context;groupsgives a readable membership list. A group membership change may not reach an already-running process, so start a fresh login session or restart the service before concluding the change didn’t work. - Inspect the file and every parent directory. Use
ls -lorstaton the file and each directory above it, and confirm the process has search (x) permission on each component. - Inspect ACLs. Run
getfacland check named entries, the mask and any default ACL on the parent. - Make the narrowest change that matches the intent, then verify as the affected identity, not as yourself.
This sequence covers the discretionary permission model, but it isn’t a guarantee that mode bits explain every denial. If the credentials, path, modes and ACLs all check out, consider mount options, capabilities, security modules and namespaces. These are the other layers of system policy that can participate.
Choosing the right remedy
| Question | Options |
|---|---|
| Who needs access? | Owner only, a group, a specific named user or group (ACL), or everyone |
| File or directory? | Directories need x to be traversed; files need x only to be run |
| Should it persist for new files? | Mode bits fix one existing object; a default ACL on a directory shapes future children |
| How broad is the change? | One object, or a recursive tree |
Why is chmod -R 777 the wrong first move?
Recursive chmod and chown touch everything beneath the target. That can include files you didn’t mean to change, and it can open sensitive data to every user. GNU chmod documents recursive traversal, and behavior around special cases can vary by system and utility version. If a recursive change is truly needed, inspect a narrow sample first, understand the directory layout, and change only what the access requirement calls for. Avoid changing ownership of broad system paths.
Treat every command in this article as an illustration. Confirm the target path and the intended audience before you apply it.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesCommon misconceptions
- “Everyone in the file’s group can access it.” The process must actually carry that group ID, the group bits must grant the access, and ACLs may refine the effective rights.
- “Execute always means run.” On directories it means search.
- “chmod changes the owner.” It changes mode bits only;
chownchanges ownership. - “umask explains all new-file permissions.” A parent default ACL replaces that rule.
Quick command reference
| Command | Purpose |
|---|---|
id |
Current user and group IDs, including supplementary groups |
groups |
Group membership in readable form |
ls -l path |
Owner, group and basic mode |
stat path |
Metadata and numeric mode |
getfacl path |
ACL entries and mask |
chmod |
Change mode bits |
chown |
Change owner and/or group |
umask |
Show or set the creation mask |
These behaviors follow the Linux man-pages (credentials, umask(2), ACLs, the chmod system call) and the GNU coreutils manuals for chmod and chown. Details can differ with distribution, utility version, filesystem and security policy.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
