The Filesystem Hierarchy Standard

Everything on a Linux system is mounted under a single root directory, / — there is no equivalent of Windows-style separate drive letters. Different distributions organize this root directory in a highly consistent way, because they all follow the same convention: the Filesystem Hierarchy Standard (FHS). Understanding what each directory under this standard is for is the basis for locating configuration files, installing software, and troubleshooting later on.

The core layout under root

• Directory/

  • Directorybin/ executables for core commands (usually a symlink to /usr/bin on modern distributions)

    • …
  • Directoryboot/ boot loader and kernel-related files

    • …
  • Directorydev/ device files — hardware exposed here as files

    • …
  • Directoryetc/ system-wide configuration files

    • …
  • Directoryhome/ personal directories for regular users

    • …
  • Directorylib/ shared libraries required at runtime

    • …
  • Directoryopt/ optional install location for third-party software

    • …
  • Directoryproc/ a virtual filesystem exposing kernel and process information

    • …
  • Directoryroot/ the root user’s personal directory (not the root directory itself)

    • …
  • Directorytmp/ temporary files, usually cleared on reboot

    • …
  • Directoryusr/ the primary location for user-space programs and resources

    • …
  • Directoryvar/ frequently-changing data, such as logs and caches

    • …

A few directories worth distinguishing

/etc vs. configuration under /home: system-wide configuration (affecting all users) lives under /etc — network settings, service configuration, and so on. Per-user configuration (affecting only the current user) lives under that user’s /home/<username> directory, usually as dotfiles such as .bashrc or .gitconfig. The two operate at different scopes, so troubleshooting a configuration issue starts with confirming which layer was actually changed.

/bin, /usr/bin, and /usr/local/bin: all three hold executables, but differ by origin. /usr/bin holds programs installed by the distribution’s package manager. /usr/local/bin holds programs installed outside the package manager — compiled manually or downloaded separately. /bin on most modern distributions is simply a symlink to /usr/bin, kept only for backward compatibility. This is also why tools built and installed by hand typically end up in /usr/local/bin rather than /usr/bin.

/proc: this is a virtual filesystem — the files inside it don’t correspond to data actually stored on disk, but are generated dynamically by the kernel at runtime to reflect the current system state. /proc/cpuinfo, for example, shows CPU details, and /proc/<pid>/ holds runtime information for the process with that PID. This directory comes up frequently when inspecting or diagnosing system state.

Run man hier for the full specification

Running man hier shows the current system’s full description of the FHS directly in the terminal, covering directories not listed here — a more authoritative and offline-available reference than searching online.

Why this layout is worth memorizing

Later work — installing software, configuring services, writing scripts — will almost inevitably touch this directory structure. Figuring out why a command “installed but won’t run,” for instance, often comes down to it having landed in a directory not covered by the PATH environment variable; figuring out why a service’s configuration change had no effect often starts with confirming whether the correct configuration file, at the correct layer, was actually edited. Building an overall mental model of this hierarchy meaningfully cuts down on blind trial-and-error during later troubleshooting.

Why this matters

This topic is an important part of building a reliable Linux development workflow. Understanding it clearly will make later tasks easier, because it reduces guesswork and helps you recognize when a step is missing or misapplied.

Practical next steps

• Try the commands or configuration shown here in a safe test environment.
• Compare how the concepts apply across different distributions or tools.
• Keep a short note of what worked and what failed so you can diagnose future problems faster.
• Revisit the related article in the series to deepen the connections between topics.

Common pitfalls

• Skipping verification steps and assuming the system is configured correctly.
• Copying commands without adapting paths, package names, or tool versions for your environment.
• Treating this topic as an isolated tip rather than part of a larger workflow.