The File System Hierarchy Standard (FHS)

Red Hat is committed to the Filesystem Hierarchy Standard (FHS), a collaborative document that defines the names and locations of many files and directories. The current FHS document is the authoritative reference to any FHS-compliant file system, but the standard leaves many areas undefined or extensible. In this section, we provide an overview of the standard and a description of the parts of the file system not covered by the standard.

The complete standard is available at: 

Compliance with the standard means many things, but the two most important are compatibility with other FHS-compliant systems and the ability to mount a /usr partition as read-only because it contains common executables and is not meant to be changed by users. Because the /usr directory is mounted read-only, it can be mounted from the CD-ROM or from another machine via a read-only NFS mount.

Why Share a Common Structure?

An operating system's file system structure is its most basic level of organization. Almost all of the ways an operating system interacts with its users, applications, and security model are dependent upon the way it stores its files on a storage device. It is crucial for a variety of reasons that users, as well as programs, be able to refer to a common guideline to know where to read and write files.

A file system can be seen in terms of two different logical categories of files:

  • Shareable vs. unshareable files Shareable files are those that can be accessed by various hosts; unshareable files are not available to any other hosts.

  • Variable vs. static files Variable files can change at any time without any intervention; static files, such as read-only documentation and binaries, do not change without an action from the system administrator or an agent that the system administrator has placed in motion to accomplish that task.

The reason for looking at files in this way is to help you understand the type of permissions given to the directory that holds them. The way in which the operating system and its users need to use the files determines the directory where those files should be placed, whether the directory is mounted read-only or read-write, and the level of access allowed on each file. The top level of this organization is crucial, as the access to the underlying directories can be restricted or security problems may manifest themselves if the top level is left disorganized or without a widely-used structure.

However, simply having a structure does not mean much unless it is a standard. Competing structures can actually cause more problems than they fix. Because of this, Red Hat has chosen the most widely used file system structure for Unix-like systems (FHS) and has extended it only slightly to accommodate special files used within Red Hat Linux.

FHS Organization

The directories and files noted here are just a small subset of those specified by the FHS document. Check the latest FHS document at for the most complete information.

The /dev Directory

The /dev directory contains file system entries that represent devices that are attached to the system. These files are essential for the system to function properly.

The /etc Directory

The /etc directory is reserved for configuration files that are local to your machine. No binaries are to be put in /etc. Any binaries that were formerly put in /etc should now go into /sbin or possibly /bin.

The X11 and skel directories are subdirectories of the /etc directory. The X11 directory is for X11 configuration files such as XF86Config. The skel directory is for "skeleton" user files, which are used to populate a home directory when a user is first created.

The /lib Directory

The /lib directory should contain only those libraries that are needed to execute the binaries in /bin and /sbin. These shared library images are particularly important for booting the system and executing commands within the root file system.

The /mnt Directory

The /mnt directory is for temporarily mounted file systems, such as CD-ROMs and floppy disks.

The /opt Directory

The /opt directory provides an area for large, static application software packages to be stored.

For packages that wish to avoid putting their files throughout the file system, /opt provides a logical and predictable organizational system under that package's directory. This gives the system administrator an easy way to determine the role of each file within a particular package.

For example, if sample is the name of a particular software package located within /opt, then all of its files could be placed within directories inside /opt/sample, such as /opt/sample/bin for binaries and /opt/sample/man for manual pages.

Large packages that encompass many different subpackages, each of which accomplish a particular task, also go within /opt, giving that large package a standardized way to organize itself. In this way, our sample package may have different tools that each go in their own subdirectories, such as /opt/sample/tool1 and /opt/sample/tool2, each of which can have their own bin, man, and other similar directories.

The /proc Directory

The /proc directory contains special "files" that either extract information from or send information to the kernel. For more information on the great variety of data available within /proc and the many ways this directory can be used to communicate with the kernel, see the section “The /proc File System” later in this chapter.

The /sbin Directory

The /sbin directory is for executables used only by the root user. The executables in /sbin are only used to boot and mount /usr and perform system recovery operations.

The /usr Directory

The /usr directory is for files that can be shared across a whole site. The /usr directory usually has its own partition, and it should be mountable read-only. Table 23-1 briefly describes the major subdirectories of /usr.

Table 23-1: Subdirectories of /usr


What It Contains




Non-FHS compliant documentation pages


System-wide configuration files




C header files


Binaries (and much more) for Kerberos


Object files and libraries that are not designed to be directly utilized by users or shell scripts


Small helper programs called by other programs


System administration binaries (those that do not belong in /sbin)


Files that are not architecture-specific, src is for source code


Files for the X Window System (XFree86 on Red Hat Linux)

The /usr/local Directory

The /usr/local directory is similar in structure to the /usr directory.

In Red Hat Linux, the intended use for /usr/local is slightly different from that specified by the FHS. The FHS says that /usr/local should be where you store software that is to remain safe from system software upgrades. Because system upgrades from Red Hat are done safely with the rpm command and graphical Package Manager tool, you do not need to protect files by putting them in /usr/local. Instead, we recommend you use /usr/local for software that is local to your machine.

For instance, say you have mounted /usr via read-only NFS from a host named jake. If there is a package or program you would like to install, but you are not allowed to write to jake, you should install it under /usr/local. Later perhaps, if you have managed to convince the system administrator of jake to install the program on /usr, you can uninstall it from /usr/local.

The /var Directory

Because the FHS requires that you be able to mount /usr read-only, any programs that write log files or need spool or lock directories should write them to the /var directory. System log files such as messages and lastlog go in /var/log. The /var/lib/rpm directory also contains the RPM system databases. Lock files go in /var/lock, usually in directories particular for the program using the file. The /var/spool directory has subdirectories for various systems that need to store data files.

Special File Locations

Red Hat extends the FHS structure slightly to accommodate special files used by Red Hat Linux. The following list describes the major special file locations in Red Hat Linux:

  • /var/lib/rpm/ — Most files pertaining to the Red Hat Package Manager (RPM) are kept in the directory. See Part V for more information on RPM.

  • /var/spool/up2date/ — This directory contains files used by Red Hat Update Agent, including RPM header information for the system. This location may also be used to temporarily store RPMs downloaded while updating your system. For more information on Red Hat Network, see the Red Hat Network website at

  • /etc/sysconfig/ — This directory stores a variety of configuration information. Many scripts that run at boot time use the files in this directory.

  • /initrd/ — This directory is empty after the system is booted, but is used as a critical mount point during the boot process.


    Do not remove the /initrd/ directory for any reason. Removing this directory will cause your system to fail to boot with a kernel panic error message.

The Red Hat Documentation Team - Official Red Hat Linux User's Guide
The Red Hat Documentation Team - Official Red Hat Linux User's Guide
Year: 2002
Pages: 223 © 2008-2017.
If you may any questions please contact us: