4.3 The Filesystem Hierarchy Standard

One Tree, Predictable Places

Linux has no drive letters. Every storage device is mounted somewhere inside a single directory tree whose top is the root directory, /. The Filesystem Hierarchy Standard (FHS) defines what each top-level directory is for, so that an administrator moving between Debian, Kali, Fedora, or a server appliance finds configuration, logs, and binaries in the same places. Kali is explicitly FHS-compliant, and the KLCP exam tests the purpose of individual directories directly.

The Core Directories

Virtual Filesystems Deserve Special Attention

/proc and /sys exist only in memory — the kernel fabricates their contents on read, and writing to some entries tunes the kernel live (for example echo 1 > /proc/sys/net/ipv4/ip_forward enables IP forwarding, a classic pivoting step). They consume no disk space, which you can confirm with du: the exam likes asking why /proc reports strange sizes.

The /usr Merge in Modern Debian and Kali

Historically, /bin, /sbin, /lib, and /lib64 held the bare minimum needed to boot before /usr (possibly on another disk) was mounted. Modern systems assemble an initramfs (initial RAM filesystem) early in boot, so that split no longer serves a purpose. Current Debian — and therefore current Kali — performs the /usr merge: those four top-level directories are now symbolic links into /usr:

$ ls -ld /bin /sbin /lib /lib64
lrwxrwxrwx 1 root root 7 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 /lib -> usr/lib
lrwxrwxrwx 1 root root 9 /lib64 -> usr/lib64
lrwxrwxrwx 1 root root 8 /sbin -> usr/sbin

Practical consequences for the exam: a tool documented as living in /bin is physically stored in /usr/bin, both paths resolve to the same file, and scripts with a #!/bin/sh shebang keep working untouched. The old distinction between /bin and /usr/bin is effectively gone on a fresh Kali install.

Using the Layout in Practice

Knowing the FHS tells you where to look before you ever run a search. Hunting a service's settings? Start in /etc. Suspect a rootkit hid files? Check world-writable /tmp and /dev/shm. Need the kernel or want to back up boot configuration? Everything static is in /boot. Disk filling up? /var/log and /var/cache grow continuously, while /home holds user data. Triaging an odd process? Read /proc/<pid>/cmdline and /proc/<pid>/exe. Because Kali follows the FHS, lessons learned on any compliant distribution transfer directly — and because the exam is written from the Kali Linux Revealed book, directory-purpose matching questions (for example, 'where do variable data and logs live?' → /var) are common.

Looking Inside /var and /usr

Two directories reward a closer look because the exam tests their subdivisions. Under /var, the split is by lifecycle: /var/log holds log files (rotated by logrotate so disks do not fill), /var/cache holds data programs can regenerate or re-download if deleted, /var/lib holds persistent application state such as the dpkg database in /var/lib/dpkg that APT consults for every install, /var/tmp holds temporary files that must survive reboots (unlike /tmp), and /var/spool queues jobs such as mail and print tasks. Under /usr, the split is by content type: /usr/bin and /usr/sbin hold executables, /usr/lib holds libraries and architecture-dependent files, /usr/share holds architecture-independent data such as documentation, icons, and wordlists — on Kali this includes the famous /usr/share/wordlists, which ships rockyou.txt.gz (run sudo gunzip /usr/share/wordlists/rockyou.txt.gz before first use) — and /usr/local is reserved for software the administrator compiles and installs manually, so package managers never overwrite it. That last point is a favorite exam trap: locally compiled tools belong in /usr/local, not /opt (which is for self-contained third-party bundles) and not directly in /usr/bin (which the package manager owns).