The Filesystem Hierarchy (FHS) & Navigation: /, /etc, /var, /home, Absolute vs Relative Paths

Open a terminal on a fresh Linux box and the first feeling is usually “where is everything?” On Windows you have C:\Users\you\Documents and a Start menu; here you have a blinking cursor and a slash. This lesson replaces that lost feeling with a map. By the end you will be able to land on any Linux machine you have never seen — a cloud VM, a container, a Raspberry Pi, your work laptop’s WSL — and know within seconds where the config lives, where the logs are, where your files go, and how to walk there without fumbling.

Why this matters

Almost every early Linux frustration is really a navigation problem in disguise. “My command says file not found, but I can see the file.” “I edited the config and nothing changed.” “I saved something in /tmp and it vanished after a reboot.” “The tutorial says edit /etc/… but I don’t know if I’m allowed to.” Every one of these dissolves the moment you hold two ideas in your head: there is exactly one tree, and each branch of that tree has a well-known job.

The single tree is the big mental shift coming from Windows. There are no drive letters. There is no C:\. There is one root, written /, and everything hangs off it — your files, the programs, the kernel’s own view of itself, and every disk and USB stick you plug in. A second hard drive doesn’t become D:; it gets mounted onto an empty directory somewhere in the one tree, and from then on it just looks like a folder. This is not a cosmetic difference. It means you can always reason about a Linux system as a single hierarchy you walk up and down, and you never have to guess which letter a thing lives behind.

The second idea is that the layout is a standard, not a per-distro accident. It is written down in the Filesystem Hierarchy Standard (FHS), which is why /etc means “configuration” on Ubuntu, Rocky, Alpine, Amazon Linux and a NAS appliance alike. Learn the map once and it transfers everywhere for the rest of your career. That is a rare thing in tech — knowledge that does not expire — so it is worth an hour now.

This lesson is pure navigation: we look, we don’t yet change. Actually creating, copying, moving and deleting files is the next lesson, on managing files and directories with cp, mv, rm and find. If you have only just met the shell, the getting started, first login and getting help lesson sits directly before this one.

One tree, no drive letters: “everything is a file”

Two slogans capture the Unix filesystem philosophy, and both are worth taking literally.

Slogan one: there is one unified tree rooted at /. Read a path left to right and each / is a step deeper into the tree. /home/vinod/notes.txt means: start at the root /, go into home, then into vinod, then the file notes.txt. The very first / is the root; the later slashes are just separators between directory names. There is no equivalent of C: or D: — a disk becomes visible by being mounted onto a directory, so /mnt/backup might be a whole separate SSD while /home is on your main disk, and nothing in the path tells you (nor should you have to care).

Here is the contrast that unlocks it for anyone coming from Windows:

Slogan two: everything is a file. In Unix, the “file” is the universal interface. A regular document is a file, obviously — but so is a directory (a special file that lists other files), a disk (/dev/sda), your terminal (/dev/tty), a source of randomness (/dev/urandom), a running process’s memory map (/proc/1234/maps), and a network socket. Because they all present as files, the same handful of tools (ls, cat, stat, redirection with > and <) work on all of them. That uniformity is why Linux composes so well.

You can already see the different kinds. The first character of an ls -l line names the file’s type:

Keep that first column in mind — we decode a full ls -l line later, and it starts with exactly this character.

The FHS tour: every top-level directory, and whether you touch it

This is the reference you will come back to. Every mainstream distro puts the same things in the same places because they all follow the FHS. Read the table once now, skim it forever after. The third column — do you edit it? — is the part beginners most need: some directories are yours to change, others belong to the package manager or the kernel and editing them by hand is either pointless (it gets overwritten on the next update) or dangerous.

⚠️ Two of these deserve a warning. Never run rm -rf / or anything that deletes at the root — it will try to erase the entire system. And do not “tidy up” /proc, /sys, /dev or /run: those are not real files on disk, and deleting entries there is meaningless at best and destabilising at worst.

The modern /usr merge (why /bin and /usr/bin are the same)

