The Linux Filesystem Hierarchy Standard(FHS) is a specification that spells out where files should be placed based on their nature or function. An understanding of the FHS is like peeling away a veil: the system moves from being a black box to something more approachable.
The goal of this piece is to make it easy for Linux users and enthusiasts to derive more utility from the filesystem by being able to predict the most likely location for various files.

FHS 3.0

The FHS, now in its third iteration, is available online at the Linux Foundation. The last revision was in 2015, (11 years ago). Though you might find it dated and out of sync with your current system, it forms the basis of the modern system and provides the historical foundations and context needed to understand modern systems. This section is an overview of the spec. Later on, we focus on modifications and adaptations in modern day systems.

Static vs Variable; Shareable vs Unshareable

The specification defines different categories of files. Understanding these categories is important for seeing the reasoning behind the standard.

Static - Static files do not change unless they are explicitly altered by the administrator

Variable - Variable files can change as the system is running and without the admin’s explicit knowledge.

Shareable - Shareable files can be used by more than one system simultaneously. Changes to a shareable file have the same effect across board.

Unshareable - Unshareable files are localized to a single system. Changes to them are supposed to affect just the local system.

I like the way the spec puts it;

Static files include … files that cannot be changed without the system administrator’s intervention. Variable files are files that are not static.

Shareable files are those that can be stored on one host and used on others. Unshareable files are those that are not shareable.

The Actual Spec

With that out of the way, we can dive into the meat of the spec. Being a spec on a typical Linux filesystem, it starts with /, the root of the file hierarchy, and the root filesystem.

  • / - The root directory (/) is the base of the Linux filesystem. At a minimum, it must contain everything required to boot up, restore and repair a Linux system laid out in a defined set of top-level directories such as /bin, /etc, and /boot. Some of these directories may be mount points for other filesystems. For example, /boot can be stored on a separate partition, but the /boot directory must still exist under /. This means that, under FHS, a valid root filesystem must include the expected directory structure. A filesystem that lacks these directories may still mount at /, but it will not be FHS-compliant. / may have other directories aside from those specified in the FHS, since the FHS only prescribes directories that should exist at a minimum, and not a complete list.

  • /boot - It contains static files that are required for booting a system, including the kernel and some bootloader files. The baseline criterion is that a the files in /boot should be required during the bootup process.

  • /bin - /bin contains a minimal set of static binaries that the system needs to startup and function. They are binaries that should be available even if no other filesystems are mounted. Another word for ‘minimal set’ is ‘essential’.

  • /sbin - /sbin also contains a minimal set of binaries needed during normal system operation. The difference between /bin and /sbin is that the binaries in /sbin should not be run without explicitly knowing that an admin-level task is about to be performed. For example, if you want to modify the list of devices mounted on a system, it shouldn’t be inadvertent. The user should know that he is about to perform an admin-level task. The binaries in /sbin are meant to be used by administrators, as opposed to regular users. They should also be available when no other filesystems are mounted.

  • /lib - The files in /lib are the files needed by the binaries in /sbin and /bin to run. Also known as libraries, they are not meant to be run directly by users. While not specified in the spec, some multilib distributions may attempt to separate 32-bit libraries from 64-bit ones using directories such as /lib64 or /lib32 in addition to /lib.

  • /usr - The /usr directory contains nonessential, static, shareable, read-only files. Essentially, binaries and libraries that you can afford to have outside your root filesystem. Since they are nonessential, /usr can be mounted on a non-root filesystem and mounted late in the boot sequence. The binaries in /usr and their libraries are also organized under /bin, /sbin and /lib, just like the ones directly under /. Because of this /usr is also referred to as ‘a secondary hierarchy’. The spec also requires the presence of other subdirectories such as /usr/local and /usr/share. For a foray into why it is called /usr and why it has a structure similar to /, check out Rob Landley’s history lesson on the subject

  • /opt - This is for third-party-provided applications that want to maintain their own directory structure. The application and its required binaries are stored in a subfolder of /opt, away from possible interference from the distribution providers. This self-contained design is supposed to ease the management of third-party applications. Such applications can still use /etc and /var for storing configuration files and other variable files on an FHS-compliant system

  • /srv - This directory can be used by services such as FTP, HTTP and Git to house the content they serve to clients. In practice, many systems do not use /srv. Services often store their data in other locations. For example, web servers commonly use /var/www instead of /srv.

    The FHS also limits what should go into /srv. Only place data here if it is meant to be shared with clients. If the data is internal to the service or has system-wide implications, store it in /var/lib. If the data belongs to a single user, store it in that user’s home directory.

  • /etc - This directory stores system-wide configuration files. These files control how programs and services behave. They are meant to be edited by the system administrator, and sometimes by end users. Default configuration provided by the vendor is usually not stored in /etc. Instead, it is placed under /usr/lib. The files in /etc override these defaults

  • /mnt - This directory is used for temporary mount points. An administrator can mount a filesystem here for short-term use. For example, to access the files on a disk or a backup. Permanent mount points can be placed anywhere on the system, at the admin’s discretion.

  • /media - /media contains mountpoints for removable storage. Usually these mountpoints are automatically created and removed on the insertion and removal of temporary media.

  • /var - This directory stores variable data that must persist across reboots. The contents of /var may change during normal system operation, without direct action from the administrator. For example, a virtual machine may make changes to its disk image while it runs. These changes must remain after a reboot. For this reason, /var must be writable. Programs and services write to /var as part of their normal operation. There is also a subdirectory, /var/opt for applications installed under /opt.

  • /tmp - /tmp is for temporary files that do not need to survive a reboot. In fact, the files in /tmp are not even required to survive across individual runs of the same program. The files may be static or variable, and are usually created as part of a program’s execution.

  • /run - This directory stores runtime data. Runtime data is data produced during the execution of a program. It shows the current state of the system, and its programs and services since boot. Examples of files that usually go into /run are pid, lock, and socket files. Their mere presence tells you something about the running system and applications or administrators can use this information where necessary.

  • /proc - This is a virtual filesystem provided by the kernel. It exposes information about the running system and active processes to userspace. This includes details about system state, process information, and some kernel tunables (mainly via /proc/sys and sysctl). /proc lets users and programs view system and process information through a filesystem-like hierarchy. Applications use this data to understand the system and adjust their behavior while running.

  • /sys - This is a virtual filesystem provided by the kernel. It exposes information about the kernel and other kernel subsystems represented as kernel objects. This includes hardware devices, drivers, and kernel modules. The data is organized as a directory tree that represents the objects, and their properties. It also uses symbolic links to show relationships between objects and make navigation easier. Some parts of /sys are writable and writing to them alters the running system.

