Linux Filesystem Hierarchy and Core Concepts¶

Before you can troubleshoot anything on Linux, you need a correct mental model of where things live and why. This article covers the Filesystem Hierarchy Standard (FHS), permissions, and the ownership model that everything else in this handbook assumes you already know.

How it works¶

Linux organizes everything as files under a single root (/) — there are no drive letters. Separate physical or logical volumes are mounted onto directories within this tree. The Filesystem Hierarchy Standard (FHS) defines what each top-level directory is for:

/proc and /sys are worth dwelling on: they don't consume disk space and their contents are generated on read. /proc/<pid>/ holds live information about a running process; /proc/meminfo, /proc/cpuinfo, and /proc/net/ are where tools like free, top, and (older) netstat actually get their numbers from.

Ownership and permissions¶

Every file has an owner (a user) and a group, plus three permission triplets — owner, group, others — each with read (r), write (w), and execute (x) bits.

$ ls -l /etc/passwd
-rw-r--r-- 1 root root 2847 Oct 15 06:32 /etc/passwd

Reading this left to right: - (regular file, as opposed to d for directory or l for symlink), then rw- (owner root can read/write), r-- (group root can only read), r-- (everyone else can only read).

Permissions are commonly set two ways:

chmod 644 file.txt      # numeric form: owner=rw, group=r, other=r
chmod u+x script.sh     # add execute for the owner only
chown alice:developers file.txt   # change owner to alice, group to developers

The numeric form is a 3-digit octal number, one digit per triplet, where read=4, write=2, execute=1, summed: rw- = 4+2+0 = 6, r-- = 4. So 644 means owner can read/write, group and others can only read.

The sticky bit on /tmp¶

$ stat -c "%a %U:%G %n" /tmp
1777 root:root /tmp

The leading 1 is the sticky bit. On a directory, it means: even though everyone can write into /tmp (the trailing 7), a user can only delete or rename files they themselves own inside it — not each other's files. Without it, /tmp being world-writable would let any user delete any other user's temp files.

Ubuntu/Debian vs. RHEL-family differences¶

The FHS layout itself (/etc, /var, /usr, ...) is identical — it's not a distribution-specific convention, it's a cross-distribution standard both families follow.

Practical exercise¶

1. Create a test file and inspect its default permissions:

   touch ~/test.txt
   ls -l ~/test.txt
   

2. Remove write access for your own user, then try to edit the file with a text editor and observe what happens:

   chmod u-w ~/test.txt
   echo "hello" > ~/test.txt   # this should fail
   

3. Restore write access and check the numeric permission value:

   chmod u+w ~/test.txt
   stat -c "%a" ~/test.txt
   

How to verify you did it correctly¶

• Step 2 should produce bash: /home/<you>/test.txt: Permission denied (bash prints the expanded path) (or your editor's equivalent error).
• After step 3, stat -c "%a" should print 644 (or whatever your original umask produced before you changed anything).

Common mistakes¶

• Using chmod 777 to "fix" a permission error. This makes the file writable and executable by everyone, including other users and (if network-exposed) potentially services you didn't intend to grant access. Find the actual owner/group mismatch instead — ls -l and id <user> will usually show it immediately.
• Confusing /bin vs /usr/bin. On modern distributions these are merged (/bin is a symlink to /usr/bin), but scripts written for older systems sometimes hardcode one or the other.
• Assuming /tmp is persistent. Many distributions mount /tmp as tmpfs (RAM-backed) or clear it on boot — don't store anything there you can't afford to lose.

⚠ Dangerous commands¶

• chmod -R 777 / or any recursive chmod/chown on a system directory can break sudo, SSH, and most system services outright (many daemons refuse to start if their config files are world-writable, as a security measure). Never run a recursive permission change outside a directory you're certain only contains your own application's files.
• rm -rf / (or rm -rf /*) is the canonical catastrophic mistake — modern rm refuses this on the literal root by default, but rm -rf $VAR/ where $VAR is an empty/unset variable expands to the same thing and is not protected against.

Related articles¶

• Writing Robust Bash Scripts
• Understanding systemd
• SSH Hardening and Key-Based Authentication

Review questions¶

1. What is the difference between /bin and /usr/bin on a modern Linux distribution?
2. Why does the sticky bit matter specifically for /tmp?
3. What does chmod 750 file grant to the owner, the group, and everyone else?
4. Why is /proc described as a "virtual" filesystem, and what happens if you try to check its size with du?