Linux Filesystem Hierarchy¶

Overview¶

On Linux, everything is a file — regular files, directories, devices, sockets, and even kernel interfaces. The Filesystem Hierarchy Standard (FHS) defines where each type of data lives so administrators, applications, and automation tools can predict paths across distributions. When nginx fails to start, you check /etc/nginx/; when disks fill up, you investigate /var/log/ and /var/lib/; when a user's shell misbehaves, you read ~/.bashrc under /home/.

Without FHS literacy, you waste hours searching for configs, accidentally edit the wrong copy of a file, or store application data in paths that break during upgrades. DevOps engineers live in this tree daily — Docker volumes map to /var/lib/docker, Kubernetes mounts host paths, Ansible templates target /etc/, and log agents tail /var/log/. This tutorial maps the entire hierarchy with real examples you will encounter in production.

This is Tutorial 2 in Module 1: Foundations of the REBASH Academy Linux series. It follows our documentation standards with theory, hands-on labs, and interview preparation.

Prerequisites¶

• Completed Introduction to Linux or equivalent familiarity with Linux basics
• Terminal access to a Linux VM, WSL2 instance, or cloud server
• Ability to run read-only commands (ls, cat, find) — some steps use sudo optionally
• Basic understanding that / is the root of the entire filesystem tree

Learning Objectives¶

By the end of this tutorial, you will be able to:

• Explain the purpose of the FHS and why standardized paths matter in multi-server environments
• Identify the role of every major top-level directory under /
• Distinguish between static config (/etc), variable data (/var), and executable programs (/usr/bin)
• Navigate virtual filesystems (/proc, /sys, /dev) and understand what they expose
• Predict where logs, packages, user data, and temporary files are stored on any FHS-compliant distro
• Use CLI tools to explore and audit filesystem layout on an unfamiliar server

Architecture Diagram¶

The diagram below shows the FHS tree with the most important directories and typical contents. Arrows indicate "contains" relationships — not symlinks.

flowchart TD
    ROOT["/  Root filesystem"]

    ROOT --> etc["/etc<br/>Static configuration"]
    ROOT --> var["/var<br/>Variable data"]
    ROOT --> usr["/usr<br/>User programs & read-only data"]
    ROOT --> home["/home<br/>User home directories"]
    ROOT --> root["/root<br/>Superuser home"]
    ROOT --> tmp["/tmp<br/>World-writable temp"]
    ROOT --> opt["/opt<br/>Third-party add-ons"]
    ROOT --> boot["/boot<br/>Kernel & initramfs"]
    ROOT --> dev["/dev<br/>Device nodes"]
    ROOT --> proc["/proc<br/>Process & kernel info"]
    ROOT --> sys["/sys<br/>Kernel object hierarchy"]
    ROOT --> run["/run<br/>Runtime state since boot"]
    ROOT --> srv["/srv<br/>Service data"]

    etc --> etc_nginx["nginx/nginx.conf"]
    etc --> etc_systemd["systemd/system/"]
    var --> var_log["log/syslog"]
    var --> var_lib["lib/docker/"]
    usr --> usr_bin["bin/ — ls, grep, python3"]
    usr --> usr_lib["lib/ — shared libraries"]
    home --> home_user["ubuntu/ .bashrc projects/"]
    boot --> boot_vmlinuz["vmlinuz-6.8.0"]

Theory¶

What Is the FHS?¶

The Filesystem Hierarchy Standard, maintained by the Linux Foundation, specifies directory names, locations, and minimum contents for Linux and Unix-like systems. FHS ensures that /etc/passwd means "user account database" whether you are on Ubuntu, RHEL, or Debian. Configuration management tools, monitoring agents, and security scanners rely on these conventions.

FHS defines three logical categories:

The Root Directory /¶

/ is the mount point for the root filesystem. All other paths are descendants. On a typical server, / is a separate partition (often 20–50 GB). Filling / breaks the entire system — which is why logs and databases live under /var, not /.

