Purpose

This standard enables:

• Software to predict the location of installed files and directories, and

• Users to predict the location of installed files and directories.

We do this by:

• Specifying guiding principles for each area of the filesystem,

• Specifying the minimum files and directories required,

• Enumerating exceptions to the principles, and

• Enumerating specific cases where there has been historical conflict.

The FHS document is used by:

• Independent software suppliers to create applications which are FHS compliant, and work with distributions which are FHS complaint,

• OS creators to provide systems which are FHS compliant, and

• Users to understand and maintain the FHS compliance of a system.

The FHS document has a limited scope:

• Local placement of local files is a local issue, so FHS does not attempt to usurp system administrators.

• FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, applications, documentation, etc.

Conventions

We recommend that you read a typeset version of this document rather than the plain text version. In the typeset version, the names of files and directories are displayed in a constant-width font.

Components of filenames that vary are represented by a description of the contents enclosed in "<" and ">" characters, <thus>. Electronic mail addresses are also enclosed in "<" and ">" but are shown in the usual typeface.

Optional components of filenames are enclosed in "[" and "]" characters and may be combined with the "<" and ">" convention. For example, if a filename is allowed to occur either with or without an extension, it might be represented by <filename>[.<extension>].

Variable substrings of directory names and filenames are indicated by "*".

The sections of the text marked as Rationale are explanatory and are non-normative.

Purpose

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

• To boot a system, enough 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.

 

Rationale

The primary concern used to balance these considerations, which favor placing many things on the root filesystem, is the goal of keeping root as small as reasonably possible. For several reasons, it is desirable to keep the root filesystem small:   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.

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.

 

Rationale

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.

Requirements

The following directories, or symbolic links to directories, are required in /.

Each directory listed above is specified in detail in separate subsections below. /usr and /var each have a complete section in this document due to the complexity of those directories.

Specific Options

The following directories, or symbolic links to directories, must be in /, if the corresponding subsystem is installed:

Each directory listed above is specified in detail in separate subsections below.

/bin : Essential user command binaries (for use by all users)

---

Requirements

There must be no subdirectories in /bin.

The following commands, or symbolic links to commands, are required in /bin.

 

Command	Description
cat	Utility to concatenate files to standard output
chgrp	Utility to change file group ownership
chmod	Utility to change file access permissions
chown	Utility to change file owner and group
cp	Utility to copy files and directories
date	Utility to print or set the system data and time
dd	Utility to convert and copy a file
df	Utility to report filesystem disk space usage
dmesg	Utility to print or control the kernel message buffer
echo	Utility to display a line of text
false	Utility to do nothing, unsuccessfully
hostname	Utility to show or set the system's host name
kill	Utility to send signals to processes
ln	Utility to make links between files
login	Utility to begin a session on the system
ls	Utility to list directory contents
mkdir	Utility to make directories
mknod	Utility to make block or character special files
more	Utility to page through text
mount	Utility to mount a filesystem
mv	Utility to move/rename files
ps	Utility to report process status
pwd	Utility to print name of current working directory
rm	Utility to remove files or directories
rmdir	Utility to remove empty directories
sed	The `sed' stream editor
sh	The Bourne command shell
stty	Utility to change and print terminal line settings
su	Utility to change user ID
sync	Utility to flush filesystem buffers
true	Utility to do nothing, successfully
umount	Utility to unmount file systems
uname	Utility to print system information

 

If /bin/sh is not a true Bourne shell, it must be a hard or symbolic link to the real shell command.

The [ and test commands must be placed together in either /bin or /usr/bin.

 

	Rationale
	For example bash behaves differently when called as sh or bash. The use of a symbolic link also allows users to easily see that /bin/sh is not a true Bourne shell. The requirement for the [ and test commands to be included as binaries (even if implemented internally by the shell) is shared with the POSIX.2 standard.

---

Specific Options

The following programs, or symbolic links to programs, must be in /bin if the corresponding subsystem is installed:

 

Command	Description
csh	The C shell (optional)
ed	The `ed' editor (optional)
tar	The tar archiving utility (optional)
cpio	The cpio archiving utility (optional)
gzip	The GNU compression utility (optional)
gunzip	The GNU uncompression utility (optional)
zcat	The GNU uncompression utility (optional)
netstat	The network statistics utility (optional)
ping	The ICMP network test utility (optional)

 

If the gunzip and zcat programs exist, they must be symbolic or hard links to gzip. /bin/csh may be a symbolic link to /bin/tcsh or /usr/bin/tcsh.

 

Rationale

The tar, gzip and cpio commands have been added to make restoration of a system possible (provided that / is intact). Conversely, if no restoration from the root partition is ever expected, then these binaries might be omitted (e.g., a ROM chip root, mounting /usr through NFS). If restoration of a system is planned through the network, then ftp or tftp (along with everything necessary to get an ftp connection) must be available on the root partition.

/boot : Static files of the boot loader

/dev : Device files

/etc : Host-specific system configuration

---

/etc/opt : Configuration files for /opt

Purpose

Host-specific configuration files for add-on application software packages must be installed within the directory /etc/opt/<subdir>, where <subdir> is the name of the subtree in /opt where the static data from that package is stored.

---

Requirements

No structure is imposed on the internal arrangement of /etc/opt/<subdir>.

If a configuration file must reside in a different location in order for the package or system to function properly, it may be placed in a location other than /etc/opt/<subdir>.

 

	Rationale
	Refer to the rationale for /opt.