DEV Community: The Linux Camp

Linux Permissions, Explained by Breaking Them on Purpose" published: true

The Linux Camp — Sat, 01 Aug 2026 03:28:45 +0000

Most permission tutorials start with the table. Nine bits, three triplets, r is 4, w is 2, x is 1. You read it, you nod, and a week later you are pasting chmod 777 from a forum answer like everyone else.

This one runs backwards. We break things on purpose, read the exact error each breakage produces, and work out what the system was checking. The table arrives at the end, where it stops being trivia and becomes the name for something you have already felt.

You need any Linux machine: a VM, a cheap cloud box, a Raspberry Pi, WSL on Windows. Everything happens inside one throwaway folder, and the worst outcome available to you is deleting that folder. Twenty minutes.

The three questions

Hold one model in your head the whole way. Every time you touch a file, the kernel, the core of Linux that referees every file access, asks three questions in this order:

Are you the owner of this file?
If not, are you a member of the file's group?
If neither, you are everyone else.

It takes the first category that matches you, reads that category's three permissions (read, write, execute), and stops. It never falls through to the next category to see whether some other category would have been kinder. That "and stops" is where all the strangeness lives, and Break 1 makes it hurt.

The sandbox

zayden@lab:~$ mkdir playground
zayden@lab:~$ cd playground
zayden@lab:~/playground$

Everything below stays in there. When you are finished, the whole crime scene comes off in two commands:

cd ~              # step out of the playground first
rm -r playground  # delete the directory and everything inside it

Use a normal user account that can run sudo, not a root login. Root skips almost every permission check, which would quietly spoil each experiment before it starts. Why root gets that treatment is Break 4's job.

Break 1: Lock yourself out of your own file

Make a file and look at it:

zayden@lab:~/playground$ echo "secret plans" > notes.txt
zayden@lab:~/playground$ ls -l notes.txt
-rw-r--r-- 1 zayden zayden 13 Jul 30 10:02 notes.txt

That string of dashes and letters at the front is the permission readout. Ignore it for a few more minutes. Now remove every permission from everyone, including yourself:

zayden@lab:~/playground$ chmod 000 notes.txt
zayden@lab:~/playground$ ls -l notes.txt
---------- 1 zayden zayden 13 Jul 30 10:02 notes.txt
zayden@lab:~/playground$ cat notes.txt
cat: notes.txt: Permission denied

You own this file. Your name is on it twice. The kernel refused you anyway, and the reason is that "and stops" rule. Question one: are you the owner? Yes. So it read the owner's three permissions, found no read there, and stopped. Whether the group or everyone else could read the file was never considered. First match, then verdict, no appeal.

So are you locked out forever?

zayden@lab:~/playground$ chmod 644 notes.txt
zayden@lab:~/playground$ cat notes.txt
secret plans

chmod worked while cat did not, because changing permissions is not governed by the permission bits at all. It is a right of ownership. The owner can always change a file's mode, even when the current mode grants the owner nothing. You can lock yourself out of a file's contents, but you cannot lock yourself out of the lock.

Break 2: The script that refuses to run

Write a two-line script and try to run it:

zayden@lab:~/playground$ printf '#!/bin/bash\necho "hello from the script"\n' > hello.sh
zayden@lab:~/playground$ ./hello.sh
bash: ./hello.sh: Permission denied

Same error text as Break 1, completely different check underneath. ./hello.sh asks the kernel to execute this file as a program, and execute is its own separate permission. Reading was never the problem, which you can prove in one line:

zayden@lab:~/playground$ bash hello.sh
hello from the script

bash hello.sh runs bash, which is already executable over in /usr/bin, and bash merely reads your file the way cat would. Read is granted, so it works. Running the file directly is the thing that needs the x bit on the file itself. One chmod flips it:

zayden@lab:~/playground$ chmod +x hello.sh
zayden@lab:~/playground$ ls -l hello.sh
-rwxr-xr-x 1 zayden zayden 41 Jul 30 10:05 hello.sh
zayden@lab:~/playground$ ./hello.sh
hello from the script

+x with no letter in front of it means "add execute everywhere the umask allows", and a standard umask of 022 blocks only write bits, so all three x characters appeared at once. That asymmetry between ./hello.sh and bash hello.sh is worth remembering. When a script suddenly stops running after you copy it between machines or pull it out of a zip archive, the file is usually fine and the x bit is what went missing.