/bin and /sbin — Essential Binaries¶

These directories hold binaries required for single-user mode and early boot before /usr is mounted. On modern distros, /bin and /sbin are often symlinks to /usr/bin and /usr/sbin (the merged /usr layout).

Verify on your system: ls -l /bin — if it shows bin -> usr/bin, you have the merged layout.

/boot — Kernel and Bootloader Files¶

Contains files needed to boot the kernel. Typically a separate small partition (512 MB–1 GB).

Never store arbitrary files in /boot — a full /boot partition prevents kernel updates from installing.

/dev — Device Files¶

Hardware and pseudo-devices appear as special files:

Modern systems use udev (managed by systemd) to create device nodes dynamically at boot.

/etc — Host-Specific Configuration¶

"etc" = editable text configuration. This is the most visited directory for sysadmins. Files here apply to this machine only — they are not shared across /usr.

Rule of thumb: If you are configuring how a service behaves on this server, the file is almost always under /etc/.

/home — User Home Directories¶

Each regular user gets a subdirectory: /home/alice, /home/bob. User-owned files, SSH keys (~/.ssh/id_ed25519), shell configs (~/.bashrc), and project code live here. Home directories are often on separate partitions or NFS mounts in enterprises.

The tilde ~ expands to your home directory: cd ~ → /home/youruser.

/root — Superuser Home¶

The home directory for the root account (/root), not /home/root. Separated so root can log in even if /home is corrupted or unmounted. Directories like /root/.ssh/ store root's SSH keys.

/lib, /lib64 — Essential Shared Libraries¶

Kernel modules and shared libraries required for /bin and /sbin binaries to run. Like /bin, often symlinked to /usr/lib on merged-/usr systems. Contains critical files such as /lib/x86_64-linux-gnu/libc.so.6 (the C standard library).

/media and /mnt — Mount Points¶

In servers, you will mount volumes under /mnt or custom paths like /data.

/opt — Optional Third-Party Software¶

Self-contained packages from vendors install here: /opt/google/chrome, /opt/splunk/, /opt/aws/amazon-cloudwatch-agent/. Each package typically has its own bin/, lib/, and config subtree. Keeps vendor software isolated from distro packages in /usr.

/proc — Process and Kernel Information (Virtual)¶

A virtual filesystem — no disk space used. The kernel exposes runtime information as readable files:

Tools like top, ps, and free read /proc under the hood.

/run — Runtime Variable Data¶

Created by systemd at boot; holds PID files, sockets, and state that must persist across early boot but not reboots. Examples: /run/sshd.pid, /run/systemd/system/, /run/udev/data/. Replaces much of what historically lived in /var/run (now typically a symlink to /run).

/srv — Service Data¶

Data served by this system — site content for web servers, Git repos, FTP roots. Example: /srv/www/example.com/public_html/. Less commonly used today (many teams prefer /var/www or container volumes), but FHS-compliant and seen in exam questions.

/sys — Kernel Object Hierarchy (Virtual)¶

Another virtual filesystem (sysfs). Exposes kernel data structures about devices, drivers, and kernel subsystems. Used by udev and low-level tooling. Example: /sys/class/net/eth0/address shows the MAC address.

/tmp — Temporary Files¶

World-writable with sticky bit (drwxrwxrwt). Any user can create files; only the owner (or root) can delete their own. Cleared on reboot on many systems (or by systemd-tmpfiles). Use for scratch space — never store secrets here.

/usr — User Programs and Read-Only Data¶

The largest directory on most systems. Contains the bulk of installed software:

Distinction: /usr is often mounted read-only in hardened systems. /etc holds local overrides; /usr holds packaged software.

/var — Variable Data¶

Files that change in size and content during normal operation:

Production alert: /var filling up stops logging, breaks databases, and can crash services. Monitor disk usage here aggressively.

Hands-on Lab¶

Step 1 – List top-level directories with types and sizes¶

