Linux Filesystem Hierarchy Reference

Key /proc, /sys, /etc, /var paths with purpose and content description.

Searchable Linux FHS directory reference with purpose, typical contents and read/write access notes. Look up any top-level path like /etc, /var, /proc or /sys and learn what belongs there. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

What is the Filesystem Hierarchy Standard?

The FHS is a specification, maintained by the Linux Foundation, that defines the purpose of the top-level directories on a Linux system. It is why /etc holds configuration and /var holds variable data on nearly every distribution, which makes scripts and tools portable across systems.

Know where everything lives on Linux

Every Linux system follows the Filesystem Hierarchy Standard (FHS), which assigns a clear purpose to each top-level directory. Configuration goes in /etc, logs and spools in /var, user programs in /usr, and live kernel state in the virtual /proc and /sys. This reference lets you search any path and instantly see what it is for, what files you will find there, and whether it is safe to write to.

How the FHS organises files

The FHS separates files along two axes: shareable vs unshareable (can it be served to other hosts) and static vs variable (does it change at runtime). That is why read-only program files live under /usr while changing data lives under /var, and why machine-specific configuration sits in /etc.

The virtual filesystems /proc and /sys are special: they hold no real files on disk but expose kernel and device state that you can read, and in some cases write, to tune the running system. Filtering in this reference matches the path, its purpose, and example contents, so searching logs, /var, or config finds the right entry fast.

The directories that trip people up most

/usr vs /usr/local/usr is owned by the package manager; your distribution installs software there. /usr/local is reserved for software you install yourself outside the package manager, so upgrades do not overwrite your additions. A script you compile and install manually belongs in /usr/local/bin, not /usr/bin.

/bin and the usr-merge — Historically, /bin held the minimal set of binaries needed before /usr was mounted (early boot). Most modern distributions like Ubuntu, Fedora, and Debian now make /bin a symlink to /usr/bin (the “usr-merge”), so the distinction is mostly historical. If you are troubleshooting a system where /usr is on a separate partition that does not mount in early boot, the distinction still matters.

/etc vs /var — Both are machine-specific. /etc holds configuration that is almost always static once set (for example, /etc/nginx/nginx.conf). /var holds data that changes at runtime: logs in /var/log, mail spools in /var/spool, package manager databases in /var/lib/dpkg.

/run vs /var/run/run is a tmpfs mounted very early in the boot process. It stores runtime state like PID files and Unix sockets that only need to exist while the system is up. On modern systems /var/run is a symlink to /run.

/opt — Self-contained third-party packages that do not follow the FHS internally (many commercial or proprietary tools) land here. Each package typically gets its own subdirectory like /opt/google/chrome.

Practical scenarios

  • “Where is the config file for my service?” Start in /etc/<servicename>/. For example, SSH is /etc/ssh/sshd_config, nginx is /etc/nginx/, PostgreSQL is often /etc/postgresql/.
  • “Where are the logs?” Almost always /var/log/. System logs are /var/log/syslog or /var/log/messages depending on the distro; journal logs are read via journalctl rather than a file.
  • “Where does my program write its data?” Application state goes in /var/lib/<appname>/. That is where databases, package manager indexes, and container runtimes store their data.
  • “Why can’t I write to /proc?” Most /proc paths are read-only. The tunable kernel parameters are under /proc/sys/ and are best written via sysctl -w key=value (or persistently in /etc/sysctl.d/*.conf), not by echoing directly.

Tips for sysadmins and developers

  • Use /tmp for throwaway scratch files; it is typically a memory-backed tmpfs cleared on reboot. Use /var/tmp only when the data must survive a restart.
  • When packaging software, follow FHS so your files end up in the right places and the package manager can track them cleanly.
  • Running df /usr and df /var separately is useful on servers where they are different partitions — filling /var with logs does not crash /usr and vice versa.
  • lsof +D /var/log shows which processes are writing to the log directory right now — helpful for tracing runaway log producers.