Break 3: Seal a directory shut

This is the one that bends brains. Directories carry the same nine bits, but x means something different on them: not "run this", but "pass through this". Watch what happens when it goes missing.

zayden@lab:~/playground$ mkdir vault
zayden@lab:~/playground$ echo "gold" > vault/treasure.txt
zayden@lab:~/playground$ chmod a-x vault
zayden@lab:~/playground$ ls -ld vault
drw-r--r-- 2 zayden zayden 4096 Jul 30 10:07 vault
zayden@lab:~/playground$ cd vault
bash: cd: vault: Permission denied

cd is pure pass-through, so it dies instantly. Now the strange part:

zayden@lab:~/playground$ ls vault
ls: cannot access 'vault/treasure.txt': Permission denied
treasure.txt
zayden@lab:~/playground$ ls -l vault
ls: cannot access 'vault/treasure.txt': Permission denied
total 0
-????????? ? ? ? ?            ? treasure.txt

An error and a result at the same time, then a row of question marks. Here is the unlock: a directory is a file whose contents are a list of names. The r bit lets you read that list, which is why treasure.txt still prints. But the file's size, owner, permissions and timestamps live with the file itself, on the far side of the door you just sealed, and reaching them requires x. ls could read the guest list and could not walk in, so every fact about the file came back as a question mark.

If you are wondering why plain ls needed those details at all, it did not. Most systems alias ls to ls --color=auto, and picking a color per file requires the same blocked lookup. That is the alias talking, not ls itself.

Reading the file is fully off the table:

zayden@lab:~/playground$ cat vault/treasure.txt
cat: vault/treasure.txt: Permission denied

It is not only the last directory in the path, either. To reach vault/treasure.txt the kernel needs x on every directory along the way, starting at /. One sealed door anywhere above a file blocks everything below it, which is why a permission problem is so often three levels higher than the file you are shouting at.

Now flip the experiment and give the directory x without r:

chmod 711 vault  # 7 = rwx for you, 1 = execute only for group and everyone else

That is a speakeasy instead of a sealed vault. As group or other, cd vault works and cat vault/treasure.txt works if you already know the name, but ls vault fails outright. A menu with no door, or a door with no menu. The two bits really are that independent, and web servers lean on the door-with-no-menu form constantly.

One more directory surprise: deleting a file is an edit to the directory, because you are erasing a name from its list. rm therefore cares about w and x on the directory, not about the file's own bits. That is why rm can delete a read-only file inside a writable directory (it asks first) and cannot delete anything inside a directory you cannot write.

Repair the vault before moving on:

zayden@lab:~/playground$ chmod 755 vault
zayden@lab:~/playground$ cat vault/treasure.txt
gold

Break 4: Try to give your file away

zayden@lab:~/playground$ chown root notes.txt
chown: changing ownership of 'notes.txt': Operation not permitted

New error text, and the difference matters more than any bit in this article. "Permission denied" means the kernel checked the bits and the bits said no. "Operation not permitted" means the bits were never consulted, because the operation itself is reserved. On Linux, giving a file away is root-only. If ordinary users could hand files to each other, you could dump junk onto someone else's disk quota, or plant a file that looks like somebody else wrote it. So there are no three questions here. There is one: are you root? You are not.

zayden@lab:~/playground$ sudo chown root notes.txt
[sudo] password for zayden:
zayden@lab:~/playground$ ls -l notes.txt
-rw-r--r-- 1 root zayden 13 Jul 30 10:02 notes.txt

Same file, same folder, same you. Try to append a line:

zayden@lab:~/playground$ echo "one more line" >> notes.txt
bash: notes.txt: Permission denied
zayden@lab:~/playground$ cat notes.txt
secret plans

Run the three questions yourself before reading on. Owner? No, that is root now. Group? Yes, the file's group is still zayden and you are in it, so the kernel reads the group triplet: read yes, write no, and stops, exactly like Break 1. Reading works, appending does not. The error names bash rather than echo because your shell opens the file for the >> redirect before echo ever runs, which is a useful tell: when the complaint comes from bash, the redirect failed and the command never started.

