Linux file permissions are one of the first concepts every Linux user and system administrator needs to master. Every sysadmin has been burned by a permissions mistake at least once. Uploaded a script that won’t run. Moved a file you couldn’t overwrite. Set up a deployment hook that silently failed because the user running it didn’t have write access to the log directory. These aren’t exotic edge cases, they’re the daily friction of working on a Linux system.
Linux file permissions are the gatekeepers of everything that runs on your server. Get them right, and your applications work smoothly, your users can access what they need, and your server stays reasonably secure. Get them wrong, and you’re either locked out of your own files or handing out access like candy.
This guide cuts through the noise. You’ll learn exactly how Linux permission bits work, what each one actually does when you’re logged in, how to read the cryptic output of ls -l, and how to change permissions the right way using both symbolic and numeric chmod. Everything here is written from the perspective of someone who’s spent real hours on actual servers, not just quoting man pages.
TL;DR
- Linux has three permission types: Read (r), Write (w), and Execute (x)
- Permissions apply to three categories of users: Owner (u), Group (g), and Others (o)
- The
ls -lcommand shows permissions in a 10-character string like-rw-r--r-- - Use chmod to change permissions, symbolic mode (u+x) or numeric mode (755)
- Use chown and chgrp to change ownership
- Common pitfalls: execute bit on directories, wrong group ownership, restrictive umask in production
Why Linux Permissions Matter More Than You Think
On a single-user laptop, permissions feel academic. On a server running multiple services, serving web traffic, and handling multiple users? Permissions are load-bearing infrastructure.
When a web server like Nginx runs, it typically operates under its own user, www-data on Ubuntu. The user account must have read permissions for the web root directory in order to serve website files. Your deployment script, running as a deploy user, needs write access to certain directories and execute access to deployment hooks. Your backup cron job, running as root, needs read access to everything but write access only to the backup volume.
Getting any one of these wrong breaks something silently. I’ve seen a Node.js app that kept crashing every night because a cron job was deleting its log directory, and the app didn’t have permission to recreate it. Permissions weren’t on anyone’s radar until the app started failing.
Understanding permissions also matters for security. The difference between chmod 777 and chmod 644 on a configuration file could be the difference between a server that’s yours and a server that’s been compromised. That’s not hyperbole, misconfigured permissions are a documented entry point for a wide range of attacks.
The Three Layers: Owner, Group, Others
Before you can understand what a permission means, you need to know who it’s being applied to. Linux splits access into three layers:
Owner (u)
The user who created the file. On a shared server, each user has their own home directory with files they own. The owner can change permissions on their own files, or take them away from themselves, which is a fun way to lock yourself out of something.
Group (g)
A group is a named collection of users. Instead of granting the same permission to five individual users one by one, you put them in a group and set permissions once. This is how most team-based server access works in practice.
Others (o)
Everyone else, users who aren’t the owner and aren’t in the owning group. “Others” permissions are your last line of defense. They’re what the world gets when someone with no account on your server tries to access your files.
The Three Permission Types Explained
Read (r or 4)
Read permission lets a user view a file’s contents. For a directory, read means listing the directory’s contents, you can see what files and subdirectories exist inside it, but you can’t enter it or access any of those files without additional permissions.
In practice, read on a directory is the permission that ls checks. Without it, ls returns a permission denied error even if you already know the directory exists.
Write (w or 2)
Write permission lets a user modify a file’s contents, add data, truncate it, rewrite it entirely. On a directory, write means you can create, delete, and rename files inside that directory.
Here’s the part that catches people: you need write permission on the directory itself to delete a file, not write permission on the file.
Execute (x or 1)
Execute permission is what makes a file run as a program or script. Without it, trying to run ./script.sh gives you a “permission denied” error, even if you own the file and have full read/write access.
For directories, execute has a different meaning: it allows access to the directory’s metadata and file contents. Without execute on a directory, you can’t cd into it or access any file inside it, even if you have read permission on those individual files.
Read Full Article: https://serveravatar.com/linux-file-permissions
Top comments (0)