The File Hierarchy Standard (FHS) is a set of guiding principles for management of files on Linux systems. The standard is maintained by a working group of the Linux Foundation.
A Little History
The File Hierarchy Standard was first released as Filesystem Standard (FSSTND) in 1994. The newer FHS name was adopted on version 2.0 in 1997. The current version is 3.0, having been announced on June 3, 2015.
FHS is a widely-adopted standard, in use by the majority of Linux Distributions, with a few notable exceptions.
Summary of the Structure
/root of the filesystem
/binessential binaries needed in single-user mode
/bootbootloader and it’s dependencies
/devdirectory for special “device” files, representing physical or logical devices
/homeuser home directories
/mediamounted removable media (CDs, USB drives)
/mnttemporary mount points - programs should not depend on these mounts
/opt“add-on” application packages - more on this below
/rootroot user’s home directory
/runrun-time variable data - cleared on boot
/srvservice data (ftp, webserver)
/usrsubdivision of the filesystem used in multi-user mode
/usr/includeheaders referenced by source files
/usr/localused for “locally-installed” software - may contain a hierarchy mirroring
/usr/sharestatic data files and documentation
/varvariable data that is typically not shareable between systems
/var/accountdata from linux process accounting
/var/cachecomputed data, or fetched from other systems - should be safe to delete
/var/crashsystem crash dumps
/var/gamesvariable game data like game saves
/var/logsystem and application logs
/var/optdata for “add-on” applications
/run- in fact this is often a symlink to
/var/spoolapplication “spool” data (print jobs, logrotate spool)
/var/tmptemporary data that is preserved between reboots
/procvirtual filesystem used by Linux kernel to expose process information
/sysvirtual filesystem used by Linux kernel to expose driver and device info
Why Do We Need a Standard?
Having a standard supports an orderly software packaging system. If software packages had no guidance about where to place files, it can lead to file placement conflicts, build errors from dependencies not being where they’re expected to be, etc.
A standard also promotes a software environment friendly to administrators. It is significantly easier to diagnose and solve problems with a system if the file and directory layout is familiar.
What About Software That Wasn’t Designed for FHS?
The standard has some provisions for software that wasn’t built to support the standard directory layout. Software in
/opt is “add-on” software, and is - to some degree - exempted from the layout rules.
The two examples I’ve most commonly seen taking advantage of
/opt are Java and Python applications.
Java, because the application often comes with many source library files and other supporting content that was laid-out for systems that do not use FHS (ie. Windows).
I’ve commonly seen Python applications installed into
/opt when they are using a Python Virtual Environment (Virtualenv), which may include it’s own version of Python, the Pip package manager, and versions of libraries which may differ from those installed “globally” on the system.
Command binaries installed in
/opt are often added to the standard search path for binaries (the
$PATH environment variable) by adding a symbolic link to
/usr/local/bin. I’m not certain that this is correct according to the standard, but it generally achieves the intended effect, and is a fairly common practice.