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.