Command:

ls -la /
df -h /

Explanation: ls -la / shows every top-level entry including symlinks (note bin -> usr/bin). df -h / shows total disk usage of the root filesystem — context for why /var separation matters.

Expected output:

lrwxrwxrwx   1 root root     7 ... bin -> usr/bin
drwxr-xr-x   4 root root  4096 ... boot
drwxr-xr-x  18 root root  3880 ... dev
drwxr-xr-x  95 root root  4096 ... etc
...
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        30G  4.2G   24G  15% /

Step 2 – Explore static configuration in /etc¶

Command:

ls /etc | head -20
cat /etc/hosts
cat /etc/os-release | head -5

Explanation: /etc contains hundreds of config files and directories. hosts and os-release are safe to read on any system and demonstrate host-specific vs standardized config.

Expected output:

adduser.conf
alternatives
apt
bash.bashrc
...
127.0.0.1 localhost
127.0.1.1 ip-172-31-10-42

PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
...

Step 3 – Inspect variable data and logs in /var¶

Command:

sudo ls -lah /var/log | head -12
du -sh /var/log /var/lib /var/cache 2>/dev/null

Explanation: Logs and application state live under /var. Disk usage here grows unbounded without log rotation — a top cause of production outages.

Expected output:

drwxr-xr-x  11 root syslog 4.0K ... .
-rw-r-----   1 syslog adm    45K ... auth.log
-rw-r-----   1 syslog adm   128K ... syslog
...
120M    /var/log
890M    /var/lib
156M    /var/cache

Sizes vary widely by system age and installed services.

Step 4 – Count installed user programs in /usr/bin¶

Command:

ls /usr/bin | wc -l
which python3 nginx docker 2>/dev/null

Explanation: /usr/bin holds the command-line tools you use daily. which searches $PATH — typically including /usr/bin and /usr/local/bin.

Expected output:

1847
/usr/bin/python3

Some commands may return nothing if the package is not installed — that is expected.

Step 5 – Read kernel and process info from /proc¶

Command:

head -5 /proc/cpuinfo
head -3 /proc/meminfo
cat /proc/loadavg
echo "My PID: $$ — status file: /proc/$$/status"
head -5 /proc/$$/status

Explanation: /proc is a live view into the kernel. Reading these files costs nothing and works in scripts when external tools are unavailable.

Expected output:

processor       : 0
vendor_id       : GenuineIntel
model name      : Intel(R) Xeon(R) CPU ...
MemTotal:        8123456 kB
MemFree:         5234567 kB
0.08 0.04 0.01 1/234 45678
My PID: 45678 — status file: /proc/45678/status
Name:   bash
State:  S (sleeping)
Pid:    45678

Step 6 – Examine device nodes in /dev¶

Command:

ls -l /dev/null /dev/zero /dev/random
lsblk

Explanation: Special files in /dev represent devices. lsblk shows block device hierarchy — mapping /dev/sda1 to mount points like /.

Expected output:

crw-rw-rw- 1 root root 1, 3 ... /dev/null
crw-rw-rw- 1 root root 1, 5 ... /dev/zero
crw-rw-rw- 1 root root 1, 8 ... /dev/random
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    0   30G  0 disk
└─sda1   8:1    0   30G  0 part /

Step 7 – Compare /tmp and /var/tmp permissions¶

Command:

ls -ld /tmp /var/tmp

Explanation: Both hold temporary files, but /tmp is cleared on reboot while /var/tmp persists. The sticky bit (t in drwxrwxrwt) prevents users from deleting each other's files.

Expected output:

drwxrwxrwt  12 root root 4096 ... /tmp
drwxrwxrwt   8 root root 4096 ... /var/tmp

The t at the end of the permission string is the sticky bit.

Step 8 – Trace a config file to its package (Debian/Ubuntu)¶

Command:

dpkg -S /etc/nginx/nginx.conf 2>/dev/null || \
  rpm -qf /etc/ssh/sshd_config 2>/dev/null || \
  echo "Install nginx or use an existing /etc file for this demo"
ls -la /etc/systemd/system/

Explanation: Knowing which package owns a file prevents accidental manual edits that get overwritten on upgrade. /etc/systemd/system/ holds admin-created unit overrides — a path you will use constantly in DevOps.

Expected output:

nginx: /etc/nginx/nginx.conf
total 16
drwxr-xr-x  2 root root 4096 ... .
lrwxrwxrwx  1 root root   44 ... dbus-org.freedesktop.resolve1.service -> ...

Commands¶

Code¶

FHS audit script for onboarding new servers¶

Run this when inheriting an undocumented server. It reports mount points, largest /var consumers, and symlink layout.

#!/usr/bin/env bash
# fhs-audit.sh — summarize filesystem layout for runbook documentation
set -euo pipefail

section() { printf '\n=== %s ===\n' "$1"; }

section "Root Filesystem Usage"
df -h / /var /home /boot 2>/dev/null || df -h /

section "Top-Level Directories"
ls -la / | awk '{print $1, $9, $10, $11}'

section "Merged /usr Layout?"
for link in /bin /sbin /lib /lib64; do
  if [[ -L "$link" ]]; then
    echo "$link -> $(readlink -f "$link")"
  else
    echo "$link is a real directory (pre-merged layout)"
  fi
done

section "Largest Consumers in /var (top 5)"
du -sh /var/* 2>/dev/null | sort -rh | head -5

section "Critical Config Files Present"
for f in /etc/fstab /etc/hosts /etc/os-release /etc/passwd; do
  [[ -e "$f" ]] && echo "OK  $f" || echo "MISSING  $f"
done

section "Virtual Filesystems Mounted"
mount -t proc,sysfs,tmpfs 2>/dev/null | awk '{print $1, $3}' || \
  grep -E '^(proc|sysfs)' /proc/mounts | awk '{print $2, $3}'

Find misconfigured log paths filling root¶

#!/usr/bin/env bash
# find-large-logs.sh — locate log files over 100MB under /var/log
find /var/log -type f -size +100M -exec ls -lh {} \; 2>/dev/null | \
  awk '{print $5, $9}' | sort -rh

Common Mistakes¶

Best Practices¶

Troubleshooting¶

Summary¶

• FHS standardizes directory purposes so configs, logs, programs, and user data have predictable locations
• /etc = static host-specific configuration; /var = growing logs and application state; /usr = packaged programs and libraries
• /proc and /sys are virtual filesystems exposing live kernel and process data
• /dev contains device nodes; /boot holds kernels — keep it small and monitored
• /tmp is ephemeral and world-writable; /var/tmp persists across reboots
• Production reliability depends on separating /var from / and rotating logs under /var/log

Interview Questions¶

1. What is the FHS, and why does it matter for DevOps automation?
2. What is the difference between /etc, /usr, and /var?
3. Explain the purpose of /proc and name three useful files inside it.
4. Why should application logs be stored under /var/log rather than /opt or /home?
5. What is the sticky bit on /tmp, and why is it important?
6. What is the difference between /bin and /usr/bin on a modern Ubuntu system?
7. Where would you look for systemd service unit overrides?
8. What lives in /boot, and what happens if that partition fills up?
9. Explain the difference between /mnt and /media.
10. How do you determine which package installed a file at /etc/nginx/nginx.conf?

Related Tutorials¶

• Linux – Category Overview
• Introduction to Linux (previous in Module 1)
• Essential Linux Commands (next in Module 1)
• File Permissions and Ownership
• Learning Paths – DevOps Engineer

References¶

• Filesystem Hierarchy Standard (FHS 3.0) — official specification
• Linux man pages — hier(7) — overview of filesystem hierarchy
• systemd file hierarchy — systemd's perspective on FHS
• Linux man pages online
• REBASH Academy – Linux Overview