So what did sudo actually do? It ran chown as root, and root passes nearly every file permission check automatically. Sudo does not grant you permission. It removes the questions. That is why it fixes almost everything, and why reaching for it by reflex is a bad habit. You are not solving the puzzle, you are unplugging the referee. (Nearly every check: even root cannot execute a file that has no x bit anywhere. The kernel wants at least one signal that the thing was meant to be a program.)

Take your file back:

zayden@lab:~/playground$ sudo chown zayden notes.txt

The notation you already felt

Now the table, which at this point is a summary rather than a mystery.

The ten characters at the front of ls -l

- rwx r-x r-x
^  ^   ^   ^
|  |   |   everyone else
|  |   group
|  owner
type: - file, d directory, l symlink

ls prints those with no spaces, as -rwxr-xr-x. They are spaced out here to show the grouping. Three triplets, one per question, each answering read, write and execute with a letter for yes and a dash for no. Every error you caused above was the kernel landing on one triplet and finding a dash where it needed a letter.

The three digits in chmod 755

The numeric form compresses each triplet into a single digit: r is 4, w is 2, x is 1, add them up. So 7 is rwx, 6 is rw-, 5 is r-x, 4 is r--, and 0 is nothing at all.

Octal	Triplets	Where you felt it
000	--- --- ---	Break 1, locked out of your own notes
644	rw- r-- r--	notes.txt as created, hello.sh before +x
755	rwx r-x r-x	hello.sh after +x, the repaired vault
711	rwx --x --x	the speakeasy vault, door with no menu
600	rw- --- ---	private files, and ssh refuses keys looser than this

The chmods you have been pasting for years now decode themselves. chmod 644 is "owner reads and writes, everyone else reads". chmod 755 is the same plus execute for all, the standard for scripts and for directories people are meant to enter. chmod 777 hands all nine yeses to everyone, and usually marks the spot where somebody stopped debugging and started gambling.

The symbolic form

The letters address the same three lanes: u owner, g group, o everyone else, a all three, combined with + to add, - to remove, and = to set exactly.

chmod u+x deploy.sh     # add execute for the owner only
chmod go-w report.txt   # take write away from group and everyone else
chmod a-x vault         # remove execute from all three, which is what Break 3 did
chmod u=rw,go= key.pem  # set exactly: owner reads and writes, nobody else gets anything

Symbolic form is the safer habit when you are adjusting one thing, because it changes only the bits you name. Octal replaces all nine at once, so a typo in a hurry rewrites permissions you never meant to touch.

The error decoder

Four messages cover most permission trouble, and you have now caused every one of them on purpose.

`cat: notes.txt: Permission denied`

The bits denied a read. The same shape comes from cp, grep, less and anything else that opens a file. Check first: run ls -l notes.txt, work out which single triplet applies to you, and look for r in it.

`bash: ./hello.sh: Permission denied`

An execute was refused. Check first: ls -l hello.sh and look for x in your triplet. If x is present and it still fails, check whether the filesystem is mounted noexec, which is common on /tmp and on USB drives.

`bash: cd: vault: Permission denied`

Pass-through was refused. Check first: ls -ld vault, where the d makes ls describe the directory itself instead of listing its contents. Remember that the check applies to every directory on the path, not only the last one.

`chown: changing ownership of 'notes.txt': Operation not permitted`

Not a bits problem. This is a root-only operation, so chmod will never fix it. Check first: whether the change genuinely needs sudo, and whether you are sure it does. Any time you see "Operation not permitted" where you expected "Permission denied", stop staring at the permission bits and go looking for the rule instead.

Where to practice safely

Not on machines you care about. Permission experiments escalate: today you chmod 000 a note, next month you fat-finger a recursive chmod in the wrong terminal window. Do your breaking where mistakes are free.

A local VM is the classic answer. VirtualBox with a Debian or Ubuntu image, take a snapshot before you start, roll back when things get strange. A cheap cloud box you can rebuild on demand works the same way. WSL handles everything in this article too, as long as you work inside your Linux home directory rather than under /mnt/c, where the permission bits behave oddly because they are being translated from Windows.

Full disclosure, I built the third option: The Linux Camp (thelinuxcamp.com), real Linux VMs in your browser that boot in about a second, made for exactly this break-and-inspect style of learning. Wreck the machine, reset it, go again, and your progress is verified from the commands you actually type. Sign-up is required to launch a VM, the first track is free, and everything past it is $14.99 a month. Every experiment above runs identically on any Linux box you already have, so start wherever you are.

