Chapter 3. The Root Filesystem

Table of Contents

3.1. Purpose
3.2. Requirements
3.3. Specific Options
3.4. /bin : Essential user command binaries (for use by all users)
3.4.1. Purpose
3.4.2. Requirements
3.4.3. Specific Options
3.5. /boot : Static files of the boot loader
3.5.1. Purpose
3.5.2. Specific Options
3.6. /dev : Device files
3.6.1. Purpose
3.6.2. Specific Options
3.7. /etc : Host-specific system configuration
3.7.1. Purpose
3.7.2. Requirements
3.7.3. Specific Options
3.7.4. /etc/opt : Configuration files for /opt
3.7.5. /etc/X11 : Configuration for the X Window System (optional)
3.7.6. /etc/sgml : Configuration files for SGML (optional)
3.7.7. /etc/xml : Configuration files for XML (optional)
3.8. /home : User home directories (optional)
3.8.1. Purpose
3.8.2. Requirements
3.8.3. Home Directory Specifications and Conventions
3.9. /lib : Essential shared libraries and kernel modules
3.9.1. Purpose
3.9.2. Requirements
3.9.3. Specific Options
3.10. /lib<qual> : Alternate format essential shared libraries (optional)
3.10.1. Purpose
3.10.2. Requirements
3.11. /media : Mount point for removable media
3.11.1. Purpose
3.11.2. Specific Options
3.12. /mnt : Mount point for a temporarily mounted filesystem
3.12.1. Purpose
3.13. /opt : Add-on application software packages
3.13.1. Purpose
3.13.2. Requirements
3.14. /root : Home directory for the root user (optional)
3.14.1. Purpose
3.15. /run : Run-time variable data
3.15.1. Purpose
3.15.2. Requirements
3.16. /sbin : System binaries
3.16.1. Purpose
3.16.2. Requirements
3.16.3. Specific Options
3.17. /srv : Data for services provided by this system
3.17.1. Purpose
3.18. /tmp : Temporary files
3.18.1. Purpose

3.1. Purpose

The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system.

  • To boot a system, enough software and data must be present on the root partition to mount other filesystems. This includes utilities, configuration, boot loader information, and other essential start-up data. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.

  • To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to diagnose and reconstruct a damaged system must be present on the root filesystem.

  • To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be present on the root filesystem.


The minimum requirements for the root filesystem should be as small as reasonably possible, but no smaller. While many users may not want the extra complexity of a partitioned system, the option to keep the root small should be preserved for several reasons:

  • It is occasionally mounted from very small media.

  • The root filesystem contains many system-specific configuration files. Possible examples include a kernel that is specific to the system, a specific hostname, etc. This means that the root filesystem isn't always shareable between networked systems. Keeping it small on servers in networked systems minimizes the amount of lost space for areas of unshareable files. It also allows workstations with smaller local hard drives.

  • While you may have the root filesystem on a large partition, and may be able to fill it to your heart's content, there will be people with smaller partitions. If you have more files installed, you may find incompatibilities with other systems using root filesystems on smaller partitions. If you are a developer then you may be turning your assumption into a problem for a large number of users.

  • Disk errors that corrupt data on the root filesystem are a greater problem than errors on any other partition. A small root filesystem is less prone to corruption as the result of a system crash.

These considerations must be balanced against the need for a minimally useful operating environment, for the sake of the boot process as well as in failure recovery situations.

Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.


There are several reasons why creating a new subdirectory of the root filesystem is prohibited:

  • It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons.

  • It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes.

Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.