Linux Permissions Complete Guide: chmod, chown, octal, and ACLs

Linux file permissions form the bedrock of system security, server administration, and application deployment. Whether you are a seasoned DevOps engineer grappling with complex containerized environments, a backend developer fighting with server deployments, or a Linux enthusiast exploring the terminal, you have undoubtedly encountered the infamous "Permission denied" error. It is a universal rite of passage in the Linux world. But why do we have this complex system of file permissions, octal permissions, ugoa, setuid, setgid, and sticky bits?

The answer lies in the fundamental Unix philosophy: Everything is a file. Because hardware devices, network sockets, system configurations, and user data are all represented as files, securing the operating system intrinsically means securing file access. In a multi-user environment—which Linux is designed to be from the ground up—you need a rigorous mathematical model to dictate exactly who can read, modify, or execute these files. This guide will serve as your ultimate, comprehensive pillar resource. By the time you finish reading, you will understand the nuances of chmod, chown, Access Control Lists (ACLs), and advanced troubleshooting techniques for modern server environments.

1. The Foundation of Linux File Permissions: The UGO Model

To understand linux permissions, you first must understand how Linux categorizes the entities that interact with files. Linux does not assign permissions indiscriminately to specific user accounts by default (though ACLs, which we will discuss later, do allow this). Instead, it uses a highly efficient, rigid tripartite model known as UGO (User, Group, Others). Every single file and directory on a Linux filesystem is associated with exactly one owner and one group.

The Three Categories (UGOA)

• User (u) - The Owner: The specific user account that owns the file. By default, the user who creates a file becomes its owner. The owner typically has the most control over the file and can change its permissions.
• Group (g): A collection of users. Rather than adding permissions for users Alice, Bob, and Charlie individually, a system administrator can create a group called developers, assign those users to the group, and give the group access to the file.
• Others (o) - The World: This category encompasses everyone else. Any user account on the system that is not the owner and is not part of the file's group falls into the "Others" category. This is often referred to as "world" permissions.
• All (a): This is a shortcut used in symbolic notation that simply targets User, Group, and Others simultaneously.

You can view this relationship by running the "long listing" command, ls -l. Let us break down a typical output line:

$ ls -l /var/www/html/index.html
-rw-r--r-- 1 www-data devteam 1045 Jun 29 10:00 /var/www/html/index.html

Let us meticulously dissect what each part of this line means:

• -rw-r--r--: The permission string. This ten-character string is the heart of Linux security. (We will decode this deeply in the next section).
• 1: The number of hard links to the file. (For directories, this is the number of subdirectories + 2).
• www-data: The User (Owner) of the file.
• devteam: The Group that owns the file.
• 1045: The size of the file in bytes.
• Jun 29 10:00: The last modification timestamp.
• /var/www/html/index.html: The file name and path.

This breakdown demonstrates how intrinsically tied file permissions and ownership are. The permissions dictate what can be done, while the ownership dictates who can do it. You cannot fully master chmod without mastering chown.

2. Read, Write, and Execute (rwx): Files vs. Directories

Now we must decode the first 10 characters of the ls -l output (e.g., -rw-r--r--). This string is divided into four distinct blocks. The very first character dictates the File Type, and the next nine characters represent the permissions for User, Group, and Others, in blocks of three.

The File Type Indicator

The first character tells you what kind of file you are dealing with:

• - : Regular file (text, image, script, binary, etc.)
• d : Directory
• l : Symbolic link (a pointer to another file)
• c : Character device file (like a terminal)
• b : Block device file (like a hard drive, e.g., /dev/sda)
• s : Socket (used for inter-process communication)
• p : Named pipe (FIFO)

The Meaning of Read (r), Write (w), and Execute (x)

The remaining nine characters are broken into three sets of rwx. The first triplet is for the User (Owner), the second is for the Group, and the third is for Others. If a permission is granted, you see the letter. If it is denied, you see a hyphen -.

However, there is a massive conceptual trap here that catches even mid-level developers: rwx means entirely different things depending on whether the target is a file or a directory.