However you practice, keep the habit. Next time something denies you, do not paste a fix from a forum. Ask which of the three questions matched you, and which single bit said no. The system is not being difficult. It is answering exactly the question you asked, and you now speak enough of its language to ask better ones.

How to Learn Linux in 2026 (Hands-On, Free, No Experience Needed)

The Linux Camp — Sat, 01 Aug 2026 03:05:10 +0000

Here is the whole method: get access to a real Linux machine, type commands on it for 30 to 60 minutes every day, and follow a plan that builds from navigating the filesystem up to running your own web server. Do that and you will be comfortable in four weeks and genuinely fluent in about eight.

No experience required, no money required. The rest of this article is the specific plan: what to type each week, where to get a free machine you can safely break, what the three scariest errors mean, and how to tell you are actually improving.

Why most people fail at Linux

The pattern is nearly universal. Someone decides to learn Linux, finds a nine-hour video course, watches it at 1.5x speed, takes beautiful notes, and three weeks later cannot list the contents of a directory without checking those notes.

Watching someone else type is not practice. It feels like learning because the explanation makes sense while you hear it. But command line skill is muscle memory wrapped around a mental model, and both are built one way: typing, failing, reading the error, trying again. An hour of reading about ls teaches you less than typing ls twenty times in twenty directories. Videos are fine as a preview. They are just not the workout.

So flip the ratio: for every minute reading or watching, spend five with your hands on a keyboard. This article included. Read a section, then go type it.

Two smaller failure modes show up almost as often.

Trying to memorize everything

Linux has thousands of commands. Working engineers lean hard on a core of about 25 and look up the rest without shame. The plan below teaches that core and nothing else.

Fear of breaking things

On a practice machine, breaking things is the goal, not the risk. A system you broke and fixed teaches more than ten flawless tutorials. Every option in the practice section makes the worst case "start over," which costs a minute.

The four-week plan

First, get a machine from the free options below (one minute to one afternoon, depending which you pick). Then follow three rules:

Daily beats big. Thirty focused minutes every day builds more skill than four hours on Saturday. Consistency is the entire trick.
Type everything yourself. Even the commands that look trivial. Especially those.
Learn the two magic keys today. Press Tab to autocomplete commands and file names. Press the up arrow to bring back previous commands. These two habits save hours every week.

Each week has a small command set, daily reps, and a test. Move on only when you pass the test without notes.

Week 1: Move around with pwd, ls, cd, cat

First, one definition: the terminal is the text window where you type commands and Linux types back. That is the entire interface. It looks hostile, and it is not. It is just quiet.

Your daily reps, in order:

pwd            # print working directory: "where am I?"
ls             # list what is here
ls -l          # long view: permissions, owner, size, date
ls -a          # also show hidden files (names starting with a dot)
cd /           # go to the root of the filesystem
ls
cd /var/log    # jump to a specific place
ls -l
cd ~           # jump straight home
cd ..          # go up one level
cd -           # bounce back to wherever you just were
cat /etc/hostname     # print a file's contents to the screen
cat /etc/os-release

The mental model: Linux is one big tree of directories (folders) rooted at /. A path like /var/log is an address in that tree. Paths starting with / are absolute and work from anywhere; paths without it are relative to where you stand.

Week 1 pass test

Dropped into any directory, you can figure out where you are, get to /var/log, print a file that lives there, and get home in one command. No notes.

Week 2: Create, copy, protect with mkdir, cp, mv, rm, chmod, chown

Week 1 was looking. Week 2 is changing things, and everything below is safe to get wrong.

mkdir practice             # make a directory
cd practice
touch empty.txt            # create an empty file
echo "hello" > notes.txt   # create a file with text in it
cp notes.txt backup.txt    # copy
mv backup.txt old.txt      # move, which is also how you rename
rm old.txt                 # remove. There is no trash can. Gone is gone.
mkdir -p web/css/img       # -p builds the whole nested path at once
cp -r web web-copy         # -r copies a directory and everything in it

The command line assumes you mean what you say. rm does not ask twice, and rm -r on the wrong directory is the classic disaster.

