Lesson  in  Linux for SRE / DevOps - Beginner Level

Permissions: The #1 On-Call Page

on Linux
rwx, chmod/chown, and why "permission denied" is behind most 3am pages - diagnosing and fixing a service that won't start.

More on-call pages come down to "permission denied" than almost any other single cause. The good news: it's the most mechanical thing in this entire course. There is no guessing, only reading three characters at a time.

Reading rwx

ls -l /opt/reporting-svc/run.sh
-rw-r--r-- 1 root root 92 Sep 22 03:44 /opt/reporting-svc/run.sh

That first block, -rw-r--r--, is four pieces: the file type (- for a regular file), then three groups of rwx - owner, group, everyone else - in that fixed order. r = read, w = write, x = execute. A - means that permission is absent. So rw-r--r-- reads as: the owner can read and write, the group can only read, everyone else can only read. Nobody, owner included, can execute it - which matters enormously for a script. The two names right after the permission block, root root, are the owner and the group that owns the file - both root here, which is the other half of the problem: this script belongs to root, but laborant is the one meant to run it.

Changing it

chmod +x run.sh              # add execute, for everyone who already had read
chmod 755 run.sh              # set it exactly: owner rwx, group r-x, other r-x
chown username file            # change who owns it
chown user:group file            # change owner and group together

The numeric form (755) is rwx as three bits per group - r=4, w=2, x=1, added together. 7 = 4+2+1 = all three. Worth recognizing 755 and 644 on sight; you'll see them constantly.

Fix the actual failure

Two things are wrong with run.sh: it isn't executable, and it isn't owned by you (laborant) even though you're the one meant to run it going forward. Fix both, then run it:

sudo chown laborant:laborant /opt/reporting-svc/run.sh
sudo chmod +x /opt/reporting-svc/run.sh
ls -l /opt/reporting-svc/run.sh
-rwxr-xr-x 1 laborant laborant 92 Sep 22 03:44 /opt/reporting-svc/run.sh

Compare this to the broken version above, field by field: the permission block went from -rw-r--r-- to -rwxr-xr-x - an x appeared in all three groups (chmod +x adds execute for everyone who already had read, which here was everyone). The owner and group went from root root to laborant laborant. Both problems, both fixed, both visible in one line of output. Confirm the same two facts with stat, which is built for asking exactly one question at a time instead of parsing a whole ls -l line:

stat -c '%U %a' /opt/reporting-svc/run.sh
laborant 755

%U prints just the owner's username, %a prints just the numeric permissions - 755, matching -rwxr-xr-x exactly (owner 7=rwx, group and other 5=r-x each). Now it should actually run:

/opt/reporting-svc/run.sh
I chmod'd it but it still won't run for me

chmod +x alone doesn't change who owns the file. If you're not the owner and not root, you may not even have permission to run chmod on it in the first place without sudo.