For Files:

• Read (r): The ability to open and read the contents of the file. Commands like cat, less, or opening it in a text editor require this.
• Write (w): The ability to modify the contents of the file. Note: This does not give you the right to delete or rename the file. Deletion is a property of the directory holding the file, not the file itself!
• Execute (x): The ability to run the file as a program or script. A bash script, Python script, or compiled binary must have this bit set to run directly (e.g., ./script.sh). If it is a script, it also needs Read permission so the interpreter can read the commands.

For Directories:

• Read (r): The ability to list the contents of the directory (i.e., running ls to see the names of files inside). However, without Execute permission, you cannot access the metadata (inodes) of those files.
• Write (w): The ability to add, delete, or rename files within the directory. This is critical: if you have write permission on a directory, you can delete any file inside it, regardless of whether you own that file or have write permission to it! (This is why the Sticky Bit exists, which we will cover).
• Execute (x): Often called the "traverse" or "search" bit. This allows you to cd into the directory and access known files inside it. Without execute permission on a directory, you cannot access anything inside it, even if you know the exact file path and have read access to the file.

3. Octal Permissions vs. Symbolic Permissions

Linux provides two ways to interpret and modify permissions: Symbolic notation (using letters like u+x) and Octal notation (using numbers like 755). Mastery of both is required. Symbolic is excellent for making surgical, relative changes, while octal is perfect for explicitly defining the exact desired state in automation, scripts, and infrastructure as code.

The Math Behind Octal Permissions

Octal permissions are not arbitrary numbers; they are a direct representation of binary (Base-2) mathematics. Each permission type is represented by a bit (1 for on, 0 for off).

• Read (r): Binary 100, which equals 4 in decimal.
• Write (w): Binary 010, which equals 2 in decimal.
• Execute (x): Binary 001, which equals 1 in decimal.

To combine permissions, you simply add the numbers together:

• 4 + 2 + 1 = 7 (Read + Write + Execute)
• 4 + 2 = 6 (Read + Write)
• 4 + 1 = 5 (Read + Execute)
• 4 (Read only)
• 0 (No access)

Because we have three classes (User, Group, Others), we string three octal digits together.

Example Breakdown of 755:

• First digit (7): User (Owner). 4(r) + 2(w) + 1(x) = 7. The owner can read, write, and execute.
• Second digit (5): Group. 4(r) + 0(w) + 1(x) = 5. The group can read and execute.
• Third digit (5): Others. 4(r) + 0(w) + 1(x) = 5. Others can read and execute.

If you find this math tedious, remember that you can always use our Chmod Calculator to visually construct these octal values without making costly arithmetic mistakes on production servers.

Symbolic Permissions (ugoa, +, -, =)

Symbolic notation is highly human-readable. It uses the UGOA classes and mathematical operators to change permissions relative to their current state.

• Classes: u (user), g (group), o (others), a (all).
• Operators: + (add), - (remove), = (set exactly).
• Permissions: r (read), w (write), x (execute).

Examples of Symbolic Usage:

# Add execute permission for the owner
chmod u+x deploy.sh

# Remove write access for others
chmod o-w config.json

# Add read access for group and others simultaneously
chmod go+r public_html

# Set exact permissions for all (read and execute only)
chmod a=rx backup.tar.gz

4. Deep Dive into the chmod Command

The chmod (change mode) command is your primary tool for applying these octal and symbolic permissions to files and directories. Let us examine standard conventions and advanced flags.

Common Octal Patterns

There are a few octal patterns you will see constantly in the industry:

• 644 (-rw-r--r--): The standard permission for most files. The owner can edit the file, but everyone else can only read it. Ideal for HTML files, configurations, and documents.
• 755 (-rwxr-xr-x): The standard permission for executable scripts and directories. The owner has full control, while others can traverse the directory or execute the script.
• 700 (-rwx------): Extremely restrictive. Only the owner can access the file or directory. This is mandatory for the ~/.ssh directory to ensure private keys are secure.
• 600 (-rw-------): Restrictive file permission. Mandatory for SSH private keys (e.g., id_rsa) and files containing passwords or database credentials.
• 777 (-rwxrwxrwx): The Danger Zone. Everyone on the system can do anything to the file. It is often used as a desperate, lazy fix for "Permission denied" errors. Never use 777 in production. It represents a catastrophic security vulnerability, allowing any process (including exploited web servers) to modify or run malicious code.

