分类： LINUX
2008-03-21 09:45:16
Copyright © 1994-2004 Daniel Quinlan
Copyright © 2001-2004 Paul 'Rusty' Russell
Copyright © 2003-2004 Christopher Yeoh
This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems.
All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.
Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are divserved on all copies.
Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder.
This standard enables:
Software to divdict the location of installed files and directories, and
Users to divdict 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.
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 redivsented by a description of the contents enclosed in "<" and ">" characters,
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 redivsented by
Variable substrings of directory names and filenames are indicated by "*".
The sections of the text marked as Rationale are explanatory and are non-normative.
This standard assumes that the operating system underlying an FHS-compliant file system supports the same basic security features found in most UNIX filesystems.
It is possible to define two independent distinctions among files: shareable vs. unshareable and variable vs. static. In general, files that differ in either of these respects should be located in different directories. This makes it easy to store files with different usage characteristics on different filesystems.
"Shareable" files are those that can be stored on one host and used on others. "Unshareable" files are those that are not shareable. For example, the files in user home directories are shareable whereas device lock files are not.
"Static" files include binaries, libraries, documentation files and other files that do not change without system administrator intervention. "Variable" files are files that are not static.
| Rationale | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Shareable files can be stored on one host and used on several others. Typically, however, not all files in the filesystem hierarchy are shareable and so each system has local storage containing at least its unshareable files. It is convenient if all the files a system requires that are stored on a foreign host can be made available by mounting one or a few directories from the foreign host. Static and variable files should be segregated because static files, unlike variable files, can be stored on read-only media and do not need to be backed up on the same schedule as variable files. Historical UNIX-like filesystem hierarchies contained both static and variable files under both /usr and /etc. In order to realize the advantages mentioned above, the /var hierarchy was created and all variable files were transferred from /usr to /var. Consequently /usr can now be mounted read-only (if it is a separate filesystem). Variable files have been transferred from /etc to /var over a longer period as technology has permitted. Here is an example of a FHS-compliant system. (Other FHS-compliant layouts are possible.)
|
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 divsent 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 divsent on the root filesystem.
To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be divsent 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:
|
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:
Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability. |
The following directories, or symbolic links to directories, are required in /.
| Directory | Description |
|---|---|
| bin | Essential command binaries |
| boot | Static files of the boot loader |
| dev | Device files |
| etc | Host-specific system configuration |
| lib | Essential shared libraries and kernel modules |
| media | Mount point for removeable media |
| mnt | Mount point for mounting a filesystem temporarily |
| opt | Add-on application software packages |
| sbin | Essential system binaries |
| srv | Data for services provided by this system |
| tmp | Temporary files |
| usr | Secondary hierarchy |
| var | Variable data |
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.
The following directories, or symbolic links to directories, must be in /, if the corresponding subsystem is installed:
| Directory | Description |
|---|---|
| home | User home directories (optional) |
| lib | Alternate format essential shared libraries (optional) |
| root | Home directory for the root user (optional) |
Each directory listed above is specified in detail in separate subsections below.
/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts.
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. |
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 comdivssion utility (optional) |
| gunzip | The GNU uncomdivssion utility (optional) |
| zcat | The GNU uncomdivssion 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. |
This directory contains everything required for the boot process except configuration files not needed at boot time and the map installer. Thus /boot stores data that is used before the kernel begins executing user-mode programs. This may include saved master boot sectors and sector map files.
The operating system kernel must be located in either / or /boot.
The /dev directory is the location of special or device files.
If it is possible that devices in /dev will need to be manually created, /dev must contain a command named MAKEDEV, which can create devices as needed. It may also contain a MAKEDEV.local for any local devices.
If required, MAKEDEV must have provisions for creating any device that may be found on the system, not just those that a particular implementation installs.
The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary.
No binaries may be located under /etc.
The following directories, or symbolic links to directories are required in /etc:
| Directory | Description |
|---|---|
| opt | Configuration for /opt |
| X11 | Configuration for the X Window system (optional) |
| sgml | Configuration for SGML (optional) |
| xml | Configuration for XML (optional) |
The following directories, or symbolic links to directories must be in /etc, if the corresponding subsystem is installed:
| Directory | Description |
|---|---|
| opt | Configuration for /opt |
The following files, or symbolic links to files, must be in /etc if the corresponding subsystem is installed:
| File | Description |
|---|---|
| csh.login | Systemwide initialization file for C shell logins (optional) |
| exports | NFS filesystem access control list (optional) |
| fstab | Static information about filesystems (optional) |
| ftpusers | FTP daemon user access control list (optional) |
| gateways | File which lists gateways for routed (optional) |
| gettydefs | Speed and terminal settings used by getty (optional) |
| group | User group file (optional) |
| host.conf | Resolver configuration file (optional) |
| hosts | Static information about host names (optional) |
| hosts.allow | Host access file for TCP wrappers (optional) |
| hosts.deny | Host access file for TCP wrappers (optional) |
| hosts.equiv | List of trusted hosts for rlogin, rsh, rcp (optional) |
| hosts.lpd | List of trusted hosts for lpd (optional) |
| inetd.conf | Configuration file for inetd (optional) |
| inittab | Configuration file for init (optional) |
| issue | Pre-login message and identification file (optional) |
| ld.so.conf | List of extra directories to search for shared libraries (optional) |
| motd | Post-login message of the day file (optional) |
| mtab | Dynamic information about filesystems (optional) |
| mtools.conf | Configuration file for mtools (optional) |
| networks | Static information about network names (optional) |
| passwd | The password file (optional) |
| printcap | The lpd printer capability database (optional) |
| profile | Systemwide initialization file for sh shell logins (optional) |
| protocols | IP protocol listing (optional) |
| resolv.conf | Resolver configuration file (optional) |
| rpc | RPC protocol listing (optional) |
| securetty | TTY access control for root login (optional) |
| services | Port names for network services (optional) |
| shells | Pathnames of valid login shells (optional) |
| syslog.conf | Configuration file for syslogd (optional) |
mtab does not fit the static nature of /etc: it is excepted for historical reasons.
Host-specific configuration files for add-on application software packages must be installed within the directory /etc/opt/
No structure is imposed on the internal arrangement of /etc/opt/
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/
| Rationale | |
|---|---|
| Refer to the rationale for /opt. |
/etc/X11 is the location for all X11 host-specific configuration. This directory is necessary to allow local control if /usr is mounted read only.
The following files, or symbolic links to files, must be in /etc/X11 if the corresponding subsystem is installed:
| File | Description |
|---|---|
| Xconfig | The configuration file for early versions of XFree86 (optional) |
| XF86Config | The configuration file for XFree86 versions 3 and 4 (optional) |
| Xmodmap | Global X11 keyboard modification file (optional) |
Subdirectories of /etc/X11 may include those for xdm and for any other programs (some window managers, for example) that need them. We recommend that window managers with only one configuration file which is a default .*wmrc file must name it system.*wmrc (unless there is a widely-accepted alternative name) and not use a subdirectory. Any window manager subdirectories must be identically named to the actual window manager binary.
Generic configuration files defining high-level parameters of the SGML systems are installed here. Files with names *.conf indicate generic configuration files. File with names *.cat are the DTD-specific centralized catalogs, containing references to all other catalogs needed to use the given DTD. The super catalog file catalog references all the centralized catalogs.
Generic configuration files defining high-level parameters of the XML systems are installed here. Files with names *.conf indicate generic configuration files. The super catalog file catalog references all the centralized catalogs.
/home is a fairly standard concept, but it is clearly a site-specific filesystem. The setup will differ from host to host. Therefore, no program should rely on this location.
User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a "dot file"). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a "dot directory"). In this case the configuration files should not start with the '.' character.
The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin.
At least one of each of the following filename patterns are required (they may be files, or symbolic links):
| File | Description |
|---|---|
| libc.so.* | The dynamically-linked C library (optional) |
| ld* | The execution time linker/loader (optional) |
If a C divprocessor is installed, /lib/cpp must be a reference to it, for historical reasons.
The following directories, or symbolic links to directories, must be in /lib, if the corresponding subsystem is installed:
| Directory | Description |
|---|---|
| modules | Loadable kernel modules (optional) |
There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries.
If one or more of these directories exist, the requirements for their contents are the same as the normal /lib directory, except that /lib
This directory contains subdirectories which are used as mount points for removeable media such as floppy disks, cdroms and zip disks.
| Rationale | |
|---|---|
| Historically there have been a number of other different places used to mount removeable media such as /cdrom, /mnt or /mnt/cdrom. Placing the mount points for all removeable media directly in the root directory would potentially result in a large number of extra directories in /. Although the use of subdirectories in /mnt as a mount point has recently been common, it conflicts with a much older tradition of using /mnt directly as a temporary mount point. |
The following directories, or symbolic links to directories, must be in /media, if the corresponding subsystem is installed:
| Directory | Description |
|---|---|
| floppy | Floppy drive (optional) |
| cdrom | CD-ROM drive (optional) |
| cdrecorder | CD writer (optional) |
| zip | Zip drive (optional) |
On systems where more than one device exists for mounting a certain type of media, mount directories can be created by appending a digit to the name of those available above starting with '0', but the unqualified name must also exist.
This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run.
This directory must not be used by installation programs: a suitable temporary directory not in use by the system must be used instead.
/opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt must locate its static files in a separate /opt/
| Directory | Description |
|---|---|
| Static package objects | |
| LANANA registered provider name |
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.
Programs to be invoked by users must be located in the directory /opt/
Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information.
No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.
Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.
| Rationale | |
|---|---|
| The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here. The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt. Generally, all data required to support a package on a system must be divsent within /opt/ The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software. The structure of the directories below /opt/ |
The root account's home directory may be determined by developer or local divference, but this is the recommended default location.
Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin.
The following commands, or symbolic links to commands, are required in /sbin.
| Command | Description |
|---|---|
| shutdown | Command to bring the system down. |
The following files, or symbolic links to files, must be in /sbin if the corresponding subsystem is installed:
| Command | Description |
|---|---|
| fastboot | Reboot the system without checking the disks (optional) |
| fasthalt | Stop the system without checking the disks (optional) |
| fdisk | Partition table manipulator (optional) |
| fsck | File system check and repair utility (optional) |
| fsck.* | File system check and repair utility for a specific filesystem (optional) |
| getty | The getty program (optional) |
| halt | Command to stop the system (optional) |
| ifconfig | Configure a network interface (optional) |
| init | Initial process (optional) |
| mkfs | Command to build a filesystem (optional) |
| mkfs.* | Command to build a specific filesystem (optional) |
| mkswap | Command to set up a swap area (optional) |
| reboot | Command to reboot the system (optional) |
| route | IP routing table utility (optional) |
| swapon | Enable paging and swapping (optional) |
| swapoff | Disable paging and swapping (optional) |
| update | Daemon to periodically flush filesystem buffers (optional) |
/srv contains site-specific data which is served by this system.
| Rationale | |
|---|---|
| This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory. The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data. Distributions must take care not to remove locally placed files in these directories without administrator permission. |
The /tmp directory must be made available for programs that require temporary files.
Programs must not assume that any files or directories in /tmp are divserved between invocations of the program.
| Rationale | |
|---|---|
| IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section. Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted. FHS added this recommendation on the basis of historical divcedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard. |
