Overview of 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. We will continue to track and follow the standard to keep Red Hat Linux FHS-compliant.

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:

http://www.pathname.com/fhs

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

FHS Organization

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

The /dev Directory

The /dev directory contains file system entries which 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 should be subdirectories of /etc:

/etc
  |- X11
  |- skel

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 refers to temporarily mounted file systems, such as CD-ROMs and floppy disks.

The /opt Directory

The /opt directory provides an area for usually 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 sub-packages, 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 sub-directories, 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.

Due to the great variety of data available within /proc and the many ways this directory can be used to communicate with the kernel, an entire chapter has been devoted to the subject. For more information, please see Chapter 2.

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 FHS says:

"/sbin typically contains files essential for booting the system in addition to the binaries in /bin. Anything executed after /usr is known to be mounted (when there are no problems) should be placed in /usr/sbin. Local-only system administration binaries should be placed into /usr/local/sbin."

At a minimum, the following programs should be in /sbin:

arp, clock,
getty, halt,
init, fdisk,
fsck.*, grub,
ifconfig, lilo,
mkfs.*, mkswap,
reboot, route,
shutdown, swapoff,
swapon, update

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. At minimum, the following directories should be subdirectories of /usr:

/usr
  |- bin
  |- dict
  |- etc
  |- games
  |- include
  |- kerberos
  |- lib
  |- libexec	    
  |- local
  |- sbin
  |- share
  |- src
  |- X11R6

The bin directory contains executables, dict contains non-FHS compliant documentation pages, etc contains system-wide configuration files, games is for games, include contains C header files, kerberos contains binaries and much more for Kerberos, and lib contains object files and libraries that are not designed to be directly utilized by users or shell scripts. The libexec directory contains small helper programs called by other programs, sbin is for system administration binaries (those that do not belong in /sbin), share contains files that are not architecture-specific, src is for source code, and X11R6 is for the X Window System (XFree86 on Red Hat Linux).

The /usr/local Directory

The FHS says:

"The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable among a group of hosts, but not found in /usr."

The /usr/local directory is similar in structure to the /usr directory. It has the following subdirectories, which are similar in purpose to those in the /usr directory:

/usr/local
       |- bin
       |- doc
       |- etc
       |- games
       |- include
       |- lib
       |- libexec
       |- sbin
       |- share
       |- src

The /var Directory

Since 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. The FHS states /var is for:

"...variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files."

Below are some of the directories which should be subdirectories of /var:

/var
  |- arpwatch
  |- cache
  |- db
  |- ftp
  |- gdm
  |- kerberos
  |- lib
  |- local
  |- lock
  |- log
  |- named
  |- mail -> spool/mail
  |- named
  |- nis
  |- opt
  |- preserve
  |- run
  +- spool
       |- anacron
       |- at
       |- cron
       |- fax
       |- lpd
       |- mail
       |- mqueue
       |- news
       |- rwho
       |- samba
       |- slrnpull
       |- squid
       |- up2date
       |- uucp
       |- uucppublic
       |- vbox
       |- voice
  |- tmp
  |- tux
  |- www
  |- yp

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.

/usr/local in Red Hat Linux

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. Since system upgrades from Red Hat are done safely with the rpm command and graphical Gnome-RPM application, 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 the /usr/local/ directory.