Historically /bin, /sbin and /lib held the bare-minimum tools needed to boot and repair a system before /usr (which might be a separate disk) was mounted, and /usr/bin held everything else. That split stopped making sense once every root filesystem could reach /usr at boot. So modern distros — Fedora/RHEL since RHEL 7, Debian since 12 (bookworm), Ubuntu since 19.10, Arch, and most others — did the usr-merge: /bin, /sbin and /lib became symlinks into /usr. Prove it on your own box:

# On any modern distro, /bin is just a symlink to usr/bin:
ls -ld /bin /sbin /lib

lrwxrwxrwx 1 root root 7 Apr 22  2024 /bin -> usr/bin
lrwxrwxrwx 1 root root 8 Apr 22  2024 /sbin -> usr/sbin
lrwxrwxrwx 1 root root 7 Apr 22  2024 /lib -> usr/lib

The l at the start and the -> confirm they are links. Practically: /bin/ls and /usr/bin/ls are the same file, and when you install a custom tool by hand you still put it in /usr/local/bin, not /bin.

A few pairs beginners confuse

Some directories look similar and trip people up. These two tables settle the two most common mix-ups.

The FHS also classifies every directory along two axes that explain the layout’s logic: static vs variable (does the content change at runtime?) and shareable vs local (could it be shared read-only over a network to many hosts?). It’s why config that you change (/etc) is kept apart from programs that don’t change (/usr), which are kept apart from data that grows (/var).

Here is the whole map as one picture. Read from the root / on the left; each branch is a direct child of the one tree, and the numbered points are the five places a beginner reaches for most.

The one-line summary of the whole tour: /etc is what you configure, /usr is what you run, /var is what grows, /home is what you own, and /proc+/dev are the kernel showing you itself.

Absolute vs relative paths, and the five special tokens

A path is just a route through the tree. There are two ways to write one, and confusing them is the single most common beginner mistake.

An absolute path starts with /. It is measured from the root, so it means the same thing no matter where you currently are. /var/log/syslog is /var/log/syslog whether you type it from your home directory, from /tmp, or inside a script run by cron at 3am.

A relative path does not start with /. It is measured from your current working directory (the directory you are “in”, shown by pwd). If you are in /var and type log/syslog, the shell resolves it against your location to /var/log/syslog. Stand somewhere else and the same text points somewhere else — or nowhere.

Woven into paths are five short tokens that mean special places. Memorise these — they appear constantly:

Two quick clarifications. The . prefix on ./script.sh is not decoration — you need it to run a program in the current directory, because for safety the shell does not search your current directory for commands (more on that in the getting-started lesson). And ~ is expanded by the shell into your home path before the command even runs, which is why echo ~ prints /home/vinod.

Navigating: pwd, cd, ls and their friends

Three commands do 90% of moving around: pwd (where am I?), cd (go there), ls (what’s here?). The rest of this section adds the inspection tools that tell you about a path without opening it.

pwd — print working directory

pwd

/home/vinod

That’s it — pwd answers “where am I standing in the tree?” It has one flag worth knowing: pwd -P prints the physical path with all symlinks resolved, while plain pwd (-L, logical) may show the symlinked name you cd’d through.

cd — change directory

cd takes you somewhere. Its no-argument and shortcut forms are what make an expert look fast:

Watch cd - toggle you between two directories — it’s how you bounce between a config dir and a log dir without retyping:

cd /etc/ssh          # go dig in the config
cd -                 # bounce back to where you were

/home/vinod

ls — list directory contents

ls on its own gives a bare, columnated list. Its flags turn it into a precision instrument. These are the ones you’ll actually use:

Combine them freely. The two combos you’ll type most: ls -lah (everything, long, human sizes) and ls -ltr (long, oldest-to-newest, so the newest files land at the bottom by your prompt).

ls -lah ~

total 40K
drwxr-xr-x  5 vinod vinod 4.0K Jul  9 09:14 .
drwxr-xr-x 48 root  root  4.0K Jul  9 08:02 ..
-rw-------  1 vinod vinod  820 Jul  9 09:10 .bash_history
-rw-r--r--  1 vinod vinod  220 Jan  1  2024 .bashrc
drwxr-xr-x  3 vinod vinod 4.0K Jul  9 09:12 projects
-rw-r--r--  1 vinod vinod 1420 Jul  9 09:14 notes.txt

Notice the first two entries: . is this directory and .. is its parent — the same tokens from the previous section, now showing up as real entries you can see. Notice too that .bashrc and .bash_history only appeared because of -a; a plain ls would hide them.

The inspection tools: tree, stat, file, realpath, basename, dirname

These answer questions about a path without opening the file. Learn them and you stop guessing.

tree is not installed by default, so on a fresh box you’ll add it. This is one of the few places the two big distro families differ, so here are both:

# Debian / Ubuntu (apt family)
sudo apt update && sudo apt install -y tree

# RHEL / Fedora / Rocky / Alma (dnf family)
sudo dnf install -y tree

tree -L 2 /etc/ssh

/etc/ssh
├── ssh_config
├── ssh_config.d
│   └── 50-redhat.conf
├── sshd_config
└── sshd_config.d

stat is the deepest look. It shows size, the inode, link count, permissions in both octal and symbolic form, owner/group, and the three timestamps (access, modify, change):

stat notes.txt

  File: notes.txt
  Size: 1420       Blocks: 8      IO Block: 4096   regular file
Device: 8,2  Inode: 1315874    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ vinod)   Gid: ( 1000/ vinod)
Access: 2026-07-09 09:14:02 +0530
Modify: 2026-07-09 09:14:02 +0530
Change: 2026-07-09 09:14:02 +0530

realpath and readlink -f are your friends whenever symlinks confuse you — they collapse ., .. and links into one true absolute path:

realpath ../log/../log/syslog   # from /var/anything
realpath /bin                   # follow the usr-merge symlink

/var/log/syslog
/usr/bin

Decoding an ls -l line, field by field

ls -l is the single most-read line in Linux, and every field is worth naming. This also sets up the next-next lesson on permissions, because the left-hand block is exactly what chmod and chown operate on. Take this one line:

-rw-r--r-- 1 vinod vinod 1420 Jul  9 09:14 notes.txt

Reading left to right, it is seven fields:

Now zoom into field 1, the ten characters. The first character is the file type from that earlier table:

The remaining nine characters are three groups of rwx — owner, then group, then other (everyone else). In -rw-r--r--: the owner has rw- (read + write), the group has r-- (read only), and other has r-- (read only). A - means “that permission is off.” Occasionally you’ll see a trailing eleventh character after the nine: a . means an SELinux context is present, and a + means the file has extended ACLs. We fully unpack rwx, octal 644/755, and how the kernel actually checks them in the users, groups and permissions lesson (chmod, chown, sudo). For now, just be able to read the line: type, who-can-do-what, links, owner, group, size, when, name.

Where do I find X? — the reverse lookup

The FHS table above answers “what is in this directory?” This one answers the question you actually have at 2am: “I need X — where do I go?” Bookmark it.

The single most useful entry there is /proc/<PID>/. Every running process gets a live directory named after its PID, and it exposes the process’s command line, environment, working directory and open files — as files you can read. That is the “everything is a file” slogan paying off: you debug a live process with cat.

Hands-on lab

Run this on any Linux you have — a cloud VM, WSL, or a throwaway container (docker run -it --rm ubuntu bash or docker run -it --rm rockylinux:9 bash). Nothing here is destructive; we only look. Do every step in order and you’ll build the map in your hands, not just your head.

Step 1 — Establish where you are.

pwd            # where am I in the tree?
whoami         # who am I?
echo "$HOME"   # what does ~ expand to?

You should see a path like /home/vinod (or /root in a root container), your username, and your home path. What just happened: you confirmed your starting point and proved ~ and $HOME are the same place.

Step 2 — Look at the root of the whole tree.

ls -l /

You’ll see the top-level directories from the FHS tour — etc, var, home, usr, proc, dev, boot and friends. What just happened: you looked at the trunk that everything else hangs off. There is only this one.

Step 3 — See the usr-merge for yourself.

ls -ld /bin /sbin /lib

On a modern distro each line starts with l and shows -> usr/.... What just happened: you confirmed /bin is a symlink into /usr, so /bin/ls and /usr/bin/ls are one file.

Step 4 — Absolute vs relative, felt directly.

cd /var                # absolute: works from anywhere
pwd
ls log | head -3       # relative: 'log' means /var/log because we're in /var
cd log                 # relative move down
pwd
cd -                   # bounce back to /var

What just happened: the same text log meant /var/log only because you were standing in /var. That’s the whole absolute-vs-relative idea in four lines.

Step 5 — Practise the special tokens.

cd ~          # home, from anywhere
cd ..         # up to /home
cd /          # to the very top
cd -          # back to /home

What just happened: you drove the tree with ~, .., / and - — no full paths typed.

Step 6 — Read a long listing and decode a line.

cd ~
ls -lah

Pick any line and name its seven fields out loud: type+perms, links, owner, group, size, date, name. What just happened: you turned a wall of text into structured information.

Step 7 — Inspect a single file two ways.

stat /etc/hostname
file /etc/hostname /usr/bin/ls /home

stat shows size, inode, permissions and timestamps; file reports ASCII text, an ELF executable, and a directory respectively. What just happened: you learned about files without opening them, and saw that file inspects content, not the name.

Step 8 — Visit the three “kinds” of directory.

cat /etc/os-release          # /etc = config (plain text)
ls -lt /var/log | head       # /var/log = logs, newest first
cat /proc/cpuinfo | head     # /proc = the kernel describing itself

What just happened: you touched config, logs and the kernel’s virtual view — three of the five branches from the diagram.

Step 9 — Debug a live process through /proc.

echo "my shell PID is $$"          # $$ = this shell's PID
ls /proc/$$/                        # the live directory for THIS process
readlink /proc/$$/cwd               # its current working directory
tr '\0' ' ' < /proc/$$/cmdline; echo # the exact command that started it

What just happened: you read a running process’s working directory and command line straight out of the filesystem — proof that “everything is a file.”

Step 10 — Canonicalise a messy path.

realpath /var/log/../lib/../log     # collapses the .. hops
basename /etc/ssh/sshd_config       # -> sshd_config
dirname  /etc/ssh/sshd_config       # -> /etc/ssh

What just happened: realpath turned a tangled relative path into one true absolute path; basename/dirname split a path into its two useful halves (the exact trick scripts use to find their own location).

Step 11 — Draw the tree (after installing tree).

# install first (pick your family):
#   sudo apt install -y tree      # Debian/Ubuntu
#   sudo dnf install -y tree      # RHEL/Fedora/Rocky
tree -L 1 /
tree -L 2 /etc | head -30

What just happened: you saw the hierarchy as an actual tree, which is the picture the diagram above is describing.

Common mistakes and troubleshooting

Three gotchas bite hardest, so they get extra words.

The relative-path footgun. This is the number-one beginner error and it is dangerous precisely because it is silent. cp report.txt ../backup/ copies to a different place depending on where you’re standing. When the command is rm, that ambiguity gets expensive. ⚠️ Before any rm, and always before rm -rf, run pwd and ls so you know exactly what’s around you — a relative rm -rf * in the wrong directory has ended careers. The habit that saves you: in scripts and anything you’ll run twice, use absolute paths. Deleting and moving safely is the whole subject of the files and directories management lesson.

Editing the wrong copy because of the usr-merge. Since /bin is a symlink to /usr/bin, editing /bin/somescript and /usr/bin/somescript touch the same file — which surprises people who think they’re separate. More importantly, neither is where your custom tools belong: the package manager can overwrite them at any update. Your tools go in /usr/local/bin, which no package owns.

Assuming /tmp is durable storage. /tmp is a scratchpad the system is free to wipe on every reboot, and on many systems it lives in RAM (tmpfs), so it also competes with your memory. It’s perfect for a throwaway file within one command or session, and wrong for anything you expect to find tomorrow. Reach for /var/tmp (survives reboot) or your home directory instead.

Cheat-sheet

Interview and exam questions

