Linux File Permissions Basics

Learn how Linux file and directory permissions work, how ownership selects access rules, and how to inspect or change permissions safely.

What Linux permissions protect

Linux permissions are a basic access-control mechanism for filesystem objects such as regular files, directories, symbolic links, and device files. They help protect personal data, coordinate shared resources, and prevent accidental or unauthorized changes to operating-system files.

When a user attempts an operation, Linux evaluates the user's identity, group membership, and the permission mode of the object. The result can allow or deny an operation such as reading a file, changing its contents, executing a program, or creating an entry in a directory.

Permission classes and ownership

A filesystem object has an owner, meaning the user account associated with it, and a group owner, meaning the group associated with it. The owner and group owner are separate properties: a file can belong to user alice and group developers.

Linux selects one basic class for a user in this order:

1. If the user owns the object, owner permissions apply.
2. Otherwise, if the user belongs to the object's group, group permissions apply.
3. Otherwise, others permissions apply.

This means owner permissions take precedence. A user who owns a file does not use the group or others triplet for that file, even if the owner is also a member of the assigned group.

Read, write, and execute bits

A permission bit is an individual binary access flag. The three basic bits are read, write, and execute. A permission mode is the complete set of access bits assigned to an object.

Permissions on regular files

Read permits opening and viewing file data. Write permits changing the data, although an application may choose how it writes and the filesystem may impose additional restrictions. Execute permits the kernel to run a file as a program when its format and interpreter are valid.

Execute permission does not automatically mean that a script's source can be read. For example, a user might be able to execute a script without having read permission for its contents, though the interpreter, script format, and operating-system behavior still matter. Do not treat execute as a reliable method for hiding source code.

Permissions on directories

Directory permissions describe operations on directory entries, not simply the contents of files stored inside.

• Read without execute: a user may be able to obtain names in the directory but may not be able to inspect metadata or access those names reliably through path traversal.
• Execute without read: a user cannot normally list names, but can traverse the directory when the exact child name is known and the child permissions allow the requested operation.
• Write plus execute: a user can generally create, remove, or rename entries. Read is not required to modify a directory's entry set.
• Read plus execute: a user can list names and traverse permitted paths, but cannot create, remove, or rename entries without directory write permission.

Deleting or renaming a file depends primarily on write and execute permission on the file's parent directory, not on write permission for the file itself. Thus, a user may delete another user's non-writable file in a writable shared directory.

Reading a permission display

Use a long listing to show the mode, owner, and group:

ls -l report.txt

-rw-r----- 1 alice developers 1842 Aug 18 09:30 report.txt

The first character identifies the object type. The next nine characters are three permission triplets:

- rw- r-- ---

• - at the beginning means a regular file.
• d means a directory.
• l means a symbolic link.
• c and b identify character and block device files at an introductory level.
• Within each triplet, the positions are read, write, and execute.
• A dash in a permission position means that bit is absent.

In -rw-r-----, alice is the owner and developers is the group owner. Alice can read and write. Matching members of developers can read. Others have no listed permissions. No class can execute this regular file.

Inspecting the directory itself

ls -l directory lists the directory's children. To inspect the directory object, use -d:

ls -ld directory

For detailed metadata, including a numeric mode, use stat:

stat report.txt
stat -c '%A %a %U %G %n' report.txt

The second command displays symbolic mode, octal mode, owner name, group name, and path. Formats can vary across operating systems, so consult the local stat manual if an option differs.

Numeric and symbolic permission modes

Each class receives a three-bit value: read is 4, write is 2, and execute is 1. Add the values within each triplet:

• 7 = 4 + 2 + 1 = read, write, execute
• 6 = 4 + 2 = read, write
• 5 = 4 + 1 = read, execute
• 4 = read only
• 0 = no permissions

An octal mode uses one digit for owner, group, and others. For example, 640 means owner rw-, group r--, and others ---.

Numeric notation sets the basic bits for all three classes at once. Symbolic mode uses letters and operators, making a targeted change easier to review.

Changing permission bits with chmod

chmod modifies an object's access mode. Use a narrow symbolic change when you want to alter one class or one bit:

chmod u+x script.sh
chmod g+w shared-file
chmod o-r private-file
chmod u=rw,g=r,o= private-file

Use an octal mode when you intend to define all basic permission triplets:

chmod 600 private-file
chmod 700 private-directory
chmod 755 command-or-directory
chmod 775 project-directory

For a private notes file:

chmod 600 notes.txt
chmod 700 private-notes

For a script, add execute permission without adding unnecessary write permission:

chmod u+x backup.sh
chmod 700 backup.sh

Use 755 only when other users should be able to run the command and reading the file is acceptable. A shell script commonly needs read access for its interpreter, so its practical behavior should be tested rather than inferred from the execute bit alone.

Recursive changes

chmod -R applies a change throughout a directory tree. Recursive operations are powerful and easy to misuse. Applying chmod -R 755 project marks ordinary data files as executable. Applying a broad writable mode can expose sensitive files or allow unwanted changes.