Now permissions, the biggest source of beginner confusion. Run ls -l and look at the start of a line, something like -rw-r--r--. That is three sets of three: owner, group, everyone else. r is read, w is write, x is execute (run as a program).

chmod 600 notes.txt          # only you can read and write it
chmod u+x hello.sh           # let the owner run it as a program
sudo chown root notes.txt    # hand the file to the root user
sudo chown $USER notes.txt   # take it back

The numbers: read is 4, write is 2, execute is 1, summed per group. So 600 is "owner reads and writes, everyone else nothing," and 755 is "owner everything, everyone else read and run." Two more definitions: root is the administrator account that can do anything, and sudo runs one command with root's power.

Week 2 pass test

You can build a small directory tree, write a two-line script and run it, and lock a file so only your user can read it. Here is the script, if you want it:

echo '#!/bin/bash' > hello.sh                        # names the program that runs the file
echo 'echo Hello from my first script' >> hello.sh   # >> appends instead of overwriting
chmod u+x hello.sh                                   # make it runnable
./hello.sh                                           # ./ means "in this directory"

Week 3: Processes and software with ps, kill, systemctl, apt

Everything running on a Linux machine is a process, and every process has an ID number called a PID. This week: see them, stop them, and install new software.

ps aux                 # every process on the machine right now
ps aux | grep bash     # the | pipes one command's output into another
sleep 300 &            # start a five-minute do-nothing process in the background
ps aux | grep sleep    # find it and note its PID
kill 12345             # replace with the real PID: politely ask it to exit
kill -9 12345          # force it. Last resort only.

One opinion to adopt early: reaching for kill -9 first is a bad habit. Plain kill lets a program clean up after itself, and -9 yanks the power cord. Use it only after polite failed.

Installing software, on Ubuntu and Debian:

sudo apt update          # refresh the list of available software
sudo apt install htop    # a friendlier process viewer. Go explore it.
sudo apt remove htop

Services are long-running background processes (web servers, databases) managed by a supervisor called systemd. Try it on cron, the job scheduler present on virtually every Linux machine:

systemctl status cron               # is it running? since when? any recent errors?
sudo systemctl restart cron
systemctl list-units --type=service # every service systemd manages

Read status output closely: the Active: line gives the state, and the last lines are the service's own recent logs. The bottom is where answers live.

Week 3 pass test

You can start a background process, hunt down its PID, and kill it, install and remove a package, and check whether a service is running, then restart it.

Week 4: Networking, logs, and your first web server with ip, ss, journalctl

Two definitions first: an interface is how your machine reaches the network, and a port is the numbered door a program listens on.

ip a                # your machine's network interfaces and addresses
sudo ss -tulpn      # every port something is listening on, and what
journalctl -u cron  # the full log history of one service
journalctl -f       # live tail of every log. Ctrl-C stops it.

Then the project that ties all four weeks together. Budget about an hour.

Install a web server: sudo apt install nginx
Confirm it is running: systemctl status nginx (week 3 skill)
Fetch your site: curl localhost (curl downloads a web page in the terminal). Real HTML comes back. You are running a web server.
See it holding port 80: sudo ss -tulpn | grep 80
Make the page yours: echo "<h1>I built this</h1>" | sudo tee /var/www/html/index.html then curl localhost again. The sudo is week 2: that directory belongs to root.
Now break it on purpose. Open the config with sudo nano /etc/nginx/sites-enabled/default and delete one semicolon. Run sudo systemctl restart nginx. It fails.
Fix it by reading, not guessing: systemctl status nginx shows the failure, sudo nginx -t names the exact file and line, journalctl -u nginx -e shows the history. Repair, restart, and curl works again.

Steps 6 and 7 are the whole point. Professional Linux work is mostly this exact loop: change something, watch it break, read the logs, fix it, confirm. You just ran a full shift of it somewhere nothing could go wrong.

Week 4 pass test

You can serve a page you wrote, break the config on purpose, and bring the service back using only systemctl status, nginx -t, and journalctl.

Weeks 5 through 8: from familiar to fluent

If you want fluency instead of familiarity, repeat the whole plan on a fresh machine without notes, then extend it. Add a second user and lock your files away from them. Schedule a job with cron. SSH between two machines. Turn one-off commands into small shell scripts. Fluency is repetition with variation, nothing fancier.

