Free Linux File Permissions Cheat Sheet PDF: chmod, chown and umask Explained

Every Linux file permissions cheat sheet promises to make chmod click. Most just list commands. This one walks through the actual logic: how to read rwx in ls -l, how symbolic and octal notation map to each other, and the one mistake that wrecks a whole directory when you run chmod -R without thinking first.

Grab the PDF for the quick-reference version. Keep reading if you want the reasoning behind it, not just the syntax.

Why Linux file permissions trip people up

Here’s the thing. chmod 755 isn’t hard to copy-paste. Understanding why it’s 755 and not 750, that’s where people get stuck.

Three separate ideas get bundled into one command: who can act on a file (owner, group, everyone else), what they can do (read, write, execute), and how you express that as a number. Miss one piece and you either lock yourself out of your own script, or leave a config file world-writable without noticing.

Look, this isn’t a knowledge gap you can Google your way around mid-deploy. You need the mental model, not just the syntax.

Reading permissions with ls -l

Run ls -l on any file and you get a string like this:

-rwxr-xr-x  1 root  staff  8192 Sep 16 10:02 deploy.sh

Break down that 10-character block:

So -rwxr-xr-x reads as: a regular file, the owner can read/write/execute, the group can read/execute, everyone else can read/execute. No write access outside the owner. That’s a normal, safe permission set for a script other people need to run but shouldn’t edit.

chmod: symbolic vs octal notation

Two ways to write the same instruction to chmod. Pick whichever fits the situation.

Symbolic notation changes permissions relative to what’s already there:

chmod u+x script.sh      # add execute for the owner
chmod g-w file.txt       # remove write from the group
chmod o=r config.yml     # set "others" to read-only, nothing more
chmod a+x setup.sh       # add execute for everyone

u (user/owner), g (group), o (other), a (all). + adds, - removes, = sets exactly, wiping whatever was there before.

Octal notation sets the whole permission set at once, using three digits (owner, group, other). Each digit is a sum:

Add them together for what you want. Read + write + execute = 4+2+1 = 7. Read + execute = 4+1 = 5. Read only = 4.

chmod 755 script.sh   # owner: rwx (7), group: r-x (5), other: r-x (5)
chmod 644 file.txt    # owner: rw- (6), group: r-- (4), other: r-- (4)
chmod 700 secret.key  # owner: rwx (7), group and other: nothing

Octal to symbolic conversion table

Look up each digit, read left to right, and you’ve decoded any octal permission without a calculator.

chmod recursive: changing permissions on a whole directory

chmod -R applies a permission change to a directory and everything inside it. Sounds simple. It’s the most common way people break a deployment.

chmod -R 755 /var/www/app

Problem: this sets 755 on every file and every directory underneath, including files that had no business being executable. A directory needs the execute bit to be traversable, a text config file usually doesn’t need execute at all. Blanket -R 755 makes every file in that tree “executable,” which isn’t a permission error exactly, but it’s sloppy and it hides real permission problems the next time something breaks.

The safer pattern separates files from directories:

find /var/www/app -type d -exec chmod 755 {} \;
find /var/www/app -type f -exec chmod 644 {} \;

Directories get 755 (traversable), files get 644 (readable, not executable). If some files genuinely need to run, chmod +x them individually after.

There’s also a one-line version using the capital X flag, which only adds execute to files that already have it set for somebody:

chmod -R u+rwX,go+rX,go-w /var/www/app

That’s the version worth remembering if you only take one thing from this section.

chown and chgrp: changing ownership

chmod controls what’s allowed. chown and chgrp control who’s asking.

chown deploy:www-data app.conf     # set owner to "deploy", group to "www-data"
chown deploy app.conf              # change owner only, leave group as is
chown :www-data app.conf           # change group only, leave owner as is
chgrp www-data app.conf            # same as the line above, older syntax
chown -R deploy:www-data /srv/app  # apply to a whole directory tree

Ownership and permissions work together. chmod 640 on a file means nothing useful if the wrong user owns it, you’ll either lock out someone who needs access or leave it open to someone who shouldn’t have it. Check both when something “isn’t working” and the permission bits look correct.

Special permissions: setuid, setgid and the sticky bit

Past the standard read/write/execute, three special bits show up often enough to know on sight, even if you rarely set them yourself.

You’ll see these stacked as a fourth leading digit: chmod 4755 sets setuid plus the usual 755. In ls -l, they show up as an s, S, or t replacing the normal execute character.

umask and default permissions

Ever notice a brand new file lands at 644 and a brand new directory lands at 755, without anyone running chmod? That’s umask.

Linux starts from a base: 666 for files, 777 for directories (read/write for everyone on files, full access on directories, execute is never a file default). umask subtracts from that base for every new file or directory you create.

umask        # show the current value
umask 022    # set it

With the common default of 022: new files get 666 - 022 = 644, new directories get 777 - 022 = 755. Change the umask to 002 on a shared project folder and new files come out group-writable by default, useful for a team directory where everyone needs write access without running chmod after every touch.

What’s inside the PDF

• The full ls -l breakdown, read left to right
• Symbolic notation (u+x, g-w, o=r, a+x) with what each operator does
• Octal notation with the 4/2/1 math spelled out
• The complete octal-to-symbolic conversion table (0 through 7)
• The safe pattern for chmod -R on a directory tree, files vs directories
• chown, chgrp and the difference between changing owner, group, or both
• Special permission bits: setuid, setgid, sticky bit, with octal values
• umask and the subtraction math for default file and directory permissions
• Format: single-page PDF, print-ready

Who it’s for

• Linux+ and CompTIA A+ candidates working through file system security objectives
• DevOps engineers who need to stop guessing at chmod numbers mid-deploy
• Junior sysadmins troubleshooting “permission denied” errors for the first time
• Anyone who’s run chmod -R 777 on something out of frustration and knows that’s not a real fix

Intermediate level. You should already be comfortable in a terminal (cd, ls, editing a file) before this one. If you’re still building that foundation, start with our Linux Commands Cheat Sheet PDF first, it covers the 64 commands you’ll actually type before permissions come up.

Want the hands-on version instead of just the reference sheet? Our DevOps Certification Workbook opens with a full Linux administration and Bash scripting foundation, then builds into CI/CD, Docker and Kubernetes labs where permission handling shows up constantly (deployment scripts, container file ownership, CI runner access). This cheat sheet is the reference you’ll want open next to you while you work through it.