Appendix

Command binaries that are not essential enough to place into /bin must be placed in /usr/bin, instead. Items that are required only by non-root users (the X Window System, chsh, etc.) are generally not essential enough to be placed into the root partition.

Programs necessary to arrange for the boot loader to be able to boot a file must be placed in /sbin. Configuration files for boot loaders must be placed in /etc.

The GRUB bootloader reads its configurations file before booting, so that must be placed in /boot. However, it is a configuration file, so should be in /etc. The answer here is a symbolic link such as /etc/grub/menu.lst -> /boot/menu.lst.

On some i386 machines, it may be necessary for /boot to be located on a separate partition located completely below cylinder 1024 of the boot device due to hardware constraints.

Certain MIPS systems require a /boot partition that is a mounted MS-DOS filesystem or whatever other filesystem type is accessible for the firmware. This may result in restrictions with respect to usable filenames within /boot (only for affected systems).

The setup of command scripts invoked at boot time may resemble System V, BSD or other models. Further specification in this area may be added to a future version of this standard.

It is recommended that files be stored in subdirectories of /etc rather than directly in /etc.

Systems that use the shadow password suite will have additional configuration files in /etc (/etc/shadow and others) and programs in /usr/sbin (useradd, usermod, and others).

On some Linux systems, this may be a symbolic link to /proc/mounts, in which case this exception is not required.

/etc/X11/xdm holds the configuration files for xdm. These are most of the files previously found in /usr/lib/X11/xdm. Some local variable data for xdm is stored in /var/lib/xdm.

Different people prefer to place user accounts in a variety of places. This section describes only a suggested placement for user home directories; nevertheless we recommend that all FHS-compliant distributions use this as the default location for home directories.

On small systems, each user's directory is typically one of the many subdirectories of /home such as /home/smith, /home/torvalds, /home/operator, etc. On large systems (especially when the /home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as /home/staff, /home/guests, /home/students, etc.

If you want to find out a user's home directory, you should use the getpwent(3) library function rather than relying on /etc/passwd because user information may be stored remotely using systems such as NIS.

It is recommended that apart from autosave and lock files programs should refrain from creating non dot files or directories in a home directory without user intervention.

Shared libraries that are only necessary for binaries in /usr (such as any X Window binaries) must not be in /lib. Only the shared libraries required to run binaries in /bin and /sbin may be here. In particular, the library libm.so.* may also be placed in /usr/lib if it is not required by anything in /bin or /sbin.

The usual placement of this binary is /usr/bin/cpp.

This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them.

/lib<qual>/cpp is still permitted: this allows the case where /lib and /lib<qual> are the same (one is a symbolic link to the other).

A compliant implementation with two CDROM drives might have /media/cdrom0 and /media/cdrom1 with /media/cdrom a symlink to either of these.

If the home directory of the root account is not stored on the root partition it will be necessary to make certain it will default to / if it can not be located.

We recommend against using the root account for tasks that can be performed as an unprivileged user, and that it be used solely for system administration. For this reason, we recommend that subdirectories for mail and other applications not appear in the root account's home directory, and that mail for administration roles such as root, postmaster, and webmaster be forwarded to an appropriate user.

Originally, /sbin binaries were kept in /etc.

Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path.

For example, files such as chfn which users only occasionally use must still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and must live in /bin for that reason.

We recommend that users have read and execute permission for everything in /sbin except, perhaps, certain setuid and setgid programs. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. There is no inherent security advantage in making /sbin off-limits for users.

This is particularly important as these areas will often contain both files initially installed by the distributor, and those added by the administrator.

Examples of such configuration files include Xconfig, XF86Config, or system.twmrc)

Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share.

For example, the perl5 subdirectory for Perl 5 modules and libraries.

Some executable commands such as makewhatis and sendmail have also been traditionally placed in /usr/lib. makewhatis is an internal binary and must be placed in a binary directory; users access only catman. Newer sendmail binaries are now placed by default in /usr/sbin. Additionally, systems using a sendmail-compatible mail transfer agent must provide /usr/sbin/sendmail as a symbolic link to the appropriate executable.

Host-specific data for the X Window System must not be stored in /usr/lib/X11. Host-specific configuration files such as Xconfig or XF86Config must be stored in /etc/X11. This includes configuration data such as system.twmrc even if it is only made a symbolic link to a more global configuration file (probably in /usr/X11R6/lib/X11).

The case where /usr/lib and /usr/lib<qual> are the same (one is a symbolic link to the other) these files and the per-application subdirectories will exist.

Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.

/usr/local/man may be deprecated in future FHS releases, so if all else is equal, making that one a symlink seems sensible.

Locally installed system administration programs should be placed in /usr/local/sbin.

Much of this data originally lived in /usr (man, doc) or /usr/lib (dict, terminfo, zoneinfo).

Obviously, there are no manual pages in / because they are not required at boot time nor are they required in emergencies. Really.

For example, if /usr/local/man has no manual pages in section 4 (Devices), then /usr/local/man/man4 may be omitted.

A major exception to this rule is the United Kingdom, which is `GB' in the ISO 3166, but `UK' for most email addresses.

Some such files include: airport, birthtoken, eqnchar, getopt, gprof.callg, gprof.flat, inter.phone, ipfw.samp.filters, ipfw.samp.scripts, keycap.pcvt, mail.help, mail.tildehelp, man.template, map3270, mdoc.template, more.help, na.phone, nslookup.help, operator, scsi_modes, sendmail.hf, style, units.lib, vgrindefs, vgrindefs.db, zipcodes

Generally, source should not be built within this hierarchy.

This standard does not currently incorporate the TeX Directory Structure (a document that describes the layout TeX files and directories), but it may be useful reading. It is located at ftp://ctan.tug.org/tex/

For example, /usr/share/man/man1/ls.1 is formatted into /var/cache/man/cat1/ls.1, and /usr/X11R6/man/<locale>/man3/XtClass.3x into /var/cache/man/X11R6/<locale>/cat3/XtClass.3x.

An important difference between this version of this standard and previous ones is that applications are now required to use a subdirectory of /var/lib.

This hierarchy should contain files stored in /var/db in current BSD releases. These include locate.database and mountdtab, and the kernel symbol database(s).

Then, anything wishing to use /dev/ttyS0 can read the lock file and act accordingly (all locks in /var/lock should be world-readable).

Note that /var/mail may be a symbolic link to another directory.

/var/run should be unwritable for unprivileged users (root or users running daemons); it is a major security problem if any user can write in this directory.

UUCP lock files must be placed in /var/lock. See the above section on /var/lock.

NIS should not be confused with Sun NIS+, which uses a different directory, /var/nis.