Now that you have a grasp of the directories, allow me to drop this great snippet from the spec which helps drive home the differences between the file categories.

Shareable Unshareable
Static /usr /etc
/opt /boot
Variable /var/mail /var/run
/var/spool/news /var/lock

Advantages of using the spec

At heart, the FHS is an enabler. It enables interoperability and collaboration between various distributions and classes of users. However, to an end user or administrator, because it separates files based on the expected rate and source of change and on shareability, the spec unlocks some immediate practical benefits;

  1. Better resource utilization- Separating files by how often they change and how long they must persist allows more efficient backups. Static data does not need frequent backups, and some temporary data does not need backups at all. This enables different backup schedules per data type, reducing wasted storage and processing time.
  2. Reuse- Many parts of an operating system are the same across different systems. Virtual machines and containers often use the same base image and differ only in the services they run. Temporary systems for building or testing also start from the same set of files. Some configuration or program files may also be shared across multiple servers. The FHS supports this by separating shareable files from host-specific files. This makes it easier to reuse the same files across many systems. Knowing which directories are shareable also affects how they are mounted, whether read-only or not.
  3. Tighter fitting security policies - Separating files into clear groups allows different security rules for each group. For example, files that are only written during system upgrades can use stricter controls than user home directories, which change often. Another example is creating policy to prevent program execution from /etc. Administrators can apply security based on how the system is supposed to be used, rather than relying on user behavior. You can see the collective experience of many sysadmins and integrators here.

Conclusion

The FHS enables compatibility and collaboration in the Linux world, and forms the foundation of file hierarchy implementations on many modern Linux systems. However, you are not likely to see filesystems on your average system conform to the spec. To find out why and how check out the next piece on the FHS.

In the meantime, any time you think of the FHS, I want you to remember this quote, “…a place for everything, and everything in its place…”