Linux file permissions control who can read a file, change its contents or run it as a program. Ownership determines which user and group those permissions apply to. Together, they explain why a document opens normally, a shared folder refuses new files, or an application reports “Permission denied” despite working yesterday.
The useful habit is to separate three questions: who owns the object, which permissions apply to the process accessing it, and whether its parent directories allow access. Changing everything to 777 skips those questions. It also gives every local user write access, which is rarely the repair you intended.
How Linux Ownership and Permission Classes Work
On a Linux filesystem that supports Unix ownership, each file and directory has one owner and one owning group. Its ordinary permissions are divided into three classes: owner, group and others.
The owner permissions apply when the accessing process runs as the file’s owner. Otherwise, the group permissions apply if the process belongs to the file’s group, including through supplementary group membership. If neither matches, the others permissions apply. This describes the basic model without extended access control lists or privileged overrides.
These classes are not added together. Suppose Alex owns a file whose owner permissions deny writing but whose group permissions allow it. Alex does not gain group write permission by also belonging to that group: the owner class already matched.
“Others” means accounts that match neither the owner nor the owning group. It does not automatically mean visitors on the internet. A network service accesses local files through its own process identity, then exposes whatever its application configuration allows.
Linux stores ownership using numeric user IDs and group IDs, usually displayed as account names. The name is a readable label; the numeric identity is what matters. That distinction becomes useful when files move between systems whose account names look identical but have different IDs.
Reading a Linux Permission String
A long directory listing from ls shows permissions alongside the owner, group and other file details. The stat utility provides another view of an individual object’s metadata. Our guide to essential Linux terminal commands covers the broader inspection workflow.
Consider the permission string -rw-r—–, attached to a file owned by Alex with the group editors.
The first character identifies the object type. A dash means a regular file, d means a directory, and l means a symbolic link. The next nine characters form three groups: rw- for the owner, r-- for the group, and --- for others.
Alex can read and modify this file. Members of editors can read it. Other ordinary users receive no access through these mode bits. A dash inside a permission triplet means that permission is absent; it is not an extra restriction applied independently.
A directory shown as drwxr-x— has owner permissions of rwx, group permissions of r-x, and no permissions for others. The letters look familiar, but their effect changes because the object is a directory.
What Read, Write and Execute Actually Allow
The same three permission bits govern files and directories, but they protect different operations. The GNU Coreutils description of file mode bits distinguishes access to file contents from access to directory entries.
| Permission | Regular file | Directory |
|---|---|---|
r — read |
Read the file’s contents. | List the names stored in the directory. |
w — write |
Modify or truncate the file’s contents. | Create, remove or rename directory entries, normally requiring execute permission too. |
x — execute |
Attempt to run the file directly as a program. | Search or traverse the directory to access named entries. |
Directory Execute Permission Is Traversal Permission
A directory is not an application, so execute permission does not “run” it. It allows a process to pass through the directory and look up entries by name.
Read permission without execute permission can let someone list names while preventing access to the entries themselves. Execute permission without read permission can allow access to a known filename without allowing a directory listing. The target file still needs its own appropriate permissions.
Every directory along a path matters. A readable document inside /home/alex/private/ remains inaccessible to another user if that user cannot traverse private. Opening up the document alone does not remove the blockage. The relationship between paths and directories is covered in our Linux filesystem and directory structure guide.
Deleting a File Is Usually a Directory Operation
A file’s write bit controls changes to its contents, not whether its directory entry can be removed. Someone with write and execute permissions on the containing directory can generally delete the entry even when the file itself is read only. Sticky directories add another restriction, covered below.
This also explains some editor behavior. An editor may save by creating a replacement file and renaming it over the original. That workflow needs directory permissions, not just permission to write the original file.
For regular files, execute permission is permission to attempt direct execution, not proof that the file is a valid or trustworthy program. Removing execute permission is also not a reliable way to prevent a readable script being processed by an interpreter.
Numeric Permissions: What 644, 755 and 700 Mean
Numeric modes express the three permission classes as octal digits. Read has a value of 4, write has a value of 2, and execute has a value of 1. Add the required values within each class.
Read and write become 6. Read and execute become 5. All three become 7, and no permissions becomes 0. The digits are always ordered owner, group, others.
| Mode | Permission triplets | Typical purpose |
|---|---|---|
600 |
rw- --- --- |
A file only its owner should read or modify. |
640 |
rw- r-- --- |
A file its group may read but not modify. |
644 |
rw- r-- r-- |
A file other local users may read. |
700 |
rwx --- --- |
A private directory or owner-only executable. |
750 |
rwx r-x --- |
A directory its group may browse and traverse. |
755 |
rwx r-x r-x |
A directory or executable accessible to other users. |
770 |
rwx rwx --- |
A shared directory writable by its group. |
These are examples, not universal prescriptions. Mode 644 is unsuitable for a secret simply because it appears frequently in tutorials. Mode 755 does not belong on every document either: ordinary documents do not need execute permission.
A private key often calls for owner-only access, but authentication also depends on ownership and surrounding directories. Our guide to securing SSH with keys and access controls covers those requirements in context.
Changing Permissions with chmod
The chmod utility changes permission bits. Numeric modes describe the desired ordinary permissions across all three classes. Symbolic modes describe an adjustment or assignment for selected classes.
In symbolic notation, u selects the owner, g selects the group, o selects others, and a selects all three. The operator + adds permissions, - removes them, and = assigns the stated permissions to the selected class.
u+xadds execute permission for the owner.g-wremoves group write permission without changing group read or execute access.o=removes all ordinary permissions for others.u=rw,g=r,o=describes owner read/write, group read and no access for others.
For an owner-only document, select the file with chmod and use mode 600. For a script that already has suitable read permissions but lacks owner execute permission, the narrower symbolic adjustment is u+x.
Write access does not give someone permission to change a file’s mode. Normally, that requires ownership or appropriate administrative privileges. GNU’s handling of explicitly named symbolic links can also affect the target rather than the link itself; the GNU chmod reference documents these restrictions and link behavior.
Be Careful with Recursive Changes
The recursive option, -R, applies changes throughout a directory tree. That makes an incorrect target much more expensive. A tree may contain private files, executable programs, shared directories and application-managed data, all with different requirements.
Applying one numeric mode everywhere can remove directory traversal permissions or mark every document executable. Where appropriate, uppercase X in a symbolic mode adds execute permission to directories and to files that already have an execute bit. It avoids treating every ordinary file as a program.
Before a broad repair, record the existing ownership and permissions. A backup and recovery plan should preserve the metadata needed to restore access, not just the file contents.
Changing Ownership with chown and chgrp
Permissions answer “what access is allowed?” Ownership answers “whose permission class applies?” If a file belongs to the wrong account, making its permissions broader treats the symptom rather than the cause.
The chown utility changes the owner and can also change the owning group. Its owner-and-group argument uses a colon, such as alex:editors. The chgrp utility changes only the group.
On Linux, changing a file’s owner normally requires administrative privileges. An ordinary owner can generally change the file’s group to a group they belong to. Write permission alone does not authorize either operation.
A familiar case is a personal project containing files accidentally created by an administrative process. The useful repair may be restoring those files to the intended user, not granting everybody write access. Keep the correction confined to the affected project; system files should not become personal property.
Use our guide to Linux users, groups and sudo access for account membership and administrative access. After changing ownership, inspect permissions again rather than assuming every earlier setting remains appropriate.
How umask Sets Permissions for New Files
The umask is a process setting that removes permission bits when new objects are created. It does not grant permissions or repair existing files. Without a default ACL, the result depends on the permissions requested by the application with the masked bits removed.
Many applications request mode 666 for ordinary files and 777 for directories. With umask 022, those requests produce files with mode 644 and directories with mode 755. Umask 027 produces 640 and 750; umask 077 produces 600 and 700.
These results assume those starting requests. An application requesting a private 600 file does not gain group access from a permissive umask. The operation removes bits rather than performing ordinary decimal subtraction.
A parent directory’s default ACL changes the creation rules: Linux derives access from that ACL and the application’s requested mode instead of applying umask in the usual way. The Linux umask documentation covers that interaction.
Special Permissions: Setgid, Sticky Bit and Setuid
Three special bits sit alongside ordinary permissions. An extra leading octal digit represents them: 4 for setuid, 2 for setgid and 1 for the sticky bit.
On a directory, setgid makes newly created entries inherit its group, with newly created subdirectories also inheriting the setgid bit. It does not, by itself, grant group write access.
The sticky bit restricts removal and renaming in a directory to the entry’s owner, the directory owner or a suitably privileged process. A shared temporary directory commonly uses mode 1777. Other permissions still govern access to file contents.
On executable files, setuid and setgid can change the effective user or group identity used during execution, subject to execution restrictions. Treat these as security-sensitive settings, not ordinary permission repairs. The Linux inode documentation on special mode bits records their meanings.
Listings show these bits as s or t in execute positions. Uppercase S or T means the special bit is present while the corresponding execute bit is absent.
A Practical Shared Project Folder
Suppose Alex and Morgan need to edit the same project. A sensible design gives the project directory an owning group containing both users, rather than opening it to every account.
A directory mode of 2770 combines owner and group access with setgid inheritance, while denying access to others. Ordinary shared documents might use mode 660, allowing their owners and the project group to read and write them.
The remaining issue is new content. Setgid keeps the group consistent, but an application can still create a file without group write permission. For applications requesting the usual starting modes, umask 0007 produces 660 files and 770 directories. A default ACL offers another way to establish shared access rules.
Test creation, editing, renaming and deletion as both users. A folder that works only for its owner is not yet a shared workflow. Projects on a Linux development workstation may also involve background tools running under different accounts.
When Access Control Lists Are Useful
An access control list, or ACL, adds permissions for named users and groups beyond the single owning group. It can suit a project where the main team needs write access but one reviewer needs read access.
An access ACL governs the object itself. A directory’s default ACL supplies initial access rules for newly created children. The utilities getfacl and setfacl inspect and modify these rules.
The ACL mask caps permissions available through named user entries, the owning group entry and named group entries. An entry can show write permission while its effective access remains read only because of the mask.
With an extended ACL containing a mask, the group bits in a normal listing represent that mask rather than just the owning group’s entry. Changing those bits through chmod can therefore change effective ACL access. The Linux ACL documentation details this relationship.
Troubleshooting “Permission Denied” Without Opening Everything
Start with the operation that failed. Reading an existing document, replacing it, creating a new file and launching a program require different checks. Then inspect the account performing the operation, not just the account logged into the desktop.
- Confirm the process identity. Inspect the relevant user and group memberships. A background service may not share your interactive account’s access.
- Check ownership and the matching permission class. Decide whether the process matches owner, group or others before changing any bits.
- Inspect the complete path. Check directory traversal along the path and parent-directory write access for creation, deletion or replacement.
- Inspect ACLs and storage restrictions. An ACL mask can reduce effective access. A read only filesystem prevents writes regardless of ordinary write bits, and execution restrictions can block direct program launches.
- Check application confinement. Security policy or an application sandbox may deny access that ordinary file permissions allow.
For a service, its configured identity belongs in the investigation. Our guide to managing services with systemd covers the service configuration side.
AppArmor adds application policies alongside ordinary Unix permissions. A file can pass its owner, group and mode checks while the application’s profile still denies access. The Ubuntu AppArmor documentation describes these checks and the denial records they produce.
Use the application’s error message and relevant logs to identify the blocked operation. Our journalctl troubleshooting guide covers inspecting service logs without guessing which permission to change.
Make the smallest correction that matches the intended access: fix an owner, adjust a group, restore directory traversal or grant a named account access. Then repeat the failed operation under the same identity. A permission repair is finished when the intended user can do the intended work, not when every account can do everything.