Where to practice for free

You need a machine you can hurt without consequences. In 2026 there are more free options than ever, so pick by temperament. Ubuntu and Debian, which most of these run, are distributions: packaged versions of Linux. Every command in this plan is identical on both.

A virtual machine with VirtualBox

Install VirtualBox (free), download an Ubuntu Server ISO (free), and create a virtual machine. You get a complete real system with snapshots: save its state before a risky experiment, roll back after. Cost: an afternoon and a few gigabytes of disk. On an Apple Silicon Mac, use UTM instead, same idea. If you want maximum realism, this is the pick, and the setup is itself a decent first lesson.

WSL2 on Windows

Open PowerShell as administrator, run wsl --install, reboot, and you have Ubuntu running inside Windows. The fastest route to a real shell, and weeks 1 through 3 run on it perfectly. Two caveats: it lives on your daily machine, so reckless experimentation feels riskier, and some service and networking behavior differs from a standalone server.

OverTheWire Bandit

A free game played over SSH at overthewire.org. Each level hides the password to the next, and the week 1 and 2 commands dig it out. Start with ssh bandit0@bandit.labs.overthewire.org -p 2220, password bandit0. Bandit makes reps addictive, but it is puzzles rather than a structured path, so run it alongside this plan, not instead of it.

Linux Journey

Free, well organized reading at linuxjourney.com that explains concepts in a friendly order. Reading rather than typing, so treat it as the companion text after a hands-on session, never as the session itself.

The Linux Camp

Full disclosure: I built this one (thelinuxcamp.com), so weigh my bias accordingly. It runs real Linux VMs in the browser that boot in about one second, with progress verified from the actual commands you type, so there is nothing to install and completion is not on the honor system. A free account gets you the first track, and everything past it is $14.99 a month. You do not need it for this plan, a VirtualBox VM plus discipline is enough, but if setup friction is what killed your previous attempts, it removes all of it.

An old laptop

The sleeper option. Install Debian directly onto a machine you no longer care about and it becomes a pure toy with zero stakes, the best learning environment there is.

The three errors every beginner hits

Error messages are not the machine being hostile. They are the machine being precise. Read them literally and they usually tell you the fix.

`Permission denied`

You asked for something your user is not allowed to do. Check three things in order. First, ls -l the file: are you the owner, and does your slot in the rwx string include what you attempted? Second, a script you cannot run may be missing its execute bit, and chmod u+x script.sh fixes that. Third, some actions genuinely need root, so sudo is the answer, but ask why before typing it. Reflexive sudo on everything is how beginners turn small mistakes into big ones.

`command not found`

The shell searched everywhere it knows and found no program by that name. Cause one, by a mile: a typo. Cause two: the program is not installed, which sudo apt install fixes. Cause three catches everyone exactly once: you typed script.sh instead of ./script.sh. The shell searches only its known program directories, never your current one, so you must point at your own script with ./.

`No such file or directory`

The path you typed does not exist from where you are standing. Run pwd to confirm where that actually is. Check the spelling, and remember Linux is case sensitive: Notes.txt and notes.txt are two different files. The permanent cure is Tab completion. If you press Tab and the name will not complete, the path is wrong, and the shell just told you so before you even hit Enter.

How to know you are actually progressing

Here is the metric I trust more than any quiz: you stop googling the same command twice. Searching for new things is normal and permanent, and every working engineer does it daily. But if you are searching "how to extract tar file" for the fifth time, the reps are not landing. Slow down and type more.

Other honest signals:

Tab and the up arrow are reflexes, and watching someone type without them feels slow.
ls -l output reads like a sentence instead of a cipher.
When something fails, your pulse does not spike. Your fingers are already typing systemctl status, then heading for the logs.
You break something, fix it in four minutes, and feel vaguely disappointed that it was that easy.

And the signals that count for nothing, no matter how productive they feel: hours of video watched, notes taken, tutorials bookmarked. If your fingers did not type, the skill did not move.

Start tonight

Not this weekend. Tonight. Pick whichever practice option removes your personal excuse, open the terminal, and type these four commands:

pwd             # where am I?
ls              # what is here?
cd /etc         # move into the system config directory
cat os-release  # print the file that names your distribution

Ten minutes and day one is done. Twenty seven to go.