This article systematically explains the Linux permission model, why a file may be readable but not deletable, or visible but not accessible, and how to solve these issues with chmod, chown, umask, and Sticky Bit. It is ideal for beginner troubleshooting in server operations and development. Keywords: Linux permissions, chmod, umask.
The technical specification snapshot
| Parameter | Value |
|---|---|
| Primary language | Shell / Bash |
| Runtime environment | Linux / Unix-like |
| Core standard | POSIX file permission model |
| GitHub stars | Not provided in the original |
| Core dependencies | chmod, chown, chgrp, umask, sudo, ls |
AI Visual Insight: This image introduces the Linux permissions topic and typically represents a terminal or a permission structure diagram. It highlights the access control relationship among files, directories, and users, serving as a visual entry point for understanding owner/group/other and rwx combinations.
Linux permissions are fundamentally a multi-user isolation mechanism
Linux permissions are not just a syntax exercise. They are isolation rules for a multi-user system. Without permission controls, any user on a shared server could accidentally delete a project, overwrite scripts, or even damage system files.
The model has only three core goals: isolate users, protect the system, and make responsibility explicit. Whether you can operate on an object depends on who you are, who owns the object, and which permissions the object grants.
Start by looking at the permission string structure
ls -l
# Example output
# drwxr-xr-x 3 root root 4096 Jan 11 15:01 dir
# -rw-r--r-- 1 user user 0 Jan 11 15:02 file.txtThis output shows the file type, permission bits, owner, and group. It is the first place to check when troubleshooting permission issues.
Linux classifies access into three identities
Permission checks always revolve around three subjects: owner, group, and other. The system does not stack multiple identities for a user during evaluation. Once it matches one identity, it stops checking.
| Identity | Symbol | Meaning |
|---|---|---|
| owner | u | The file owner |
| group | g | A member of the file’s group |
| other | o | All other users |
The meaning of rwx differs between files and directories
# File permission example
-rwxr--r-- script.sh
# Directory permission example
drwxr-x--- project/For files, r means read content, w means modify content, and x means execute the program. For directories, r means list directory entries, w means add, remove, or rename directory entries, and x means enter the directory and traverse the path.
Directory permissions are where people most often get tripped up
Many accidental deletion incidents are not caused by overly permissive file settings, but by overly permissive directory settings. Deleting a file is fundamentally a modification to the directory entry, so whether you can delete a file is often determined by the directory’s w permission.
This explains a classic phenomenon: you are not the file owner, yet you can still delete it. The condition is that you have write permission on the parent directory and that no extra protection is in place.
Use a quick experiment to understand directory rwx
chmod 444 testdir # Read only, no execute permission
ls testdir # Can list names, but detailed access is limited
chmod 111 testdir # Execute only, no read permission
cd testdir # Can enter the directoryThis set of commands shows that x on a directory determines whether you can pass through the door, while r determines whether you can clearly see the list behind it.
chmod is the primary command for changing permissions
chmod has two common modes: symbolic mode is best for fine-grained changes, while octal mode is better for fast, consistent configuration. In real operations work, octal mode is usually more efficient and easier to script.
Symbolic mode is best for targeted changes
chmod u+x script.sh # Add execute permission for the owner
chmod g-w data.txt # Remove write permission from the group
chmod o=r readme.txt # Keep read permission only for others
chmod go-rwx secret.txt # Remove all permissions from group and othersThese commands are ideal when you want to change only one class of users or one specific permission bit without rewriting the entire permission set.
Octal mode is best for standardized configuration
chmod 755 deploy.sh # Full permissions for owner, read and execute for group and others
chmod 644 app.conf # Read and write for owner, read only for everyone else
chmod 700 ~/.ssh # Accessible only to the owner
chmod 600 id_rsa # Typical permission for a private key fileThese commands represent the most common production permission templates and make team conventions and audits easier.
File ownership determines who is allowed to manage permissions
Permission bits are not the whole story. Ownership matters just as much. The owner determines who can directly manage the file, while the group defines the collaboration scope. Many cases of “why chmod does not work” are really cases where the object is not under your control.
chown and chgrp handle ownership changes
chown user1 file.txt # Change the owner
chgrp developers file.txt # Change the group
chown user1:developers file.txt # Change owner and group at once
chown -R user1:developers project/These commands are commonly used to fix incorrect ownership in deployment directories, especially in CI/CD, shared directory, and container mount scenarios.
umask determines why new files have fewer permissions by default
New files do not start from 777. The theoretical base is usually 666 for regular files and 777 for directories, and then umask removes the bits they should not have.
That is why, on a typical system with umask set to 022, new files become 644 and new directories become 755. This also explains why text files do not have execute permission by default.
View and change umask
umask # Show the current mask
umask 022 # Standard shared environment
umask 002 # Same-group collaboration environment
umask 077 # Strong-security private environmentThese commands determine the default exposure surface of new files. On a multi-user server, 077 is often safer than 022.
Sticky Bit is the key safeguard against accidental deletion in shared directories
When a directory is set to 777, anyone can create and delete directory entries. That is convenient for shared directories, but it is also the most dangerous setup. The purpose of Sticky Bit is to add a constraint between “shared access” and “protection against accidental deletion.”
Once enabled, files in that directory can usually be deleted only by root, the directory owner, or the file owner. /tmp is the classic example of this mechanism.
Enable Sticky Bit for a shared directory
chmod 1777 /shared # Shared and writable, while preventing cross-user deletion
ls -ld /shared # A trailing t indicates Sticky Bit is active
chmod -t /shared # Remove Sticky BitThese commands are suitable for team temporary directories, upload directories, and public cache directories. They are one of the most important security baselines for shared environments.
A quick reference table can handle most daily troubleshooting
| Scenario | Recommended command | Purpose |
|---|---|---|
| Standard configuration file | chmod 644 file |
Prevent modification by non-owners |
| Private key file | chmod 600 id_rsa |
Meet SSH security requirements |
| Private directory | chmod 700 dir |
Allow access only to the owner |
| Shared directory | chmod 1777 shared |
Writable, but protected from cross-user deletion |
| Fix ownership | chown -R user:group dir |
Resolve permission ownership mismatches |
| Strong default security | umask 077 |
Make new files private by default |
Check these three dimensions first when troubleshooting
ls -l target
ls -ld parent_dir
idFirst inspect the target object’s permissions, then the parent directory’s permissions, and finally confirm the current user identity. This sequence usually helps you locate 80% of permission problems.
FAQ structured answers
Why can root still access a file after chmod 000 file.txt?
root has system-level administrative privileges and is usually not fully restricted by ordinary permission bits. Permission bits mainly constrain regular users, not the superuser.
Why can I see filenames when a directory is r--, but not view detailed information?
Because r allows you to read the directory entry list, but without x you cannot traverse the directory to access inode metadata. As a result, ls -l may show question marks or return a permission error.
Why is 1777 recommended for shared directories instead of 777?
777 solves only the “everyone can write” problem, but it does not prevent users from deleting each other’s files. 1777 preserves shared write access while using Sticky Bit to prevent ordinary users from deleting files they do not own.
Core summary: This article reconstructs the core Linux permission model, covering owner/group/other, rwx, chmod, chown, umask, and Sticky Bit, helping developers quickly diagnose common issues such as unreadable files, deletable directories, and accidental deletion in shared directories.