Q: Windows has C:\, D:\, E:\. How does Linux expose a second hard disk? A: There are no drive letters. Linux has one tree rooted at /, and a second disk is mounted onto an (empty) directory — say /mnt/data or /data — after which it just looks like a folder in the one tree. findmnt or df -h shows which device is mounted where.

Q: What’s the difference between an absolute and a relative path? A: An absolute path starts with / and is measured from the root, so it means the same thing everywhere. A relative path does not start with / and is measured from your current directory (pwd), so its meaning depends on where you are standing.

Q: Today, what’s the relationship between /bin and /usr/bin? A: On modern distros they are the same directory — /bin is a symlink to /usr/bin (the “usr-merge”). The historical reason for splitting them (a minimal boot set before /usr was mounted) no longer applies.

Q: You wrote a helper script and want it on every user’s PATH, installed by hand. Where do you put it, and why not /usr/bin? A: /usr/local/bin. /usr/bin is owned by the package manager and your file could be overwritten or flagged on the next update; /usr/local is the FHS location reserved for locally-installed software.

Q: For a service like SSH, where do its configuration, its logs, and its persistent state live? A: Config in /etc/ssh/ (e.g. sshd_config), logs in /var/log/ (auth.log on Debian, secure on RHEL) or via journalctl, and any persistent state under /var/lib/.

Q: In drwxr-xr-x, what does each part mean? A: The leading d says it’s a directory. The next nine characters are three rwx triads — owner (rwx), group (r-x), other (r-x) — where a letter means the permission is granted and - means it’s off.

Q: /tmp vs /var/tmp — when do you use each? A: /tmp for short-lived scratch that you don’t mind losing (it’s cleared on reboot, often RAM-backed). /var/tmp for temporary data that must survive a reboot (it’s on disk).

Q: A process with PID 4021 is misbehaving. How do you find its current working directory and the exact command that launched it, without any special tool? A: Read its /proc directory: readlink /proc/4021/cwd for the working directory and tr '\0' ' ' < /proc/4021/cmdline for the command line. /proc/4021/environ shows its environment and /proc/4021/fd/ its open files.

Q: What do cd - and ~ do? A: cd - returns you to the previous directory you were in (and prints it), letting you toggle between two places. ~ expands to your home directory, so cd ~ or just cd takes you home from anywhere.

Q (RHCSA-style): You are in /home/vinod. Using a single relative path, list the contents of /etc. A: From /home/vinod, go up two levels to reach /, then into etc: ls ../../etc. (.. is /home, ../.. is /, so ../../etc is /etc.)

Q (LFCS-style): Print the canonical absolute path that the symlink /bin ultimately points to. A: realpath /bin (or readlink -f /bin) → /usr/bin.

Q: A script runs fine when you launch it in your shell but fails under cron. Give one filesystem-related reason. A: cron starts the job with a different current working directory (usually the user’s home) and a minimal PATH, so any relative path in the script resolves against the wrong location. Fix: use absolute paths (and set PATH explicitly) in anything automated.

Key takeaways

• One tree, no drive letters. Everything hangs off /; a new disk or USB is mounted onto a directory, never given a letter. Always start at / and walk down.
• The layout is a standard (FHS), so it transfers everywhere. /etc is config you edit, /usr is programs you run, /var is data that grows (logs in /var/log, state in /var/lib), /home is your files, and /proc+/dev+/sys are the kernel showing you itself.
• Absolute paths start with / and mean the same everywhere; relative paths depend on pwd. Use absolute paths in scripts and automation to avoid the classic “works in my terminal, breaks in cron” bug.
• Learn the five tokens cold: / (root/separator), . (here), .. (up), ~ (home), - (previous). They make navigation fast.
• ls -l is seven fields: type+permissions, link count, owner, group, size, mtime, name — and the first character names the file type. This is the foundation the permissions lesson builds on.
• Put your things in the right place: custom binaries in /usr/local/bin, config in /etc, vendor apps in /opt; never hand-edit /usr, /bin, /proc or /dev.
• /tmp is disposable, /var/tmp persists. Don’t trust /tmp with anything you want tomorrow.
• /proc/<PID>/ is a live debugger for free — a running process’s cwd, command line, environment and open files are all readable as files.