Recursive Changes and Advanced Flags

When dealing with large folder structures, modifying files one by one is impossible. You need recursive changes.

# Recursively change a directory and EVERYTHING inside it to 755
chmod -R 755 /var/www/html/

The Problem with Recursive Octal Changes:
Using chmod -R 755 is a common mistake. It makes every directory traversable (good), but it also makes every text file and image executable (bad). You usually want directories to be 755 and files to be 644. To achieve this correctly, you must use the find command combined with chmod.

# Find all directories and set them to 755
find /var/www/html -type d -exec chmod 755 {} +

# Find all regular files and set them to 644
find /var/www/html -type f -exec chmod 644 {} +

Note how we had to escape the brackets in Astro syntax. This powerful command chain guarantees that your web server has exactly the right permissions without over-exposing flat files as executables.

5. Mastering chown and chgrp: Controlling Ownership

As discussed, permissions are useless if the ownership is wrong. If a file is owned by root, giving it 700 permissions means your non-root web server (e.g., www-data) cannot read it. You must change the owner using chown.

The Rules of chown

There is a strict security rule regarding ownership: Only the root user (or a user with sudo privileges) can arbitrarily change the ownership of a file to another user. You cannot give away your files to someone else without administrative privileges, as this could be exploited to bypass disk quotas.

Syntax Variations

The chown command allows you to change the user and the group simultaneously using a colon :.

# Change the owner to 'alice' (group remains unchanged)
sudo chown alice data.csv

# Change both the owner and the group to 'www-data'
sudo chown www-data:www-data /var/www/html/index.html

# Change only the group to 'devteam' (notice the leading colon)
sudo chown :devteam shared_folder/

# Recursively change owner and group for a directory tree
sudo chown -R www-data:www-data /var/www/html/

The chgrp Command

While chown :groupname works perfectly, Linux also provides the chgrp command specifically for changing the group ownership. Unlike chown, a normal user can use chgrp to change the group of a file they own, provided they are a member of the new target group.

chgrp devteam project_specs.md

For complex ownership setups, especially when preparing deployment scripts, utilize our Chown Generator to ensure syntactical correctness and avoid locking yourself out of critical system files.

6. Special Permissions: SUID, SGID, and the Sticky Bit

The standard rwx model is sufficient for 95% of use cases. But what happens when standard permissions conflict with system functionality? This is where the fourth octal bit (the special permissions bit) comes into play. It sits in front of the standard three digits (e.g., 4755).

SUID (Set User ID) - Octal 4000

When an executable has the SUID bit set, it executes with the privileges of the file owner, not the user executing it.

Why is this necessary? Consider the passwd command. To change your password, the passwd binary must update the /etc/shadow file. However, /etc/shadow is strictly readable and writable only by root. A normal user running passwd would normally receive a "Permission denied" error. By setting the SUID bit on the /usr/bin/passwd binary (which is owned by root), the program temporarily elevates the user's privileges to root for the duration of the execution, allowing it to modify the shadow file securely.

Warning: SUID on a poorly written binary is a massive security hole, allowing local privilege escalation. SUID should never be applied to scripts (like Bash or Python), and many modern kernels explicitly ignore SUID on scripts for this reason.

SGID (Set Group ID) - Octal 2000

SGID operates differently depending on whether it is applied to a file or a directory.

• On an executable file: Similar to SUID, the program runs with the privileges of the file's group, rather than the executing user's group.
• On a directory (The Collaboration Enabler): This is incredibly useful. When SGID is set on a directory, any new files or subdirectories created within it automatically inherit the group ownership of the parent directory, rather than the primary group of the user who created it. This is essential for shared team folders where multiple developers need group write access to files created by others.

