Linux Filesystem Hierarchy

What you will be able to do

• Explain the five core decisions involved in linux filesystem hierarchy.
• Choose the narrow Linux command or method that matches a stated operational need.
• Interpret command output as evidence before deciding whether to change system state.
• Apply an observe, act, verify, and recover workflow to a realistic Linux task.

01

Build the Operating Model

Read the single Linux directory tree and distinguish locations for configuration, user data, changing state, programs, and temporary files.

Reliable Linux work separates observation, decision, action, and verification. That order keeps a command from becoming a guess and makes each result useful for the next decision.

Begin in a disposable lab or a recoverable environment. Record the active user, working directory, target, and baseline output before any command that can change system state.

02

Root directory

The slash directory is the top of the Linux filesystem tree and the starting point for absolute paths. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Use an absolute path from `/` when the target must remain clear regardless of the current directory. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: root slash is not the root user's home. You should be able to verify this result: one unambiguous path from the tree root.

03

System configuration

The `/etc` hierarchy contains host-specific system configuration rather than ordinary user documents. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Inspect configuration files before editing and preserve a recoverable copy when a change can affect services. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: use elevated writes only when required. You should be able to verify this result: configuration located under the system hierarchy.

04

User home data

The `/home` hierarchy normally contains home directories and personal working data for regular users. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Keep user-owned projects under the appropriate home directory and confirm ownership after moving shared files. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: a home directory is not a system backup. You should be able to verify this result: personal data separated by user home.

05

Variable state

The `/var` hierarchy holds data expected to change during normal operation, including logs and service state. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Inspect the relevant subdirectory and its growth before deleting or rotating changing system data. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: do not remove active state without service context. You should be able to verify this result: changing application or system state located.

06

Temporary data

The `/tmp` hierarchy provides space for temporary files that should not be treated as durable storage. This distinction helps identify the smallest relevant part of the system before a change is attempted.

Use unique temporary names, restrict permissions when data is sensitive, and move durable results elsewhere. Keep the command, target, and visible result together so another person can reproduce the reasoning.

The safety boundary is clear: temporary content may disappear between sessions. You should be able to verify this result: short-lived working data kept separately.

07

Apply One Controlled Change

Start from the read-only commands that reveal identity, scope, and current state. Write the expected result before entering a modifying command, including which files, processes, accounts, or connections may be affected.

Make one narrow change and stop. If the output reports an error or an unexpected target, preserve that evidence and return to inspection instead of adding unrelated commands.

Repeat the original observation after the action. A successful command status is useful, but the real completion signal is the intended state plus the absence of an unintended side effect.

08

Complete the Evidence Loop

A good terminal record answers four questions: what was observed, why one action was selected, exactly what changed, and how the result was verified. A screenshot without command context answers fewer questions than saved text output.

Test both the expected success and one safe failure condition. This confirms that the procedure recognizes a wrong path, missing permission, invalid input, stopped service, or unavailable endpoint instead of silently continuing.

Finish by restoring the lab baseline when the task was experimental. For an operational change, record the final state and the reversal step so later work begins from a known boundary.

09

Recap Before Practice and Prove

The first decision concerns root directory. Use an absolute path from `/` when the target must remain clear regardless of the current directory.

The second decision concerns system configuration. Inspect configuration files before editing and preserve a recoverable copy when a change can affect services.

The third decision concerns user home data. Keep user-owned projects under the appropriate home directory and confirm ownership after moving shared files.

The fourth decision concerns variable state. Inspect the relevant subdirectory and its growth before deleting or rotating changing system data.

The final decision concerns temporary data. Use unique temporary names, restrict permissions when data is sensitive, and move durable results elsewhere. Keep the final output as the baseline for the next task.