When directories and regular files need different modes, target them separately:

find project-directory -type d -exec chmod 775 {} +
find project-directory -type f -exec chmod 664 {} +

Review the path, ownership, file types, and intended access before running any bulk command. Start with a small test directory when possible.

Changing ownership and group ownership

chown changes the owner and can also change the group. chgrp changes only the group:

chown user file
chown user:group file
chgrp group file

Changing the owner generally requires administrative privileges. A user may have limited ability to change a file's group to a group that the user belongs to, depending on the system and operation. Ownership changes should be deliberate because they affect which permission class applies.

Recursive ownership changes use -R:

chown -R projectuser:projectgroup project-directory

Use recursive ownership changes only when the entire tree is intended to have the same ownership. A mistaken path can change system files or unrelated user data. Inspect first:

ls -ld project-directory
find project-directory -maxdepth 2 -ls

Practical permission design

Least privilege means granting only the access needed for a task. Begin with the smallest useful access and add permissions intentionally.

• Private files commonly use 600; private directories commonly use 700.
• Publicly readable files commonly use 644.
• Commands and scripts that should be runnable by everyone may use 755 when public read access is acceptable.
• A project directory shared by a group may use 775, with the directory assigned to the project group.
• Group-collaborative files may use 664, provided unrelated users should have read access. Use a stricter others setting when they should be excluded.

To access /srv/project/report.txt, a user generally needs search permission on every directory in the path: /, /srv, and /srv/project. Granting permission on the file alone is not enough if a parent directory blocks traversal.

Shared directories and the sticky bit

A group- or world-writable directory allows users to create and remove entries. This can let one user remove another user's file because deletion is controlled primarily by the parent directory. The sticky bit is a special directory bit that restricts removal or renaming, usually to the entry owner, directory owner, or an administrator. Shared temporary directories commonly use this protection.

The setgid special bit on a directory can make newly created entries inherit the directory's group, which is useful for project collaboration. A typical advanced setup combines a project group, group-writable directory permissions, and setgid inheritance. Special bits are extensions to the basic nine permission positions.

Default permissions and umask

umask is a process setting that removes permissions from the defaults requested when new files and directories are created. It does not usually add permissions; it masks them out. Check the current setting with:

umask

Applications and system defaults determine the initial requested mode, and the umask then removes selected bits. Therefore, two users creating the same kind of file can receive different initial modes. Inspect the resulting object with ls -l or stat rather than assuming a mode.

Troubleshooting permission errors

Permission denied even though a file appears readable

1. Check the owner and group with ls -l path or stat path.
2. Determine whether the user is the owner, belongs to the assigned group, or falls into others. Remember the selection order.
3. Inspect every parent directory for execute or search permission.
4. Check for ACLs, mount options, or a security policy that adds a restriction.

A script exists but cannot be run directly

1. Inspect whether the relevant class has execute permission.
2. Confirm the interpreter directive and that the interpreter exists when the script uses one.
3. Check search permission on all containing directories.

A team member cannot edit or create shared content

1. Confirm the user's group membership.
2. Inspect the object's group owner.
3. For editing, check group write permission on the file.
4. For creating entries, check write and execute permission on the directory.
5. If group membership was recently changed, start a new login session or otherwise refresh the user's group context.

A user can delete another user's file

Inspect the parent directory. If it is writable and searchable by that user and lacks sticky-bit protection, the user may remove or rename entries regardless of the target file's own write bit.

A recursive change exposed or damaged access

Review affected file types and modes. Restore directories and regular files separately, audit ownership, and avoid applying one numeric mode indiscriminately to an entire tree.

chmod or chown reports “Operation not permitted”

Verify the effective identity and current ownership. Changing an owner normally requires administrative authority. Also check filesystem attributes, mount restrictions, or other filesystem-level controls.

Limits of basic permission bits

Owner, group, and others bits are important but are not the only access-control mechanism on Linux. Observed access can also be affected by:

• setuid: a special bit that can affect the effective user identity of an executable.
• setgid: a special bit that can affect executable group identity and group inheritance on directories.
• Sticky bit: a directory bit that restricts who can remove or rename entries.
• ACL: an access control list that provides permissions beyond the three traditional classes.
• Mandatory access control: systems such as SELinux or AppArmor can impose additional policy.
• Mount options: filesystem mount settings can constrain execution or other behavior.
• Privileged processes: administrative or specially privileged processes may not be constrained in exactly the same way as ordinary users.

For basic administration, first understand traditional mode bits and ownership. Advanced cases may require examining special permissions, ACLs, security policy, mount configuration, and symbolic-link behavior.

Permission checklist

1. Inspect with ls -l, ls -ld, or stat.
2. Identify the object type, owner, group owner, and three permission triplets.
3. Determine which class applies to the requesting user.
4. For directories, distinguish listing, traversal, and entry modification.
5. Check every parent directory for search permission.
6. Use the narrowest safe chmod, chown, or chgrp command.
7. Use extra caution with recursive operations.
8. If the mode looks correct, investigate umask, ACLs, special bits, mount options, and security policy.