Applying SGID to a shared directory:

# Set the group to devteam
sudo chown :devteam /var/shared_projects

# Add SGID via symbolic notation (g+s)
sudo chmod g+s /var/shared_projects

# Or via octal notation (2775 = 2000 + 775)
sudo chmod 2775 /var/shared_projects

The Sticky Bit - Octal 1000

Recall that write permission on a directory allows a user to delete any file inside it. What happens in a directory like /tmp, where every user on the system needs write access to create their own temporary files? Without protection, User A could delete User B's temporary files.

The Sticky Bit solves this. When applied to a directory, the sticky bit dictates that a file within that directory can only be deleted or renamed by the file's owner, the directory's owner, or the root user.

Applying the Sticky Bit:

# Symbolic notation (+t)
sudo chmod +t /tmp/shared_dump

# Octal notation (1777 = 1000 + 777)
sudo chmod 1777 /tmp/shared_dump

In the ls -l output, SUID appears as an s in the user execute position (rws------), SGID as an s in the group execute position (rwxrws---), and the Sticky Bit as a t in the others execute position (rwxrwxrwt).

7. Default Permissions and Umask

When you create a new file via touch file.txt, how does Linux know what permissions to assign it? It doesn't ask you. It calculates them using a system called umask (user file-creation mode mask).

The system starts with a base (or maximum) permission level:

• For directories: 0777 (Read, Write, Execute for all)
• For files: 0666 (Read, Write for all. Executable bits are never set automatically for safety).

The umask is a value subtracted (specifically, logically masked via bitwise NOT AND) from this base permission to determine the final permissions. A common default umask on Linux distributions is 0022.

Calculating new file permissions with umask 0022:

• Base Directory: 0777 - 0022 = 0755 (rwxr-xr-x)
• Base File: 0666 - 0022 = 0644 (rw-r--r--)

If you want tighter security by default (e.g., you don't want 'Others' to be able to read new files), you can change your umask to 0077.

• Base Directory: 0777 - 0077 = 0700 (rwx------)
• Base File: 0666 - 0077 = 0600 (rw-------)

You can temporarily set your umask by typing umask 0077 in the terminal. To make it persistent, add it to your ~/.bashrc or ~/.profile.

8. Modern Access Control Lists (ACLs)

The traditional UGO model is elegant, but it has severe limitations. What if you want to grant read access to User A, write access to User B, and execute access to Group C, all on the same file? The UGO model only gives you one owner slot and one group slot. You simply cannot fulfill this requirement using standard chmod and chown.

Enter POSIX Access Control Lists (ACLs). ACLs provide a fine-grained permissions mechanism that operates seamlessly on top of standard Linux permissions. They allow you to define multiple explicit owners and groups per file.

To use ACLs, the filesystem must be mounted with ACL support (which is default on modern ext4, xfs, and btrfs filesystems), and you need the acl package installed (which provides getfacl and setfacl).

Using setfacl and getfacl

Let us grant the specific user alice read and write access to a file, without making her the owner.

# Syntax: setfacl -m u:username:permissions filename
setfacl -m u:alice:rw project_secrets.txt

If we now run ls -l project_secrets.txt, we will notice a small change:

-rw-rw-r--+ 1 bob devteam 1045 Jun 29 10:00 project_secrets.txt

Notice the + symbol at the end of the permission string. This indicates that an ACL is present. To view the exact ACL rules, we use getfacl:

$ getfacl project_secrets.txt
# file: project_secrets.txt
# owner: bob
# group: devteam
user::rw-
user:alice:rw-
group::r--
mask::rw-
other::r--

ACLs can also define default inheritance rules for directories using the -d flag, ensuring all future files inherit exact, complex permission matrices automatically. This is invaluable in corporate file servers (like Samba shares on Linux).

9. Real-World Scenarios & The "Permission Denied" Nightmares

Theory is great, but permissions usually rear their head during production outages. Let us look at the most common scenarios where permissions break systems.

Scenario A: Web Server 403 Forbidden Errors

You upload a new PHP or HTML site, and the browser returns a 403 Forbidden. This means the web server (Nginx or Apache) does not have permission to read the files. Web servers typically run under a restricted user account, such as www-data, nginx, or apache. If you uploaded the files as root, they are owned by root, and if the "Others" read bit is disabled (e.g., 640), Nginx is locked out.

The Fix: Change the ownership to the web server user, and ensure standard 755/644 permissions.

sudo chown -R www-data:www-data /var/www/mywebsite
find /var/www/mywebsite -type d -exec chmod 755 {} +
find /var/www/mywebsite -type f -exec chmod 644 {} +

Scenario B: SSH "Bad Permissions" Error

When trying to SSH into a server using a private key, SSH abruptly disconnects with: WARNING: UNPROTECTED PRIVATE KEY FILE!

The SSH client demands that your private key (e.g., id_rsa, id_ed25519) is kept secret. If the permissions are 644 (readable by others), SSH refuses to use it.

The Fix: Strip all group and other permissions from the private key.

chmod 600 ~/.ssh/id_ed25519

Additionally, your ~/.ssh directory itself must be 700. If your home directory or .ssh directory allows group write access, SSH servers (sshd) will refuse public key authentication due to StrictModes settings.

Scenario C: Docker Volume UID/GID Mismatches

When binding a host directory to a Docker container (e.g., -v ./data:/app/data), the container writes files as its internal user. If the container runs as root (UID 0), the files on your host machine suddenly become owned by root, locking your host user out. If the container runs as a non-root user (e.g., node user with UID 1000), but your host directory is owned by root, the container crashes with "Permission Denied" trying to write to the volume.

This happens because Linux permissions are based on numeric UIDs (User IDs), not usernames. The name "node" in the container maps to UID 1000. If your host user is UID 1001, Linux sees two completely different owners.

The Fix: You must align the UIDs. This can be done by changing the owner of the host directory to match the container's UID. For a deep dive into resolving this, use our Docker Volume Permissions Helper which provides step-by-step resolution paths for complex container environments.

10. Advanced Troubleshooting Techniques

When permissions seem correct but access is still denied, standard ls -l is no longer enough. You must look deeper into the Linux security stack.

Using namei to debug the path

Remember that to read a file, you need execute access to every single parent directory in the path. If /var/www/html/site/index.html has 777 permissions, but the /var/www directory is 700 and owned by root, the web server will still fail! The kernel blocks traversal at /var/www.

The namei command helps trace permissions down the entire tree.

$ namei -mo /var/www/html/site/index.html
f: /var/www/html/site/index.html
 drwxr-xr-x root     root     /
 drwxr-xr-x root     root     var
 drwx------ root     root     www   <-- HERE IS THE CULPRIT!
 drwxr-xr-x www-data www-data html
 drwxr-xr-x www-data www-data site
 -rw-r--r-- www-data www-data index.html

SELinux and AppArmor

If ls -l, getfacl, and namei all show correct permissions, you are likely hitting Mandatory Access Control (MAC) systems like SELinux (common on RHEL/CentOS) or AppArmor (common on Ubuntu).

If you see a dot at the end of the permission string (e.g., -rw-r--r--.), SELinux is active. SELinux uses security contexts (labels) independent of UGO. To view SELinux contexts, use ls -Z. If a web server tries to access a file labeled user_home_t instead of httpd_sys_content_t, SELinux will block it immediately, and log the denial in /var/log/audit/audit.log.

Conclusion

Mastering Linux permissions is a journey from understanding the simple triplet of Read, Write, and Execute, all the way down to understanding octal math, Access Control Lists, and Mandatory Access Control labels. While the system can feel punitive with its cryptic "Permission denied" errors, it is this very rigor that makes Linux the most secure and ubiquitous server operating system in the world.

Keep this guide handy, leverage our online calculators when constructing complex octal values, and always remember to check the parent directories when a file stubbornly refuses to be read.

---

Frequently Asked Questions (FAQ)