Linux
Linux Files, Ownership, and Permissions Without the Guesswork
Linux permissions look cryptic until you stop reading them as one long string.
A line such as -rw-r----- is really a compact description of who can read, write, or execute a file.
Read a permission line
Start with ls -l.
ls -l report.txt
You might see:
-rw-r----- 1 alice developers 1842 Jul 10 09:20 report.txt
The first character describes the object type. A - is a regular file and d is a directory.
The next nine characters are three groups of permissions.
rw- r-- ---
The first group belongs to the owner, the second to the group, and the third to everyone else.
What read, write, and execute mean
For a regular file, r means reading its contents, w means changing them, and x means executing it as a program.
Directories are slightly different.
For a directory, r allows listing names, w allows creating or removing entries, and x allows traversing the directory.
That last point explains many confusing permission errors.
A user can have permission to read a file but still fail to reach it because one of its parent directories lacks execute permission.
Change permissions with chmod
The symbolic form is easy to start with.
chmod u+x backup.sh
Here u means the owner. You can also use g for group and o for others.
chmod g+r report.txt
chmod o-r report.txt
The numeric form is compact and common on servers.
chmod 640 report.txt
The values are based on read = 4, write = 2, and execute = 1.
So 640 means owner can read and write, group can read, and everyone else has no access.
Do not default to 777
A common response to a permission error is:
chmod -R 777 some-directory
It may make the error disappear, but it also gives everyone broad access.
On a production server, that can turn a small configuration problem into a security problem.
Use the smallest permission set that matches the application.
Ownership matters too
Permissions are evaluated together with ownership.
Check the current owner with:
ls -l report.txt
Change ownership with chown when you have a legitimate administrative reason.
sudo chown alice:developers report.txt
For a directory tree, recursive ownership changes are powerful and therefore worth double-checking.
sudo chown -R app:app /srv/app
Before doing this, verify the path with pwd and ls.
Groups are often better than individual permissions
Suppose three administrators need access to /srv/reports.
Creating a shared group is usually cleaner than changing permissions for each user independently.
sudo groupadd reports
sudo usermod -aG reports alice
sudo usermod -aG reports bob
The -aG combination is important because it adds a supplementary group without replacing the user's existing group memberships.
A new login session may be required before the membership is visible.
Check it with:
groups alice
Directory permissions need care
A shared directory might use group write access.
sudo chown -R root:reports /srv/reports
sudo chmod -R 2770 /srv/reports
The leading 2 sets the setgid bit on directories, helping new files inherit the directory's group.
This is useful for collaborative application data, but it should be used intentionally.
Understand umask
The umask controls which permission bits are removed when new files and directories are created.
Check it with:
umask
A value such as 0022 commonly results in files that are not writable by everyone.
You can inspect the effective defaults by creating a temporary file.
touch /tmp/permission-test
ls -l /tmp/permission-test
rm /tmp/permission-test
Troubleshoot permission denied
When you see Permission denied, do not immediately change permissions.
First identify the path.
namei -l /srv/app/config/settings.conf
namei can show permissions on each directory component.
Then inspect the process user if a service is involved.
systemctl status myapp
A service may run as a dedicated account rather than your interactive user.
Special bits exist for a reason
Linux also has setuid, setgid, and the sticky bit.
The sticky bit is familiar on /tmp.
ls -ld /tmp
It prevents users from casually deleting files owned by other users in a shared writable directory.
Do not enable special bits simply because you saw them in an example. Understand the security consequence first.
A practical rule
Think of permissions as a policy: who should access this resource, what should they do with it, and what should everyone else be allowed to do?
Once you answer those questions, chmod, chown, and groups become implementation tools instead of commands you try at random.