Linux Filesystem Hierarchy

What you will be able to do

• Explain the operational roles of the main Linux filesystem directories.
• Choose a read-only command that answers a specific path, mount, ownership, or space question.
• Interpret filesystem output as evidence before changing configuration or removing data.
• Apply an inspect, change, verify, and recover workflow to a realistic filesystem task.

01

Map the path before changing it

Linux presents one directory tree, but parts of that tree can live on different filesystems and follow different ownership rules. Before changing a file, identify your current directory with `pwd`, your effective identity with `id`, and the target with an absolute path.

Use `stat /path/to/item` to inspect the target itself. When ownership or permissions may fail at a parent directory, `namei -l /path/to/item` follows each pathname component and shows where access changes.

For example, an operator investigating a log path might record:

$ namei -l /var/log/nginx/access.log
f: /var/log/nginx/access.log
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxrwxr-x root syslog log
drwxr-x--- root adm nginx
-rw-r----- www-data adm access.log

Membership in `adm` may permit reading the file, but traversing the `nginx` directory is also required.

Check every path component before changing permissions; widening only the file mode can miss the real failure and expose the log unnecessarily.

If storage or mount options matter, run `findmnt -T /path/to/item`. It reports the mounted filesystem that contains the path, which is more useful than assuming the whole directory tree shares one device.

02

Separate the root directory from the root account

The root directory (`/`) is the top of the filesystem tree. An absolute path begins there, so `/etc/hosts` identifies the same target regardless of the shell's current directory. A relative path such as `notes/ticket.txt` starts from the directory reported by `pwd`.

The directory `/root` is different: it is normally the home directory of the root user. Treating `/` and `/root` as interchangeable can send a command to a much broader part of the system than intended.

For a handoff or a privileged change, record the absolute target. This removes dependence on another operator's working directory and makes the verification command reproducible.

03

Inspect host configuration under /etc

The `/etc` hierarchy contains host-specific system configuration. Before editing a file there, identify which service or program reads it, inspect its current metadata, and use that program's validation command when one exists.

A safe configuration change has a narrow target and a recovery copy with permissions protected. Use elevated access only for the write, not for every discovery command in the session.

After the edit, validate the file and confirm the affected service behavior. A text change in `/etc` is not complete merely because the editor saved successfully.

04

Keep user work and ownership clear under /home

Regular user home directories commonly live below `/home`. They hold personal configuration and working data, but the exact home path should come from account information rather than from a guessed username.

After copying a shared file into a user's home, inspect its owner, group, and mode with `stat` or `namei -l`. A file can exist in the expected directory and still be unusable because it remained owned by another account.

A home directory is not a backup. Moving important work into `/home` organizes ownership; it does not establish retention, versioning, or recovery.

05

Distinguish durable variable data from runtime state

The `/var` hierarchy holds data that changes during normal operation. Logs commonly appear below `/var/log`, while applications can keep durable service state below locations such as `/var/lib`. Deleting either without identifying the owning service can remove evidence or damage application state.

The `/run` hierarchy describes runtime state for the current boot, including files used by active services. That lifetime is different from durable state in `/var`.

When `/var` is growing, first use `df -h /var` to check the containing filesystem. Then narrow the directory usage with a read-only command such as `du -xhd1 /var`, subject to the permissions available on that host.

06

Create temporary data without treating it as durable

The `/tmp` hierarchy is intended for temporary files, and local cleanup policy may remove its contents. Use `mktemp` when a script needs a unique temporary file or directory instead of inventing a predictable name.

The Filesystem Hierarchy Standard gives `/var/tmp` a longer lifetime across reboots than `/tmp`, but it is still temporary storage and can be removed by site policy. Neither location replaces an application data directory or backup.

After the task, remove only the temporary path created for that run. Record the generated path when cleanup or another process depends on it.

$ workdir=$(mktemp -d)
$ printf '%s\n' "$workdir"
/tmp/tmp.wS3KpA8c2N
$ test -d "$workdir" && printf 'ready\n'
ready

`mktemp -d` returned a unique directory for this run, and the read-only test confirmed that the exact path exists. The generated suffix will differ every time.

Capture the generated temporary path and later clean up only that path; never guess a shared name or treat `/tmp` as durable storage.

07

Recognize software and mount boundaries

The `/usr` hierarchy contains shareable, generally read-only system data, including many commands and libraries supplied by the operating system. Optional add-on packages may use `/opt` instead. Locally managed software may follow a different approved policy, so inspect the package or deployment owner before replacing files.

A directory name does not prove which device stores it. Separate filesystems can be mounted at paths such as `/home`, `/var`, or an application directory. `findmnt -T` exposes that boundary for the exact target.

This matters during capacity incidents and recovery. Free space, mount options, and backup scope can differ even though every path appears under the same tree.

08

Investigate space without deleting evidence

A full-filesystem alert should begin with scope. `df -h /var/log` reports space for the filesystem containing that path, while `du` estimates space used by files below a selected directory. They answer related but different questions.

$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        40G   38G  1.1G  98% /
$ sudo du -xhd1 /var 2>/dev/null | sort -h
120M    /var/tmp
1.8G    /var/lib
5.6G    /var/log
7.7G    /var

`df` reports far more allocated space than `du` can account for below `/var`.

Treat the mismatch as evidence to check other paths, inaccessible content, mount boundaries, or deleted-but-open files; it is not evidence that `/var/log` should be purged immediately.

Use `findmnt -T /var/log` when the mount boundary is unclear, then narrow the largest directory that your access permits. Do not start with a recursive delete or an unbounded search across `/`.

Once the owner is known, use the service's retention, rotation, cache, or cleanup procedure. Repeat the same `df` and `du` observations afterward so the recorded result proves both recovered capacity and the scope of the change.

09

Build a filesystem evidence checklist before changing state

The root directory (`/`) begins the filesystem tree, while `/root` is normally the root user's home. Absolute paths make a target independent of the current directory.

Use `/etc` for host configuration, `/home` for regular user homes, `/usr` for shareable system data, and `/opt` for optional add-on packages according to the host's policy.

Use `/var` for changing logs and durable service state, and distinguish it from current-boot runtime state under `/run`. Identify the owning service before removing either.

Treat `/tmp` and `/var/tmp` as temporary. Use `mktemp` for unique working paths, and move durable results to an appropriate data location.

Before a change, use `pwd`, `id`, `stat`, `namei -l`, `findmnt -T`, `df`, and `du` only as the question requires. Repeat the relevant observation to verify the outcome.