Filesystem Hierarchy Standard FHS-3.0 - ESP

Capítulo 1.
Introducción
1.1. Propósito
Este estándar permite:
• Software para predecir la ubicación de los archivos y directorios instalados, y

• Usuarios para predecir la ubicación de los archivos y directorios instalados.
Hacemos esto por:
• Especificar principios rectores para cada área del sistema de archivos,

• Especificar los archivos y directorios mínimos requeridos,
• Enumerar excepciones a los principios, y
• Enumerar casos específicos en los que ha habido conflictos históricos.
El documento FHS es utilizado por:
• Proveedores de software independientes para crear aplicaciones que cumplan con FHS, y trabajen
con distribuciones que cumplen con FHS,
• Creadores de SISTEMAS para proporcionar sistemas que cumplen con FHS, y
• Usuarios para entender y mantener el cumplimiento FHS de un sistema.
El documento FHS tiene un alcance limitado:
• La colocación local de archivos locales es un problema local, por lo que FHS no intenta usurpar a
los administradores del sistema.
• FHS aborda problemas en los que las ubicaciones de archivos deben coordinarse entre varias
partes, como sitios locales, distribuciones, aplicaciones, documentación, etc.
1.2. Convenios
Le recomendamos que lea una versión tipográfica de este documento en lugar de la versión de
texto plano. En una versión tipográfica, los nombres de los archivos y directorios se muestran en
una fuente de ancho constante.
Los componentes de los nombres de archivo que varían se representan mediante una descripción
del contenido incluido entre caracteres "<" y ">", <por lo tanto>. Las direcciones de
correo electrónico también se incluyen en "<" y ">", pero se muestran en la tipografía habitual.
Los componentes opcionales de los nombres de archivo se encierran en los caracteres "[" y "]"
y pueden combinarse con la convención "<" y ">". Por ejemplo, si se permite que un nombre de
archivo aparezca con o sin extensión, podría estar representado por
<filename>[.<extension>].
Las subcadenas variables de nombres de directorio y nombres de archivo se indican con "*".
Las secciones del texto marcadas como Fundamento son explicativas y no son normativas.
Capítulo 2. El sistema de archivos
Este estándar supone que el sistema operativo subyacente a un sistema de archivos compatible con
FHS admite las mismas características de seguridad básicas que se encuentran en la mayoría de los
sistemas de archivos UNIX.
Es posible definir dos distinciones independientes entre archivos: compartibles vs no compartibles,

y variables vs estáticos. En general, los archivos que difieren en cualquiera de estos aspectos deben
estar ubicados en directorios diferentes.
Esto facilita el almacenamiento de archivos con diferentes características de uso en diferentes

sistemas de archivos.
Los archivos "compartibles" son aquellos que se pueden almacenar en un host y se utilizan en
otros.
Los archivos "no compartibles" son los que no se pueden compartir. Por ejemplo, los archivos en
los directorios de inicio de los usuarios se pueden compartir, mientras que los archivos de bloqueo
del dispositivo no.
Los archivos "estáticos" incluyen archivos binarios, librerías, archivos de documentación y otros
archivos que no cambian sin intervención del administrador del sistema.
Los archivos "variables" son archivos que no son estáticos.
Fundamento
Los archivos que se pueden compartir pueden almacenarse en un host y utilizarse en varios otros.
Normalmente, sin embargo, no todos los archivos en la jerarquía del sistema de archivos (FHS) se
pueden compartir por lo que cada sistema tiene un almacenamiento local que contiene al menos
sus archivos no se pueden compartir. Es conveniente si todos los archivos que requiere un sistema
que están almacenados en un host externo puede estar disponibles montando uno o varios
directorios desde el host externo.
Los archivos estáticos y variables deben separarse, porque los archivos estáticos a diferencia de los
archivos variables pueden almacenarse en medios de solo lectura y no es necesario realizar una
copia de seguridad en la misma programación que los archivos de variables.
Las jerarquías históricas del sistema de archivos similares a UNIX contenían archivos estáticos y
variables en ambos directorios /usr y /etc. Con el fin de darse cuenta de las ventajas
mencionadas anteriormente, la jerarquía /var fue creada y todos los archivos variables se
transfirieron de /usr a /var. Por lo tanto /usr ahora puede ser montado de solo lectura (si
es un sistema de archivos independiente). Los archivos variables se han transferido desde /etc a
/var durante un período más largo como la tecnología lo ha permitido.
Aquí está un ejemplo de un sistema compatible con FHS. (Otros diseños compatibles con FHS son posibles.)
Compartibles No Compartibles
Estáticos /usr /etc
/opt /boot
Variables /var/mail /var/run
/var/spool/news /var/lock
Capítulo 3. El sistema de archivos raíz
3.1. Propósito
El contenido del sistema de archivos raíz debe ser adecuado para arrancar, restaurar, recuperar y/o
reparar el sistema.
• Para arrancar un sistema, debe haber suficiente software y datos en la partición raíz para montar
otros sistemas de archivos (Filesystems). Esto incluye utilidades, configuración, información del
gestor de arranque y otros datos de inicio esenciales. /usr, /opt y /var están diseñados de
tal manera que pueden estar ubicados en otras particiones o Filesystems.
• Para permitir la recuperación y/o reparación de un sistema, las utilidades que necesita un
mantenedor experimentado para diagnosticar y reconstruir un sistema dañado deben estar
presente en el sistema de archivos raíz.
• Para restaurar un sistema, las utilidades necesarias para restaurar a partir de copias de seguridad
del sistema (en disquete, cinta, etc.) deben estar presente en el sistema de archivos raíz.
Fundamento
Los requisitos mínimos para el sistema de archivos raíz deben ser tan pequeños como sea
razonablemente posible , pero no más pequeño. Si bien es posible que muchos usuarios no quieran
la complejidad adicional de un sistema particionado, la opción para mantener la raíz pequeña debe
conservarse por varias razones:
• Ocasionalmente se monta desde medios muy pequeños.
• El sistema de archivos raíz contiene muchos archivos de configuración específicos del sistema.
Posibles ejemplos incluir un kernel que sea específico del sistema, un nombre de host específico,
etc. Esto significa que la raíz del sistema de archivos no siempre se puede compartir entre sistemas
en red. Mantenerlo pequeño en los servidores, en los sistemas en red minimizan la cantidad de
espacio perdido para áreas de archivos no compartibles. También permite estaciones de trabajo
con discos duros locales más pequeños.
• Mientras que usted puede tener el sistema de archivos raíz en una partición grande, y puede ser
capaz de llenarlo a su contenido máximo, habrá personas con particiones más pequeñas. Si tiene
más archivos instalados, puede encontrar incompatibilidades con otros sistemas que utilizan
sistemas de archivos raíz en particiones más pequeñas. Si usted es un desarrollador, entonces usted
puede estar convirtiendo su suposición en un problema para un gran número de usuarios.
• Los errores de disco que corrompen los datos del sistema de archivos raíz son un problema
mayor que los errores en alguna otra partición. Un pequeño sistema de archivos raíz es menos
propenso a la corrupción como resultado de un bloqueo del sistema.
Estas consideraciones deben equilibrarse con la necesidad de una operación mínimamente útil
Del entorno, por el bien del proceso de arranque, así como en situaciones de recuperación de
errores.
Las aplicaciones nunca deben crear ni requerir archivos o subdirectorios especiales en el directorio
raíz. Otras ubicaciones en la jerarquía de FHS proporcionan flexibilidad más que suficiente para
cualquier paquete.
Fundamento
Hay varias razones por las que está prohibido crear un nuevo subdirectorio del sistema de archivos raíz:
• Exige espacio en una partición raíz que el administrador del sistema podría querer mantener
simple por razones de rendimiento o de seguridad.
• Evade cualquier disciplina que el administrador del sistema haya establecido para distribuir
jerarquías de archivos en volúmenes montables.
Las distribuciones no deben crear nuevos directorios en la jerarquía raíz sin las consecuencias,
incluida la portabilidad de las aplicaciones.
3.2. Requisitos
Los siguientes directorios, o enlaces simbólicos a directorios, son necesarios en /. (raíz)
Directorio Descripción
bin Comandos esenciales binarios
boot Archivos estáticos del gestor de arranque
dev Archivos de dispositivos
etc Configuración del sistema específico del host
lib Librerías compartidas y módulos de kernel
media Punto de montaje de medios para medios extraíbles
mnt Punto de montaje para montar un sistema de archivos temporalmente
opt Paquetes de software de aplicaciones adicionales
run Datos relevantes para los procesos en ejecución
sbin Binarios del sistema esenciales
srv Datos para los servicios prestados por este sistema
tmp Archivos temporales
usr Jerarquía secundaria
var Datos variables
Cada directorio mencionado anteriormente se especifica en detalle en subsecciones separadas a

continuación. /usr y /var cada uno tiene una sección completa en este documento debido a
la complejidad de esos directorios.
3.3. Opciones específicas

Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en / (raiz), si el
subsistema correspondiente está instalado:
home directorios de inicio de usuario de inicio (opcional)
lib<qual> Librerias compartidas esenciales de formato alternativo (opcional)
root directorio raíz Inicio para el usuario raíz (opcional)
Cada directorio mencionado anteriormente se especifica en detalle en subsecciones separadas a

continuación.
3.4. /bin : Comandos binarios de usuario esenciales
(para uso por todos los usuarios)
3.4.1. Propósito
/bin contiene comandos que pueden ser utilizados tanto por el administrador del sistema como
por los usuarios, pero que son requeridos cuando no hay otros sistemas de archivos montados (por
ejemplo, en modo de usuario único). También puede contener comandos que son utilizados
indirectamente por scripts. 1
3.4.2. Requisitos
No debe haber subdirectorios en /bin.
Los siguientes comandos, o enlaces simbólicos a comandos, son necesarios en /bin:
Comando Descripción
cat Utilidad para concatenar archivos a salida estándar

chgrp Utilidad para cambiar la propiedad del grupo de archivos
chmod Utilidad para cambiar los permisos de acceso a archivos
chown Utilidad para cambiar el propietario y el grupo del archivo
cp Utilidad para copiar archivos y directorios
date Utilidad para imprimir o establecer los datos y la hora del sistema
dd Utilidad para convertir y copiar un archivo
df Utilidad para informar sobre el uso del espacio en disco del sistema de archivos
dmesg Utilidad para imprimir o controlar el búfer de mensajes del kernel
echo Utilidad para mostrar una línea de texto
false Utilidad para no hacer nada, sin éxito
hostname Utilidad para mostrar o establecer el nombre de host del sistema
kill Utilidad para enviar señales a procesos
ln Utilidad para hacer enlaces entre archivos
login Utilidad para iniciar una sesión en el sistema
ls Utilidad para enumerar el contenido del directorio
mkdir Utilidad para hacer directorios
mknod Utilidad para crear archivos especiales de bloques o caracteres
more Utilidad para paginar a través del texto
mount Utilidad para montar un sistema de archivos
mv Utilidad para mover/renombrar archivos
ps Utilidad para informar del estado del proceso
pwd Utilidad para imprimir el nombre del directorio de trabajo actual
rm Utilidad para eliminar archivos o directorios
1
Los comandos binarios que no son lo suficientemente esenciales para colocar en /bin deben colocarse en /usr/bin, en su lugar.
Elementos que solo son requeridos por los no-root usuarios (el X window system, chsh,etc.) generalmente no son lo suficientemente
esenciales como para colocarse en la partición raíz.
rmdir Utilidad para eliminar directorios vacíos
sed El editor de secuencias 'sed'
sh POSIX shell de comandos compatible
stty Utilidad para cambiar e imprimir la configuración de la línea de terminal
su Utilidad para cambiar el ID de usuario
sync Utilidad de sincronización para vaciar los búferes del sistema de archivos
true Utilidad para no hacer nada, con éxito
umount Utilidad para desmontar sistemas de archivos
uname Utilidad para imprimir la información del sistema
Si /bin/sh no es el propio comando de shell compatible con POSIX, debe ser un vínculo duro o
simbólico a él comando de shell real.
POSIX (Portable Operating System Interface for X, Interfaz Portátil de Sistema Operativo para
Unix. Es un estándar del IEEE que define un conjunto de servicios del sistema operativo).
Los comandos [ y test deben colocarse juntos en /bin o /usr/bin.
Fundamento
Varios shells se comportan de manera diferente cuando se llaman como sh. con el fin de preservar
la compatibilidad POSIX mientras permiten cambios o extensiones a POSIX cuando lo desee.
El requisito de que los comandos [ test se incluyan como binarios (incluso si se implementan
internamente por el shell) se comparte con el estándar POSIX.1-2008.
3.4.3. Opciones específicas

Los siguientes programas, o enlaces simbólicos a programas, deben estar en /bin si el subsistema
correspondiente está instalado:
comando Descripción
csh El shell C (opcional)
ed El editor 'ed' (opcional)
tar La utilidad de archivado comprimido (opcional)
cpio La utilidad de archivado cpio (opcional)
gzip La utilidad de compresión GNU (opcional)
gunzip La utilidad gnu descompresión (opcional)
zcat La utilidad gnu descompresion (opcional)
netstat La utilidad de estadísticas de red (opcional)
ping La utilidad de prueba de red ICMP (opcional)
/bin/csh puede ser un vínculo simbólico a /bin/tcsh o /usr/bin/tcsh.

Fundamento
Se han añadido los comandos tar, gzip y cpio para hacer posible la restauración de un sistema
(siempre que / esté intacto).
Por el contrario, si alguna vez no se espera ninguna restauración de la partición raíz, entonces estos
binarios se podrían omitir (por ejemplo, ROM chip root, mounting /usr a través de NFS). Si la
restauración de un sistema se planifica a través de la red, a continuación, ftp o tftp (junto con todo
lo necesario para obtener un ftp conexión) debe estar disponible en la partición raíz.
3.5. /boot : Archivos estáticos del gestor de arranque

3.5.1. Propósito
Este directorio contiene todo lo necesario para el proceso de arranque, excepto los archivos de
configuración que no son necesarios en tiempo de arranque y el instalador del mapa. Por lo tanto,
/boot almacena los datos que se utilizan antes de que el kernel comience a ejecutar programas de
modo de usuario. Esto puede incluir los sectores de arranque maestro guardados y los archivos de
mapa sectorial.
Los programas necesarios para organizar que el gestor de arranque pueda arrancar un archivo
deben colocarse en /sbin.
Los archivos de configuración para los cargadores de arranque que no son necesarios en el
momento del arranque deben colocarse en /etc.

El kernel del sistema operativo debe estar ubicado en / o /boot.
Ciertas arquitecturas pueden tener otros requisitos para /boot relacionados con limitaciones o
expectativas específicos de esa arquitectura. Estos requisitos no se enumeran aquí; distribuciones
pueden añadir según sea necesario para permitir el inicio del sistema en estas arquitecturas.
3.6. /dev : Archivos de dispositivo

3.6.1. Propósito
El directorio /dev es la ubicación de archivos especiales o de dispositivo.
Si es posible que los dispositivos de /dev deban crearse manualmente, /dev debe contener un
comando denominado MAKEDEV, que puede crear dispositivos según sea necesario. También
puede contener un MAKEDEV.local para cualquier dispositivo local.
Si es necesario, MAKEDEV debe tener disposiciones para crear cualquier dispositivo que se pueda
encontrar en el sistema, no sólo aquellos que instala una distribución en particular.
3.7. /etc : Configuración del sistema específica del Host
3.7.1. Propósito
La jerarquía /etc contiene archivos de configuración. Un "archivo de configuración" es un archivo
local utilizado para funcionamiento de un programa; debe ser estático y no puede ser un binario
ejecutable. 2
Se recomienda que los archivos se almacenen en subdirectorios de /etc en lugar de directamente

en /etc.
3.7.2. Requisitos
No se pueden encontrar binarios en /etc.
2
Para ser claros, /etc puede contener scripts ejecutables, como los scripts de comandos
comúnmente llamados por init para iniciar y apagar el sistema e iniciar procesos daemon.
"Binario ejecutable" en este contexto se refiere a código de máquina directa o pseudocódigo no

en un formato legible por el ser humano, como ejecutables ELF nativos.
Los siguientes directorios, o enlaces simbólicos a directorios son necesarios en /etc:
Opt Configuración para /opt

Los siguientes directorios, o enlaces simbólicos a directorios deben estar en /etc, si el subsistema
correspondiente está instalado:
X11 Configuración para el sistema X Window (opcional)

sgml Configuración para SGML (opcional)
xml Configuración para XML (opcional)
Los siguientes archivos, o enlaces simbólicos a archivos, deben estar en /etc si está instalado el
subsistema correspondiente:3
Archivo Descripción
csh.login Archivo de inicialización de todo el sistema para inicios de sesión de shell C (opcional)
exports Exporta la lista de control de acceso al sistema de archivos NFS (opcional)
fstab Información estática sobre sistemas de archivos (opcional)
ftpusers FTP daemon lista de control de acceso de usuario (opcional)
gateways Archivo que enumera las puertas de enlace para enrutadas (opcional)
gettydefs Ajustes de velocidad y terminal utilizados por getty (opcional)
group Archivo de grupo de usuarios (opcional)
host.conf Archivo de configuración Resolver (opcional)
hosts Información estática sobre nombres de host (opcional)
hosts.allow Archivo de acceso de host para contenedores TCP (opcional)
hosts.deny Archivo de acceso de host para contenedores TCP (opcional)
hosts.equiv Lista de hosts de confianza para rlogin, rsh, rcp (opcional)
hosts.lpd Lista de hosts de confianza para lpd (opcional)
inetd.conf Archivo de configuración para inetd (opcional)
inittab Archivo de configuración para init (opcional)
issue Mensaje de inicio de sesión previo y archivo de identificación (opcional)
ld.so.conf Lista de directorios adicionales para buscar librerias (opcional)
motd Mensaje post-inicio de sesión del archivo de día (opcional)
mtab Información dinámica sobre sistemas de archivos (opcional)
mtools.conf Archivo de configuración para mtools (opcional)
networks Información estática sobre nombres de red (opcional)
passwd El archivo de contraseña (opcional)
printcap La base de datos de capacidad de la impresora lpd (opcional)
profile Archivo de inicialización de Systemwide para inicios de sesión sh shell (opcional)
protocols Listado de protocolos IP (opcional)
resolv.conf Archivo de configuración Resolver (opcional)
rcp Lista de protocolos RPC (opcional)
secure tty Control de acceso TTY para inicio de sesión root (opcional)
services Nombres de puerto para servicios de red (opcional)
shells Nombres de ruta de datos de shells de inicio de sesión válidos (opcional)
syslog.conf Archivo de configuración para syslogd (opcional)
3
Los sistemas que utilizan la suite de contraseñas de sombra tendrán archivos de configuración adicionales en /etc
(/etc/shadow y otros) y programas en /usr/sbin (useradd, usermod, y otros).
mtab no se ajusta a la naturaleza estática de /etc: se exceptúa por razones históricas. 4

3.7.4. /etc/opt : Archivos de configuración para /opt
3.7.4.1. Propósito
Los archivos de configuración específicos del host para los paquetes de software de aplicación
complementarios deben instalarse dentro de la directorio /etc/opt/<subdir>, donde
<subdir> es el nombre del subárbol en /opt donde los datos estáticos de ese paquete se
almacenan.
3.7.4.2. Requisitos
No se impone ninguna estructura sobre la disposición interna de /etc/opt/<subdir>.
Si un archivo de configuración debe residir en una ubicación diferente para que el paquete o el
sistema funcionen correctamente, puede colocarse en una ubicación distinta de
/etc/opt/<subdir>.
Fundamento
Consulte la justificación de /opt.
3.7.5. /etc/X11 : Configuración para el sistema X Window (opcional)
3.7.5.1. Propósito
/etc/X11 es la ubicación para todas las configuraciones específicas del host X11. Este directorio
es necesario para permitir controlar si /usr está montado de solo lectura.
3.7.5.2. Opciones específicas

Los siguientes archivos, o enlaces simbólicos a archivos, deben estar en /etc/X11 si el subsistema
correspondiente es Instalado:
4
En algunos sistemas Linux, esto puede ser un enlace simbólico a /proc/mounts, en cuyo caso esta excepción no es
necesaria
archivo Descripción
xorg.conf El archivo de configuración para X.org versiones 7 y posteriores (opcional)
Xmodmap Archivo de modificación de teclado Global X11 (opcional)
Los subdirectorios de /etc/X11 pueden incluir aquellos para xdm y para cualquier otro programa
(algunos administradores de ventanas, por ejemplo) que los necesiten. 5
5
/etc/X11/xdm contiene los archivos de configuración para xdm. Estos son la mayoría de los archivos encontrados
anteriormente en /usr/lib/X11/xdm. Algunos datos variables locales para xdm, se almacenan en /var/lib/xdm.
3.7.6. /etc/sgml : Archivos de configuración para SGML (opcional)
3.7.6.1. Propósito
Aquí se instalan archivos de configuración genéricos que definen parámetros de alto nivel de los
sistemas SGML. Archivos con nombres *.conf indican archivos de configuración genéricos.
Los archivos con nombres *.cat son específicos de DTD catálogos centralizados, que contienen
referencias a todos los demás catálogos necesarios para utilizar la DTD dada. El súper Catálogo de
archivos de catálogo hace referencia a todos los catálogos centralizados.
3.7.7. /etc/xml : Archivos de configuración para XML (opcional)

3.7.7.1. Propósito
Aquí se instalan archivos de configuración genéricos que definen parámetros de alto nivel de los
sistemas XML. Archivos con nombres *.conf indican archivos de configuración genéricos. El
catálogo de archivos de super catálogo hace referencia a todos los catálogos centralizados.
3.8. /home : Directorios de inicio de usuario (opcional)

3.8.1. Propósito
/home es un concepto bastante estándar, pero es claramente un sistema de archivos específico del
sitio. 6 La configuración será diferente de un host a otro. Por lo tanto, ningún programa debe asumir
ninguna ubicación específica para un directorio de inicio, más bien debería consultarlo. 7
3.8.2. Requisitos
Los archivos de configuración específicos del usuario para las aplicaciones se almacenan en el
directorio principal del usuario en un archivo que se inicia con el carácter '.' (un "archivo de
punto"). Si una aplicación necesita crear más de un archivo de puntos, entonces debe
colocarse en un subdirectorio con un nombre que comience por un carácter '.', (un "directorio de
puntos"). En este caso, los archivos de configuración no deben comenzar con el carácter '.'. 8
6
Diferentes personas prefieren colocar cuentas de usuario en una variedad de lugares. En esta sección solo se describe una
ubicación sugerida para los directorios de inicio de usuario; sin embargo, se recomienda que todas las distribuciones
compatibles con FHS utilicen esto como la ubicación predeterminada para los directorios de /home de usuario. Cuentas sin
inicio de sesión creados con fines administrativos a menudo tienen sus directorios de inicio en otros lugares.
En sistemas más pequeños, el directorio de inicio de cada usuario se implementa normalmente como un subdirectorio
directamente en /home, por ejemplo /home/smith, /home/torvalds, /home/operator, etc. En sistemas
grandes (especialmente cuando los directorios /home se comparten entre muchos hosts que utilizan NFS) es útil subdividir
los directorios de inicio de usuario. La subdivisión se puede lograr mediante el uso de subdirectorios como /home/staff,
/home/invitados, /home/estudiantes, etc.
7
Para encontrar el directorio principal de un usuario, utilice una función de librería como getpwent, getpwent_r de
fgetpwent en lugar de depender de /etc/passwd porque la información del usuario puede almacenarse de forma
remota utilizando sistemas como NIS.
8
Se recomienda que, aparte de guardar y bloquear archivos, los programas se abstengan de crear archivos o directorios que
no sean de puntos en un directorio de inicio sin el consentimiento del usuario.
3.8.3. Especificaciones y convenciones del directorio de Home
Se han realizado varios esfuerzos en el pasado para estandarizar el diseño de los directorios de
inicio, incluida la especificación de directorios base de XDG 9 y las convenciones de GLib sobre el
contenido del directorio de usuarios. 10
Es posible realizar esfuerzos adicionales en esta dirección en el futuro. Para acomodar el software
que hace uso de estas especificaciones y convenciones, las distribuciones pueden crear jerarquías
de directorios que siguen la especificaciones y convenciones. Esas jerarquías de directorios pueden
estar ubicadas debajo de los directorios de inicio.
3.9. /lib : Librerías compartidas esenciales y Módulos kernel
3.9.1. Propósito
El directorio /lib contiene las imágenes de librerías compartidas necesarias para arrancar el
sistema y ejecutar los comandos en el sistema de archivos raíz, es decir por binarios en /bin y
/sbin. 11
3.9.2. Requisitos
Se requiere al menos uno de cada uno de los siguientes patrones de nombre de archivo (pueden ser
archivos o enlaces simbólicos):
libc.so.* La biblioteca C vinculada dinámicamente (opcional)
ld* El vinculador/cargador de tiempo de ejecución (opcional)
Si se instala un preprocesador de C, /lib/cpp debe ser una referencia a él, por razones históricas.12
9
Encontrado en http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html y
http://www.freedesktop.org/wiki/Software/xdg-user-dirs.
10
Puede encontrar una descripción de las convenciones de GLib en la documentación de GUserDirectory, en
http://developer.gnome.org/glib/unstable/glib-Miscellaneous-Utility-Functions.html-GUserDirectory.
11
Las librerías compartidas que solo son necesarias para los archivos binarios en /usr (como los binarios de ventana X) no
deben estar en /lib. Sólo las librerías compartidas necesarias para ejecutar archivos binarios en /bin y /sbin puede
estar aquí. En particular, la librería libm.so.* también se puede colocar en /usr/lib si no es requerido por cualquier
cosa en /bin o /sbin.
12
La colocación habitual de este binario es /usr/bin/cpp.
Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /lib, si el subsistema
está instalado:
modules Módulos de núcleo cargables (opcional)
3.10. /lib<qual> : Formato alternativo esencial de librerías

compartidas (opcional)
3.10.1. Propósito
Puede haber una o más variantes del directorio /lib en sistemas que admitan más de un formato
que requiere librerías separadas. 13
3.10.2. Requisitos
Si existe uno o varios de estos directorios, los requisitos para su contenido son los mismos que el
directorio /lib normal, excepto que /lib<qual>/cpp no es necesario. 14
13
Esto se utiliza comúnmente para soporte de 64 bits o 32 bits en sistemas que admiten varios formatos binarios, pero
requieren librerías del mismo nombre. En este caso, /lib32 y /lib64 podrían ser los directorios de las librerías y /lib
un enlace simbólico a uno de ellos.
14
/lib<qual>/cpp todavía está permitido: esto permite el caso donde /lib y /lib<qual> son los mismos (uno es
un enlace simbólico al otro).
3.11. /media : Punto de montaje para medios extraíbles
3.11.1. Propósito
Este directorio contiene subdirectorios que se utilizan como puntos de montaje para medios
extraíbles como disquetes discos, cdroms y discos zip.
Fundamento
Históricamente se han utilizado otros lugares diferentes para montar medios extraíbles como
/cdrom, /mnt o /mnt/cdrom. Colocar los puntos de montaje para todos los medios
extraíbles directamente en el directorio raíz podría resultar en una gran cantidad de directorios
adicionales en /.
Aunque el uso de subdirectorios en /mnt como punto de montaje ha sido común recientemente,
entra en conflicto con una tradición mucho más antigua de usar /mnt directamente como punto
de montaje temporal.

Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /media, si el
subsistema está instalado:
floppy Unidad de disquete (opcional)
cdrom Unidad de CD-ROM (opcional)
cdrecorder CD writer (opcional)
zip Zip drive (opcional)
En sistemas donde existe más de un dispositivo para montar un determinado tipo de medio, los
directorios de montaje pueden ser creados añadiendo un dígito al nombre de los disponibles
anteriormente a partir de '0', pero el nombre también debe existir. 15
3.12. /mnt : Punto de montaje para un sistema de archivos

montado temporalmente
3.12.1. Propósito
Este directorio se proporciona para que el administrador del sistema pueda montar temporalmente
un sistema de archivos según sea necesario.
El contenido de este directorio es un problema local y no debe afectar a la forma en que se ejecuta
cualquier programa.
Este directorio no debe ser utilizado por programas de instalación: en su lugar, debe utilizarse un
directorio temporal adecuado que no esté siendo utilizado por el sistema.
15
Una distribución compatible con dos unidades de CDROM podría tener /media/cdrom0 y /media/cdrom1 con
/media/cdrom un enlace a cualquiera de estos.
3.13. /opt : Paquetes de software de aplicación complementarios
3.13.1. Propósito
/opt está reservado para la instalación de paquetes de software de aplicación complementarios.
Un paquete que se va a instalár en /opt debe instalar sus archivos estáticos en un árbol de
directorios /opt/<package> u /opt/<provider>, donde <package> es un nombre que
describe el paquete de software <provider> es el nombre registrado del proveedor (LANANA).
3.13.2. Requisitos
<paquete> Objetos de paquete estático
<proveedor> Nombre del proveedor registrado LANANA
Los directorios /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib y

/opt/man, están reservados para el uso del administrador del sistema local.
Los paquetes pueden proporcionar archivos "front-end" destinados a ser colocados en (un enlace a
vinculación o copia) de estos directorios reservados por el administrador del sistema local, pero
debe funcionar normalmente en ausencia de estos directorios reservados.
Los programas que los usuarios pueden invocar deben estar ubicados en el directorio
/opt/<package>/bin o en la jerarquía /opt/<provider>. Si el paquete incluye páginas
de manual de UNIX, deben ubicarse en /opt/<package>/share/man o bajo la jerarquía
/opt/<provider>, y se debe utilizar la misma subestructura que /usr/share/man.
Los archivos de paquete que son variables (cambios en el funcionamiento normal) deben
instalarse en /var/opt. Consulte la sección sobre /var/opt para obtener más información.
Los archivos de configuración específicos del host deben instalarse en /etc/opt. Consulte la
sección sobre /etc para obtener más información.
No pueden existir otros archivos de paquete fuera de las jerarquías /opt, /var/opt y
/etc/opt, excepto para los archivos de paquete que deben residir en ubicaciones específicas
dentro del árbol del sistema de archivos para funcionar correctamente. Por ejemplo, los archivos de
bloqueo de dispositivos deben colocarse en /var/lock y los dispositivos deben estar ubicados en
/dev.
Las distribuciones se pueden instalar y administrar de otro modo el software en /opt bajo un
subdirectorio debidamente registrado.
Fundamento
El uso de /opt para el software complementario es una práctica bien establecida en la comunidad
UNIX. La Interfaz binaria de aplicación del sistema V [AT&T 1990], basada en la definición de la
interfaz del sistema V(Tercera edición), proporciona una estructura /opt muy similar a la definida
aquí.
Intel Binary Compatibility Standard v. 2 (iBCS2) también proporciona una estructura similar para
/opt.
Generalmente, todos los datos necesarios para admitir un paquete en un sistema deben estar
presentes dentro de /opt/<package>, incluidos los archivos destinados a ser copiados en
/etc/opt/<package> y /var/opt/<package> así como directorios reservados en
/opt.
Las restricciones menores a las distribuciones que utilizan /opt son necesarias porque es posible
que haya conflictos entre el software instalado en la distribución y el software instalado
localmente, especialmente en el caso de los nombre de ruta fijos encontrados en algún software
binario.
La estructura de los directorios debajo de /opt/<provider> se deja en manos del

empaquetador del software, aunque se recomienda que los paquetes estén instalados en
/opt/<provider>/<package> y siga una estructura similar a las directrices para
/opt/<package>. Una razón válida para divergir de esta estructura es para paquetes de
soporte que pueden tener archivos instalados en /opt/<provider>/lib o
/opt/<provider>/bin.
3.14. /root : Directorio de inicio para el usuario root (opcional)
3.14.1. Propósito
El directorio de inicio de la cuenta root puede ser determinado por el desarrollador o la preferencia
local, pero este es la ubicación predeterminada recomendada. 16
16
Si el directorio de inicio de la cuenta root no se almacena en la partición raíz, será necesario asegurarse de que esté predeterminado
en / si no se puede localizar.
Se recomienda no utilizar la cuenta root para las tareas que se pueden realizar como un usuario sin privilegios, y que se utilice
únicamente para la administración de sistema. Por esta razón, recomendamos que los subdirectorios de correo y otras aplicaciones no
aparezcan en el directorio principal de la cuenta root, y que el correo para funciones de administración como root, postmaster y
webmaster se reenvía a un usuario adecuado.
3.15. /run : Datos variables en tiempo de ejecución
3.15.1. Propósito
Este directorio contiene datos de información del sistema que describen el sistema desde que se
inició. Los archivos bajo este directorio deben borrarse (eliminarse o truncarse según corresponda)
al comienzo del proceso de arranque.
Los propósitos de este directorio alguna vez fueron servidos por /var/run. En general, los
programas pueden continuar usando /var/run para cumplir los requisitos establecidos para
/run con fines de compatibilidad con versiones anteriores. Los programas que han migrado para
ustilizar /run deben dejar de usar /var/run, excepto como se indique en la sección sobre
/var/run.
Los programas pueden tener un subdirectorio en /run; esto se recomienda para los programas
que utilizan más de un archivo de tiempo de ejecución.
Los usuarios también pueden tener un subdirectorio de /run, aunque se debe tener cuidado para
limitar adecuadamente los derechos de acceso para evitar el uso no autorizado de /run y otros
subdirectorios. 17
3.15.2. Requisitos
Los archivos de identificador de procesos (PID), que se colocaron originalmente en /etc, deben
colocarse en /run. La convención de nomenclatura para los archivos PID es <nombre-del
programa>.pid. Por ejemplo, el archivo crond PID se denomina /run/crond.pid.
El formato interno de los archivos PID permanece sin cambios. El archivo debe constar del
identificador del proceso en decimal codificado en ASCII, seguido de un carácter de nueva línea.
Por ejemplo, si crond era el proceso número 25, /run/crond.pid contendría tres caracteres:
dos, cinco y newline.
Los programas que leen archivos PID deben ser algo flexibles en lo que aceptan; es decir, deben
ignorar espacios en blanco adicionales, ceros a la izquierda, ausencia de la nueva línea final o líneas
adicionales en el archivo PID. Los programas que crean archivos PID deben utilizar la especificación
simple ubicada en el párrafo anterior.
Los programas del sistema que mantienen sockets de dominio UNIX transitorios deben colocarlos
en este directorio o en un subdirectorio apropiado como se describió anteriormente.
17
/run no debe ser grabable para usuarios sin privilegios; es un problema de seguridad importante si cualquier usuario puede escribir
en este directorio. Los subdirectorios específicos del usuario solo deben ser grabables por el propietario de cada directorio.
3.16. /sbin : Binarios del sistema
3.16.1. Propósito
Las utilidades utilizadas para la administración del sistema (y otros comandos de solo root) se
almacenan en /sbin, /usr/sbin y /usr/local/sbin. /sbin contiene binarios
esenciales para arrancar, restaurar, recuperar, y/o reparar el sistema además de los binarios en
/bin. 18
Programas ejecutados después de /usr se conoce que se deben montar (cuando no hay
problemas) generalmente se colocan en /usr/sbin. Instalación local los programas de
administración del sistema deben colocarse en /usr/local/sbin. 19
3.16.2. Requisitos
No debe haber subdirectorios en /sbin.
Los siguientes comandos, o enlaces simbólicos a comandos, son necesarios en /sbin:
shutdown comando para derribar el sistema.

Los siguientes archivos, o enlaces simbólicos a archivos, deben estar en /sbin si el subsistema
correspondiente es Instalado:
fastboot Reinicie el sistema sin comprobar los discos (opcional)
fasthalt Detenga el sistema sin comprobar los discos (opcional)
fdisk Manipulador de tablas de particiones (opcional)
fsck Utilidad de comprobación y reparación del sistema de archivos (opcional)
fsck.* Utilidad de comprobación y reparación del sistema de archivos para un sistema de
archivos (opcional)
getty El programa getty (opcional)
halt Comando para detener el sistema (opcional)
ifconfig Configurar una interfaz de red (opcional)
init Proceso inicial (opcional)
mkfs Comando para crear un sistema de archivos (opcional)
mkfs.* Comando para crear un sistema de archivos específico (opcional)
mkswap Comando para configurar un área de intercambio (opcional)
reboot Comando para reiniciar el sistema (opcional)
route Utilidad de la tabla de ruteo IP de ruta (opcional)
swapon Habilitar paginación e intercambio (opcional)
swapoff Deshabilitar la paginación y el intercambio (opcional)
update Daemon para vaciar periódicamente los búferes del sistema de archivos (opcional)
3.17. /srv: Datos de los servicios prestados por este
Sistema
3.17.1. Propósito
/srv contiene datos específicos del sitio que proporciona este sistema.
Fundamento
El propósito principal de especificar esto es para que los usuarios puedan encontrar la ubicación de
los archivos de datos para un servicio en particular, y para que los servicios que requieren un solo
árbol para los datos de solo lectura, datos de escritura y scripts (como los scripts cgi) se pueden
ubicarse razonablemente. Los datos que sólo son de interés para un usuario específico deben ir en
el directorio de inicio de ese usuario. Si el directorio y la estructura de archivos de los datos no
están expuestos a los consumidores, debe ir en /var/lib.
La metodología utilizada para nombrar los subdirectorios de /srv no está especificada, ya que
actualmente no hay consenso sobre cómo se debe hacer. Un método para estructurar datos en
/srv es protocolo, por ejemplo. ftp, rsync, www y cvs. En sistemas grandes puede ser
útil estructurar /srv por contexto administrativo, como /srv/physics/www,
/srv/compsci/cvs, etc. Esta configuración será diferente de un host a otro host. Por lo tanto,
ningún programa debería de basarse en una estructura de subdirectorio específica de /srv
existentes o que los datos estén necesariamente almacenados en /srv. Sin embargo /srv
siempre debe existir en los sistemas compatibles con FHS y deben utilizarse como la ubicación
predeterminada para dichos datos.
Las distribuciones deben tener cuidado de no eliminar los archivos ubicados localmente en estos
directorios sin permiso de administrador. 20
18
Originalmente, los binarios /sbin se mantenían en /etc.
19
Decidir qué cosas van en directorios "/sbin" es simple: si un usuario normal (no un administrador del sistema) alguna vez lo
ejecutará directamente, entonces debe colocarse en uno de los directorios "/bin". Los usuarios normales no deben tener que
colocar ninguno de los directorios /sbin en su ruta de acceso.
Por ejemplo, los archivos como chfn que los usuarios sólo utilizan ocasionalmente deben seguir colocandose en /usr/bin.
ping, aunque es absolutamente necesario para root (recuperación y diagnóstico de red) es a menudo utilizado por los usuarios y debe
vivir en /bin por esa razón.
Recomendamos que los usuarios tengan permiso de lectura y ejecución para todo en /sbin excepto, tal vez, ciertos programas
setuid y setgid. La división entre /bin y /sbin no se creó por razones de seguridad o para evitar que los usuarios vean el
sistema operativo, sino para proporcionar una buena partición entre los binarios que todo el mundo utiliza y los que se utilizan
principalmente para las tareas de administración. No existe una ventaja de seguridad inherente en hacer /sbin fuera de los límites
para los usuarios.
20
Esto es particularmente importante, ya que estas áreas a menudo contendrán tanto los archivos instalados inicialmente por el
distribuidor, como los añadidos por el Administrador
3.18. /tmp : Archivos temporales
3.18.1. Propósito
El directorio /tmp debe estar disponible para los programas que requieren archivos temporales.
Los programas no deben suponer que los archivos o directorios de /tmp se conservan entre las
invocaciones de la Programa.
Fundamento
El estándar IEEE POSIX.1-2008 enumera requisitos similares a la sección anterior.
Aunque los datos almacenados en /tmp se pueden eliminar de una manera específica del sitio, se
recomienda que archivos y directorios ubicados en /tmp se eliminarán cada vez que se inicie el
sistema.
FHS añadió esta recomendación sobre la base de precedentes históricos y prácticas comunes, pero
no lo convierten en un requisito porque la administración del sistema no está dentro del alcance de
esta norma.
Capítulo 4. La jerarquía /usr
4.1. Propósito
/usr es la segunda sección principal del sistema de archivos. /usr es un recurso compartido de
datos de solo lectura. Eso significa que /usr se debe poder compartir entre varios hosts
compatibles con FHS y no debe escribirse en él. Cualquier información específica del host o que
varía con el tiempo se almacena en otro lugar.
Los paquetes de software grandes no deben utilizar un subdirectorio directo en la jerarquía /usr.
4.2. Requisitos
Los siguientes directorios, o vínculos simbólicos a directorios, son necesarios en /usr.
bin La mayoría de los comandos de usuario
Lib Librerías
local Jerarquía local (vacío después de la instalación principal)
sbin Binarios del sistema no vitales
share Datos independientes de la arquitectura

games Juegos y binarios educativos (opcional)
include Archivos de encabezado incluidos por los programas C
libexec Binarios ejecutados por otros programas (opcional)
lib<qual> Librerías de formato alternativo (opcional)
src Código fuente (opcional)
Se hace una excepción para el Sistema de Window X debido a un precedente considerable y una
práctica ampliamente aceptada.
Los siguientes enlaces simbólicos a directorios pueden estar presentes. Esta posibilidad se basa en
la necesidad de preservar compatibilidad con sistemas más antiguos hasta que se pueda suponer
que toda la distribución utiliza la jerarquía /var.
/usr/spool -> /var/spool

/usr/tmp -> /var/tmp
/usr/spool/locks -> /var/lock
Una vez que un sistema ya no requiere cualquiera de los enlaces simbólicos anteriores, el enlace
puede ser eliminado, si lo desea.
4.4. /usr/bin : La mayoría de los comandos de usuario
4.4.1. Propósito
Este es el directorio principal de comandos ejecutables en el sistema
4.4.2. Requisitos
No debe haber subdirectorios en /usr/bin.

Los siguientes archivos, o enlaces simbólicos a archivos, deben estar en /usr/bin, si el
perl El lenguaje práctico de extracción e informe (opcional)
python El lenguaje interpretado de Python (opcional)
tclsh Shell simple que contiene intérprete Tcl (opcional)
wish Shell Simple Tcl/Tk de ventanas (opcional)
expect programa para el diálogo interactivo (opcional)
Fundamento
En muchos scripts ejecutables, el intérprete que se va a invocar para ejecutar el script se especifica
mediante #! path_to_interpreter en la primera línea de un script. Para que estos scripts
sean portátiles entre diferentes sistemas, es una ventaja estandarizar las ubicaciones del intérprete.
El intérprete de shells ya está fijado en /bin para esta especificación, pero los intérpretes de Perl,
Python y Tcl puede instalarse en varios lugares. Las ubicaciones especificadas aquí pueden
implementarse como enlaces simbólicos a la ubicación física de los intérpretes.
4.5. /usr/include : Directorio para archivos de inclusión

estándar.
4.5.1. Propósito
Aquí es donde se deben colocar todos los archivos de inclusión de uso general del sistema para el
lenguaje de programación C.

Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /usr/include, si el
correspondiente subsistema está instalado:
bsd Compatibilidad con BSD incluir archivos (opcional)
4.6. /usr/lib : Librerías para programación y Paquetes
4.6.1. Propósito
/usr/lib incluye archivos de objetos y librerías. 1 En algunos sistemas, también pueden incluir
binarios internos que no están diseñados para ser ejecutados directamente por los usuarios o
scripts de shell. 2
Las aplicaciones pueden utilizar un único subdirectorio en /usr/lib. Si una aplicación utiliza un
subdirectorio, todos los datos dependientes de la arquitectura utilizados exclusivamente por la
aplicación deben colocarse dentro de ese subdirectorio. 3

Por razones históricas, /usr/lib/sendmail debe ser un enlace simbólico que se resuelva al
correo electrónico compatible por el agente de transferencia de correo del sistema, si este último
existe. 4 5
4.7. /usr/libexec : Binarios dirigidos por otros programas

(opcional)
4.7.1. Propósito
/usr/libexec incluye binarios internos que no están diseñados para ser ejecutados
directamente por los usuarios o shell Scripts. Las aplicaciones pueden utilizar un único subdirectorio
en /usr/libexec.
Las aplicaciones que utilizan /usr/libexec de esta manera no deben usar tampoco /usr/lib
para almacenar binarios, aunque pueden usar /usr/lib para los otros fines documentados aquí.
Fundamento
Algunas versiones anteriores de este documento no soportaban /usr/libexec, a pesar de ser
una práctica estándar en una serie de entornos. 6 Para dar cabida a esta restricción, se convirtió en
práctica común para usar /usr/lib en su lugar. Cualquiera de las prácticas es ahora aceptable,
pero cada aplicación debe elegir de una manera u otra para organizarse.
1
Varios subdirectorios y archivos estáticos específicos de la aplicación independientes de la arquitectura se deben colocar en
/usr/share.
2
Véase a continuación, en la sección /usr/libexec, para una explicación de /usr/lib vs. /usr/libexec para binarios
ejecutables.
3
Por ejemplo, el subdirectorio perl5 para módulos y bibliotecas Perl 5.
4
Algunos comandos ejecutables como makewhatis y sendmail también se han colocado tradicionalmente en /usr/lib.
makewhatis es un binario interno y debe colocarse en un directorio binario; los usuarios sólo acceden a catman. Los binarios de
sendemail más recientes ahora se colocan de forma predeterminada en /usr/sbin. Además, los sistemas que utilizan un agente
de transferencia de correo compatible con sendmail deben proporcionar /usr/sbin/sendmail como el comando sendmail,
ya sea como el ejecutable o como un enlace simbólico al ejecutable adecuado.
5
Los datos específicos del host para el sistema Windos X no deben almacenarse en /usr/lib/X11. Archivos de configuración
específicos del host como xorg.conf debe almacenarse en /etc/X11. Esto incluye datos de configuración como system.twmrc
incluso si sólo se convierte en un enlace simbólico a un archivo de configuración (probablemente en /usr/lib/X11).
6
Véanse, por ejemplo, las "Normas de Codificación GNU" de la Free Software Foundation
4.8. /usr/lib<qual> : Librerías de formatos alternativos
(opcional)
4.8.1. Propósito
/usr/lib<qual> realiza el mismo rol que /usr/lib para un formato binario alternativo,
excepto que los enlaces simbólicos /usr/lib<qual>/sendmail y
/usr/lib<qual>/X11 no son obligatorios. 7
4.9. /usr/local : Jerarquía local

4.9.1. Propósito
La jerarquía /usr/local es para que la utilice el administrador del sistema cuando instale
software localmente. Debe estar a salvo de ser sobrescrito cuando se actualiza el software del
sistema. Se puede utilizar para programas y datos que se pueden compartir entre un grupo de
hosts, pero que no se encuentran en /usr.
El software instalado localmente debe colocarse dentro de /usr/local en lugar de /usr a

menos que se esté instalando para reemplazar o actualizar el software en /usr. 8
4.9.2. Requisitos
Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /usr/local
bin Binarios locales
etc Configuración del sistema específico del host para binarios locales
games Binarios de juegos locales
include Archivos de encabezado C local
lib Librerías locales
man Manuales locales en línea
sbin Binarios del sistema local
share Jerarquía independiente de la arquitectura local
src Código fuente local
Ningún otro directorio, excepto los enumerados a continuación, puede estar en /usr/local
después de instalar por primera vez un sistema compatible con FHS.

Si existen directorios /lib<qual> o /usr/lib<qual>, los directorios equivalentes también
deben existir en /usr/local. /usr/local/etc puede ser un enlace simbólico a
/etc/local.
7
En el caso donde /usr/lib y /usr/lib<qual> sean los mismos (uno es un enlace simbólico al otro) estos archivos y los
subdirectorios por aplicación existirán.
8
El software colocado en / o /usr puede ser sobrescrito por las actualizaciones del sistema (aunque recomendamos que las
distribuciones no sobrescriban los datos en /etc en estas circunstancias). Por esta razón, el software local no debe colocarse fuera de
/usr/local sin una buena razón.
Fundamento
La consistencia de /usr/local/etc es beneficiosa para los instaladores, y ya se utiliza en otros
sistemas. Como es necesario realizar una copia de seguridad de todo /usr/local para
reproducir un sistema, no introduce gastos adicionales de mantenimiento, pero un enlace simbólico
a /etc/local es adecuado si los sistemas quieren toda su configuración bajo una jerarquía.
Tenga en cuenta que /usr/etc todavía no está permitido: los programas en /usr deben colocar
los archivos de configuración en /etc.
Si el directorio /usr/share/color existe como se especifica en este documento, entonces el

directorio /usr/local/share/color también debe existir, regido por las mismas reglas que
/usr/share/color.
Fundamento
Este uso permite al sysadmin un lugar para instalar perfiles de color manualmente cuando sea
necesario.
4.9.4. /usr/local/share : Jerarquía Independiente de la

arquitectura local
Los requisitos para el contenido de este directorio son los mismos que para /usr/share.
4.10. /usr/sbin : Binarios del sistema estándar no esenciales

4.10.1. Propósito
Este directorio contiene los binarios no esenciales utilizados exclusivamente por el administrador
del sistema. Programas de administración del sistema necesarios para la reparación, recuperación y
montaje del sistema /usr, u otras funciones esenciales deben colocarse en /sbin en su lugar. 9
4.10.2. Requisitos
No debe haber subdirectorios en /usr/sbin.
4.11. /usr/share : Datos Independientes de la arquitectura

4.11.1. Propósito
La jerarquía /usr/share es para todos los archivos de datos independientes de la arquitectura
de solo lectura. 10
9
Los programas de administración del sistema instalados localmente deben colocarse en /usr/local/sbin.
10
Muchos de estos datos vivían originalmente en /usr(man,doc)o /usr/lib(dict, terminfo, zoneinfo).
Se pretende que esta jerarquía se pueda compartir entre todas las plataformas de arquitectura de
un sistema operativo determinado; así, por ejemplo, un sitio con plataformas i386, Alpha y PPC
podría mantener un único directorio /usr/share montado de forma centralizada. Sin embargo,
tenga en cuenta que /usr/share generalmente no está destinado a ser compartido por
diferentes sistemas operativos o por diferentes versiones del mismo sistema operativo.
Cualquier programa o paquete que contenga o requiera datos que no necesiten ser modificados
debe almacenar estos datos en /usr/share(o /usr/local/share , si se instalan
localmente). Se recomienda utilizar un subdirectorio en /usr/share para este propósito. Las
aplicaciones que utilizan solo un archivo pueden utilizar /usr/share/misc.
Los datos de juegos almacenados en /usr/share/games deben ser datos puramente estáticos.
Cualquier archivo modificable, como archivos de puntuación, registros de juego, etc., deben
colocarse en /var/games.
4.11.2. Requisitos
Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /usr/share
man Manuales en línea
misc Datos diversos independientes de la arquitectura

Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /usr/share, si el
color Información de gestión del color (opcional)
dict Listas de palabras (opcional)
doc Documentación diversos (opcional)
games Archivos de datos estáticos para /usr/games (opcional)
info Directorio primario para el sistema GNU Info (opcional)
locale Información de configuración regional (opcional)
nls Catálogos de mensajes para compatibilidad con idiomas nativos (opcional)
ppd Definiciones de impresora (opcional)
sgml Datos SGML (opcional)
terminfo Directorios para la base de datos terminfo (opcional)
tmac Macros troff no distribuidas con groff (opcional)
Xml Datos XML (opcional)
zoneinfo Información y configuración de la zona horaria (opcional)
Se recomienda colocar aquí directorios independientes de la arquitectura y específicos de la

aplicación. Dichos directorios incluyen groff, perl, ghostscript, texmfy,
kbd(Linux o syscons(BSD). Sin embargo, pueden colocarse en /usr/lib por
compatibilidad con versiones anteriores, a discreción del distribuidor. Del mismo modo, se puede
utilizar una jerarquía de /usr/lib/games además de la jerarquía /usr/share/games si el
distribuidor desea colocar algunos datos del juego allí.
4.11.4. /usr/share/color : Información de gestión del color
(opcional)
4.11.4.1. Propósito
Este directorio es el hogar de los archivos de gestión de color ICC instalados por el sistema.

Los siguientes directorios deben estar en /usr/share/color, si está instalado el subsistema
correspondiente:
icc Perfiles de color ICC (opcional)
El directorio de nivel superior /usr/share/color no debe contener ningún archivo; todos los
archivos deben estar en subdirectorios de /usr/share/color.
4.11.5. /usr/share/dict : Listas de palabras (opcional)

Este directorio es el hogar de listas de palabras en el sistema; Tradicionalmente, este directorio
contiene sólo el archivo de palabras en inglés, que es utilizado por look(1) y varios programas de
ortografía. Las palabras pueden utilizar ortografía estadounidense o británica.
Fundamento
La razón por la que aquí sólo se encuentran las listas de palabras es que son los únicos archivos
comunes para todos los correctores ortográficos.

Los siguientes archivos, o enlaces simbólicos a archivos, deben estar en /usr/share/dict, si el
words Lista de palabras en inglés (opcional)
Los sitios que requieren la ortografía estadounidense y británica pueden vincular words a
/usr/share/dict/american-english o /usr/share/dict/british-english.
Las listas de palabras para otros idiomas se pueden agregar usando el nombre en inglés para ese
idioma, por ejemplo, /usr/share/dict/french, /usr/share/dict/danish,etc.
Estos deben, si es posible, utilizar un carácter unicode, con el juego de caracteres UTF-8 como la
opción preferida.
Otras listas de palabras deben incluirse aquí, si están presentes.

4.11.6. /usr/share/man : Páginas del manual
Esta sección detalla la organización de las páginas del manual en todo el sistema, incluyendo
/usr/share/man. Consulte también la sección sobre /var/cache/man.
El <directorio man> principal del sistema es /usr/share/man. /usr/share/man

contiene información del manual para comandos y datos bajo los sistemas de archivos / y /usr.11
Las páginas del manual se almacenan en el <directorio man>

/<locale>/man<section>/<arch>. Una explicación del <directorio man>,
<locale>, <section>, y <arch> se indican a continuación.
A continuación se ofrece una descripción de cada sección:
• man1: Programas de usuario En este capítulo se incluyen las páginas del manual que describen
los comandos de acceso público. La mayoría de la documentación del programa que un usuario
necesitará utilizar se encuentra aquí.
• man2: Llamadas al sistema Esta sección describe todas las llamadas del sistema (solicitudes para
que el kernel realice operaciones).
• man3: Funciones y subrutinas de la librería La sección 3 describe las rutinas para la librería de
programas que no son llamadas directas a los servicios del kernel. Este y el capítulo 2 son sólo
realmente de interés para los programadores.
• man4: Archivos especiales La sección 4 describe los archivos especiales, las funciones del
controlador relacionadas y el soporte de red disponible en el sistema. Normalmente, esto incluye
los archivos de dispositivo que se encuentran en /dev y la interfaz del kernel para el soporte del
protocolo de red.
• man5: Formatos de archivo Los formatos de muchos archivos de datos se documentan en la

sección 5. Esto incluye varios archivos de inclusión, archivos de salida del programa y archivos del
sistema.
• man6: Juegos Este capítulo documenta juegos, demostraciones y programas generalmente,

triviales. Diferentes personas tienen varias nociones sobre lo esencial que es esto.
• man7: Varias páginas del manual que son difíciles de clasificar se designan como sección 7. El
troff y otros paquetes de macros de procesamiento de texto se encuentran aquí.
• man8: Administración del sistema los programas utilizados por los administradores del sistema
para el funcionamiento y mantenimiento del sistema se documentan aquí. Algunos de estos
programas también son ocasionalmente útiles para los usuarios normales.
11
Obviamente, no hay páginas de manuales en / porque no son necesarias en el momento del arranque ni son necesarias en
emergencias. En serio.
Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en
/usr/share/<mandir>/<locale>, a menos que estén vacíos: 12
man1 Programas de usuario (opcional)
man2 Llamadas al sistema (opcional)
man3 Llamadas a la Libreía (opcional)
man4 Archivos especiales (opcional)
man5 Formatos de archivo (opcional)
man6 Juegos (opcional)
man7 Varios (opcional)
man8 Administración del sistema (opcional)
El componente <section> describe la sección manual.
Se deben tomar disposiciones en la estructura de /usr/share/man para admitir las páginas del
manual que están escritas en diferentes (o múltiples) idiomas. Estas disposiciones deben tener en
cuenta el almacenamiento y referencia a estas páginas del manual. Los factores relevantes incluyen
el idioma (incluidas las diferencias geográficas) y el conjunto de códigos de caracteres.
Este nombre de los subdirectorios de idiomas de /usr/share/man se basa en el Apéndice E del

estándar POSIX1003.1 que describe la cadena de identificación de la configuración regional, el
método más aceptado para describir un entorno cultural. La cadena <locale> es:
<idioma>[_<territorio>][.<character-set>][,<version>]
El campo <idioma> debe tomarse de ISO 639 (un código para la representación de nombres de
idiomas). Debe tener dos caracteres de ancho y debe especificarse solo con letras minúsculas.
El campo <territorio> debe ser el código de dos letras de ISO 3166 (una especificación de
representaciones de países), si es posible. (La mayoría de la gente está familiarizada con los códigos
de dos letras utilizados para los códigos de país en direcciones de correo electrónico.) Debe tener
dos caracteres de ancho y especificarse solo con letras mayúsculas. 13
El campo <character-set> debe representar el estándar que describe el juego de caracteres.

Si el campo <carácter-set> es sólo una especificación numérica, el número representa el
número de estándar internacional que describe el juego de caracteres. Se recomienda que se trata
de una representación numérica si es posible (normas ISO, especialmente), no incluya símbolos de
puntuación adicionales, y que cualquier letra estar en minúsculas.
Un parámetro que especifica un <versión> del perfil se puede colocar después del campo
<character-set>, delimitado por una coma. Esto puede utilizarse para discriminar entre
diferentes necesidades culturales; por ejemplo, orden de diccionario frente a un orden de
clasificación más orientado a sistemas. Este estándar recomienda no utilizar el campo <versión>,
a menos que sea necesario.
12
Por ejemplo, si /usr/share/man no tiene páginas de manuales en la sección 4 (Dispositivos), /usr/share/man/man4 puede
omitirse.
13
Una excepción importante a esta regla es el Reino Unido, que es «GB» en la ISO 3166, pero «UK» para la mayoría de las direcciones
de correo electrónico.
Los sistemas que utilizan un idioma y un conjunto de códigos únicos para todas las páginas del manual pueden
omitir la subcadena <locale> y almacenar todas las páginas del manual en <directorio man>. Por
ejemplo, los sistemas que solo tienen páginas de manual en inglés codificado con ASCII, pueden almacenar
páginas de manual (los directorios man<section>) directamente en /usr/share/man. (Esa es la
circunstancia y el arreglo tradicionales, de hecho.)
Los países para los que hay un conjunto de códigos de caracteres estándar bien aceptado pueden omitir el
campo <character-set>, pero se recomienda encarecidamente que se incluya, especialmente para los
países con varias estándares de competencia.
Varios ejemplos:
Idioma Territorio Conjuntos de Directorio

caracteres
Inglés — ASCII /usr/share/man/en
Inglés Reino Unido Unicode UTF-8 /usr/share/man/en_GB.10646
Inglés Estados Unidos ASCII /usr/share/man/en_US
Francés Canadá ISO 8859-1 /usr/share/man/fr_CA.88591
Francés Francia ISO 8859-1 /usr/share/man/fr_FR.88591
Alemán Alemania ISO 646 /usr/share/man/de_DE.646
Alemán Alemania ISO 6937 /usr/share/man/de_DE.6937
Alemán Alemania ISO 8859-1 /usr/share/man/de_DE.88591
Alemán Suiza ISO 646 /usr/share/man/de_CH.646
Japonés Japon JIS /usr/share/man/ja_JP.jis
Japonés Japon SJIS /usr/share/man/ja_JP.sjis
Japonés Japon UJIS (or EUC-J) /usr/share/man/ja_JP.ujis
Japonés Japon Unicode UTF-16 /usr/share/man/ja_JP.10646
Del mismo modo, se deben prever las páginas de manuales que dependan de la arquitectura, como la
documentación sobre controladores de dispositivos o comandos de administración del sistema de bajo nivel.
Estos deben ser colocados bajo un subdirectorio <arch> en el directorio man<section> apropiado; por
ejemplo, una página de comando man para el comando i386 ctrlaltdel(8)podría colocarse
en/usr/share/man/<locale>/man8/i386/ctrlaltdel.8.
Las páginas del manual para comandos y datos en /usr/local se almacenan en /usr/local/man o
/usr/local/share/man. Todas las jerarquías de páginas de manual del sistema deben tener la misma
estructura que /usr/share/man, ya que esta estructura es esperada por los comandos que consumen
contenido de páginas del manual. 14
Las secciones de la página cat (cat<section>) que contienen entradas de la página de manual
formateadas también se encuentran dentro de subdirectorios de <man>/<locale>, pero no son necesarias
ni pueden distribuirse en lugar de las páginas del manual de origen nroff.
Las secciones numeradas del "1" al "8" se definen tradicionalmente. En general, el nombre de archivo de las
páginas de manual ubicadas dentro de una sección en particular termina con. <section>.
Además, algunos grandes conjuntos de páginas de manual específicas de la aplicación tienen un sufijo
adicional al nombre de archivo de las páginas de manual. Por ejemplo, las páginas de manual del sistema de
manejo de correo MH deben tener mh adjunto a todos los manuales de MH. Todas las páginas del manual del
sistema X Window deben tener una x adicional al nombre del archivo.
La práctica de colocar páginas de manual en varios idiomas en los subdirectorios apropiados de

/usr/share/man también se aplica a las otras jerarquías de páginas de manual, como /usr/local/man.
(Esta parte del estándar también se aplica más adelante en la sección de la estructura opcional
/var/cache/man.)
14
/usr/local/man está en desuso y puede caerse en una versión futura de esta especificación.
4.11.7. /usr/share/misc : Varios datos independientes de
la arquitectura
Este directorio contiene varios archivos independientes de la arquitectura que no requieren un
subdirectorio separado en /usr/share.

Los siguientes archivos, o enlaces simbólicos a archivos, deben estar en /usr/share/misc, si el
ascii Tabla de juego de caracteres ASCII (opcional)
termcap Base de datos de capacidad de terminal (opcional)
termcap.db Base de datos de capacidades de terminal (opcional)
Otros archivos (específicos de la aplicación) pueden aparecer aquí, pero un distribuidor puede
colocarlos en /usr/lib a su discreción. 15 16
4.11.8. /usr/share/ppd : Definiciones de impresora (opcional)

/usr/share/ppd contiene archivos de definición de impresora PostScript (PPD), que se utilizan
como descripciones de controladores de impresora de muchos sistemas de impresión. Los archivos
PPD se pueden colocar en este directorio o en un subdirectorio.
15
Algunos de estos archivos incluyen: 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.
16
Históricamente, el archivo magic se colocaba en /usr/share/misc, pero las variantes modernas del comando de archivo utilizan
varios archivos y los colocan en /usr/share/file. Por motivos de compatibilidad, la distribución puede crear un enlace simbólico
en /usr/share/misc/magic, apuntando a /usr/share/file/magic.
4.11.9. /usr/share/sgml : Datos SGML (opcional)
/usr/share/sgml contiene archivos independientes de la arquitectura utilizados por las
aplicaciones SGML, como catálogos ordinarios (no los centralizados, véase /etc/sgml), DTD,
entidades u hojas de estilo.

Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /usr/share/sgml,
si el correspondiente subsistema está instalado:
docbook Docbook DDT (opcional)
tei tei DTD (opcional)
html html DTD (opcional)
mathml mathml DTD (opcional)
Otros archivos que no son específicos de una DTD determinada pueden residir en su propio subdirectorio.
4.11.10. /usr/share/xml : Datos XML (opcional)

/usr/share/xml contiene archivos independientes de la arquitectura utilizados por
aplicaciones XML, como catálogos (no los centralizados, véase /etc/sgml), DTDs, entidades o
hojas de estilo.

Los siguientes directorios, o vínculos simbólicos a directorios, deben estar en /usr/share/xml,
si el correspondiente subsistema está instalado:
docbook Docbook XML DDT (opcional)
xhtml XHTML DTD (opcional)
mathml MathML DTD (opcional)
4.12. /usr/src : Código fuente (opcional)

4.12.1. Propósito
El código fuente se puede colocar en este subdirectorio, solo para fines de referencia. 17
17
Por lo general, la fuente no debe construirse dentro de esta jerarquía
Capítulo 5. La jerarquía /var
5.1. Propósito
/var contiene archivos de datos variables. Esto incluye archivos y directorios de spool, datos
administrativos y de registro, archivos transitorios y temporales.
Algunas partes de /var no se pueden compartir entre diferentes sistemas. Por ejemplo,
/var/log,/var/lock y /var/run. Otras partes pueden ser compartidas, en particular
/var/mail, /var/cache/man, /var/cache/fonts y /var/spool/news.
/var se especifica aquí para que sea posible montar /usr como de solo lectura. Todo lo que una
vez entró en /usr y que se escribió durante la operación del sistema (a diferencia de la instalación
y el mantenimiento del software) debe estar en /var.
Si /var no se puede crear en una partición separada, a menudo es preferible mover /var fuera
de la partición raíz a la partición /usr. (Esto se hace a veces para reducir el tamaño de la partición
raíz o cuando el espacio es bajo en la partición raíz.) Sin embargo, /var no debe estar vinculado a
/usr porque esto dificulta la separación de /usr y /var y es probable que cree un conflicto de
nombres. En su lugar, vincule /var a /usr/var.
Por lo general, las aplicaciones no deben agregar directorios al nivel superior de /var. Dichos
directorios sólo deben agregarse si tienen alguna implicación en todo el sistema, y en consulta con
la lista de correo de FHS.
5.2. Requisitos
Los siguientes directorios, o enlaces simbólicos a directorios, son necesarios en /var:
caché Datos de caché de aplicaciones
lib Información de estado variable
local Datos variables para /usr/local
lock Bloqueo de archivos
log Archivos de registro y directorios
opt Datos variables para /opt
run Datos relevantes para los procesos en ejecución
spool Datos spool de aplicación
tmp Archivos temporales conservados entre reinicios del sistema
Varios directorios están "reservados" en el sentido de que no deben ser utilizados arbitrariamente
por algunas nuevas aplicaciones, ya que entrarían en conflicto con la práctica histórica y/o local.
Estos son:
/var/backups
/var/cron
/var/msgs
/var/preserve
Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /var, si el
account Procesar registros contables (opcional)
crash Volcado por caída del sistema (opcional)
games Datos de juego variables (opcional)
mail archivos de buzón de usuario de correo (opcional)
yp Archivos de base de datos del Servicio de información de red (NIS) (opcional)
5.4. /var/account : Procesar registros contables (opcional)

5.4.1. Propósito
Este directorio contiene el registro de contabilidad del proceso activo actual y los datos de uso del
proceso compuesto (como se usa en algunos sistemas tipo UNIX por lastcomm y sa).
5.5. /var/cache : Datos de caché de aplicaciones

5.5.1. Propósito
/var/cache está diseñado para datos almacenados en caché de aplicaciones. Estos datos se
generan localmente como resultado de cálculos o E/S que requieren mucho tiempo. La aplicación
debe ser capaz de regenerar o restaurar los datos. A diferencia de /var/spool, los archivos
almacenados en caché se pueden eliminar sin pérdida de datos. Los datos deben permanecer
válidos entre invocaciones de la aplicación y el reinicio del sistema.
Los archivos ubicados en /var/cache pueden expirar de una manera específica de la aplicación,
por el sistema administrador, o ambos. La aplicación siempre debe ser capaz de recuperarse de la
eliminación manual de estos archivos (generalmente debido a una escasez de espacio en disco). No
se hacen otros requisitos sobre el formato de datos de la directorios de caché.
Fundamento
La existencia de un directorio independiente para los datos almacenados en caché permite a los
administradores del sistema establecer políticas de disco y copia de seguridad de otros directorios
de /var.

fonts Fuentes generadas localmente (opcional)
man Páginas de manuales con formato local (opcional)
www Proxy WWW o datos de caché (opcional)
<package> Datos de caché específicos del paquete (opcional)
5.5.3. /var/cache/fonts : Fuentes generadas localmente (opcional)
5.5.3.1. Propósito
El directorio /var/cache/fonts debe utilizarse para almacenar cualquier fuente creada
dinámicamente. En particular, todas las fuentes que son generadas automáticamente por mktexpk
deben estar ubicadas en subdirectorios con el nombre apropiado de /var/cache/fonts.1

Otras fuentes creadas dinámicamente también se pueden colocar en este árbol, bajo subdirectorios
debidamente nombrados de /var/cache/fonts.
5.5.4. /var/cache/man : Páginas de manuales con formato local (opcional)
5.5.4.1. Propósito
Este directorio proporciona una ubicación estándar para los sitios que proporcionan una partición
/usr de solo lectura, pero que desean permitir el almacenamiento en caché de páginas de manual
con formato local. Sitios que montan /usr como modificables (por ejemplo, instalaciones de un
solo usuario) puede optar por no utilizar /var/cache/man y puede escribir páginas de manual
formateadas en los directorios cat <section> en /usr/share/man directamente.
Recomendamos que la mayoría de los sitios utilicen una de las siguientes opciones en su lugar:
• Formatee previamente todas las páginas del manual junto con las versiones sin formato.
• No permita el almacenamiento en caché de las páginas de manual formateadas, y requiera que se

realice el formateo cada vez que se abre una página de manual.
• Permitir el almacenamiento en caché local de páginas de manual formateadas en

/var/cache/man.
La estructura de /var/cache/man debe reflejar tanto el hecho de varias jerarquías de páginas

de manual como la posibilidad de soporte de múltiples idiomas.
Dada una página de manual sin formato que normalmente aparece en <path>/man/<locale>
/man<section>, el directorio en el que se colocan las páginas de comando man formateadas
es: /var/cache/man/<catpath>/<locale>/cat<section>, donde <catpath> se
deriva de <path> eliminando cualquier usr inicial y/o componentes de nombre de ruta de
recurso compartido final. (Tenga en cuenta que es posible que falte el componente <locale>).2
Las páginas de manual escritas en /var/cache/man pueden eventualmente transferirse a los

directorios preformateados apropiados en la jerarquía de manuales de origen o expirar; del mismo
modo las páginas de manual con formato en la jerarquía del manual de origen pueden expirar si no
se accede a ellos durante un período de tiempo.
1
Este estándar no incorpora actualmente la estructura de directorios de TeX (un documento que describe el diseño de archivos y
directorios TeX), pero puede ser una lectura útil. Se encuentra en ftp://ctan.tug.org/tex/
2
Por ejemplo, /usr/share/man/man1/ls.1 tiene el formato /var/cache/man/cat1/ls.1 y
/usr/X11R6/man/<locale>/man3/XtClass.3x en /var/cache/man/X11R6/<locale>/cat3/XtClass.3x.
Si las páginas de manual preformateadas vienen con un sistema en un medio de solo lectura (un
CD-ROM, por ejemplo), deben instalarse en la jerarquía man de origen (por ejemplo,
/usr/share/man/cat<section>). /var/cache/man se reserva como una caché de
escritura para las páginas de manual formateadas.
Fundamento
La versión 1.2 de este estándar especificó /var/catman para esta jerarquía. La ruta se ha movido
en /var/cache para reflejar mejor la naturaleza dinámica de las páginas de manual con formato.
El nombre del directorio se ha cambiado a man para permitir la mejora de la jerarquía para incluir
formatos con procesamiento distintos de "cat", como PostScript, HTML o DVI.
5.6. /var/crash : Volcados de bloqueo del sistema (opcional)

5.6.1. Propósito
Este directorio contiene volcados de memoria por caída del sistema. A partir de la fecha de esta
versión del estándar, los volcados por caída del sistema no eran compatibles con Linux, pero
pueden ser compatibles con otros sistemas que puedan cumplir con el FHS.
5.7. /var/games : Datos de juego variables (opcional)

5.7.1. Propósito
Cualquier dato variable relacionado con los juegos en /usr debe colocarse aquí. /var/games
debe contener los datos variables encontrados previamente en /usr; datos estáticos, como el
texto de ayuda, descripciones de nivel, etc., deben permanecer en otro lugare, como
/usr/share/games.
Fundamento
/var/games ha recibido una jerarquía propia, en lugar de dejarla debajo de /var/lib como en
la versión 1.2 de este estándar. La separación permite el control local de las estrategias de copia de
seguridad, los permisos y el uso del disco, así como permitir el uso compartido entre hosts y reducir
el desorden en /var/lib. Además, /var/games es la ruta utilizada tradicionalmente por BSD.
5.8. /var/lib : Información de estado variable

5.8.1. Propósito
Esta jerarquía contiene información de estado perteneciente a una aplicación o al sistema.
La información de estado son datos que los programas modifican mientras se ejecutan, y que
pertenecen a un host específico. Los usuarios nunca deben modificar archivos en /var/lib para
configurar el funcionamiento de un paquete, y la jerarquía de archivos específica utilizada para
almacenar los datos no deben exponerse a usuarios regulares. 3
3
Los datos con estructura del sistema de archivos expuesto deben almacenarse en /srv.
La información de estado se utiliza generalmente para preservar la condición de una aplicación (o un grupo de
aplicaciones interrelacionadas) entre invocaciones y entre diferentes instancias de la misma aplicación. La
información de estado generalmente debe seguir siendo válida después de un reinicio, no debe estar
registrando la salida, y no debe ser datos en spool.
Una aplicación (o un grupo de aplicaciones interrelacionadas) debe utilizar un subdirectorio de /var/lib

para sus datos. Hay un subdirectorio requerido, /var/lib/misc, que está destinado a archivos de estado
que no necesitan un subdirectorio; los demás subdirectorios sólo deben estar presentes si se incluye la
aplicación en cuestión en la distribución. 4
/var/lib/<name> es la ubicación que se debe utilizar para todo el soporte de empaquetado de

distribución. Las diferentes distribuciones pueden utilizar diferentes nombres, por supuesto.
5.8.2. Requisitos
Los siguientes directorios, o enlaces simbólicos a directorios, son necesarios en /var/lib:
misc Varios datos de estado

Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /var/lib, si el
<editor> Estado y archivos de copia de seguridad del editor (opcional)
<pkgtool> Empaquetar archivos de soporte (opcional)
<paquete> Datos de estado para paquetes y subsistemas (opcional)
color Información de gestión del color (opcional)
hwclock Directorio de estado para hwclock (opcional)
xdm Datos variables del administrador de visualización X (opcional)
5.8.4. /var/lib/<editor> : Estado y archivos de copia de seguridad

del editor (opcional)
5.8.4.1. Propósito
Estos directorios contienen archivos guardados generados por cualquier terminación inesperada de un editor
(por ejemplo, elvis, jove, nvi).
Es posible que otros editores no requieran un directorio para los archivos de recuperación de fallos, pero
pueden requerir un lugar bien definido para almacenar otra información mientras se ejecuta el editor. Esta
información debe almacenarse en un subdirectorio bajo /var/lib (por ejemplo, GNU Emacs colocaría los
archivos de bloqueo en /var/lib/emacs/lock).
Los editores futuros pueden requerir información de estado adicional más allá de los archivos de recuperación
de fallos y los archivos de bloqueo, esta información también debe colocarse en /var/lib/<editor>.
4
Una diferencia importante entre esta versión de este estándar y las anteriores es que las aplicaciones ahora están obligadas a utilizar
un subdirectorio de /var/lib.
Fundamento
Las versiones anteriores de Linux, así como todos los proveedores comerciales, utilizan /var/preserve
para vi o su Clones. Sin embargo, cada editor utiliza su propio formato para estos archivos de recuperación de
fallos, por lo que se necesita un directorio para cada editor.
Los archivos de bloqueo específicos del editor suelen ser muy diferentes de los archivos de bloqueo de
recursos o dispositivos que son almacenados en /var/lock y, por lo tanto, se almacenan en /var/lib.
5.8.5. /var/lib/color : Información de gestión del color (opcional)

5.8.5.1. Propósito
Este directorio es el hogar de los archivos de administración de color ICC instalados dinámicamente. Este
directorio tendrá las mismas reglas que el directorio /usr/share/color.
5.8.6. /var/lib/hwclock : Directorio de estado para hwclock (opcional)

5.8.6.1. Propósito
Este directorio contiene el archivo /var/lib/hwclock/adjtime.
Fundamento
En FHS 2.1, este archivo era /etc/adjtime, pero a medida que hwclock lo actualiza, obviamente era
Incorrecta.
5.8.7. /var/lib/misc : Datos variables varios

5.8.7.1. Propósito
Este directorio contiene datos variables que no se encuentran en un subdirectorio en /var/lib. Debe
utilizar nombres relativamente únicos en este directorio para evitar conflictos de espacio de nombres. 5
5.9. /var/lock : Bloquear archivos

5.9.1. Propósito
Los archivos de bloqueo deben almacenarse dentro de la estructura de directorios /var/lock.
Los archivos de bloqueo para dispositivos y otros recursos compartidos por varias aplicaciones, como los
archivos de bloqueo de dispositivo en serie que se encontraron originalmente en /usr/spool/locks o
/usr/spool/uucp, ahora deben ser almacenado en /var/lock. La convención de nomenclatura debe
usarse es "LCK." seguida del nombre base del dispositivo. Por ejemplo, para bloquear /dev/ttyS0 se crearía
el archivo "LCK. ttyS0". 6
El formato utilizado para el contenido de estos archivos de bloqueo debe ser el formato de archivo de bloqueo
HDB UUCP. El formato HDB es para almacenar el identificador de proceso (PID) como un número decimal ASCII
de diez bytes, con una línea nueva final. Por ejemplo, si el proceso 1230 contiene un archivo de bloqueo,
contendrá los once caracteres: espacio, espacio, espacio, espacio, espacio, espacio, uno, dos, tres, cero y
nueva línea.
5
Esta jerarquía debe contener archivos almacenados en /var/db en las versiones actuales BSD. Estos incluyen locate.database
y mountdtab, y la(s) base(s) de datos de símbolos del kernel.
6
Entonces, cualquier cosa que desee utilizar /dev/ttyS0 puede leer el archivo de bloqueo y actuar en consecuencia (todos los
bloqueos en /var/lock deben ser legibles para todo el mundo).
5.10. /var/log : Archivos de registro y directorios
5.10.1. Propósito
Este directorio contiene varios archivos de registro. La mayoría de los registros deben escribirse en
este directorio o en un Subdirectorio.

Los siguientes archivos, o enlaces simbólicos a archivos, deben estar en /var/log, si el
lastlog Registro del último inicio de sesión de cada usuario
messages Mensajes del sistema de syslogd
wtmp Registro de todos los inicios de sesión y cierres de sesión
5.11. /var/mail : Archivos de buzón de usuario (opcional)

5.11.1. Propósito
La cola de correo debe ser accesible a través de /var/mail y los archivos de cola de correo deben
tener la forma <nombre de usuario>. 7
Los archivos de buzón de usuario de esta ubicación deben almacenarse en el formato de buzón
UNIX estándar.
Fundamento
La ubicación lógica de este directorio se cambió de /var/spool/mail para FHS en línea con casi
todas las distribuciones UNIX. Este cambio es importante para la interoperabilidad ya que un solo
directorio /var/mail a menudo se comparte entre varios hosts y múltiples distribuciónes UNIX
(a pesar de los problemas de bloqueo de NFS).
Es importante tener en cuenta que no hay ningún requisito para mover físicamente la cola de
correo a este Ubicación. Sin embargo, los programas y los archivos de encabezado deben cambiarse
para utilizar /var/mail.
5.12. /var/opt : Datos variables para /opt

5.12.1. Propósito
Los datos variables de los paquetes en /opt deben instalarse en /var/opt/<subdir>,donde
<subdir> es el nombre del subárbol en /opt donde se almacenan los datos estáticos de un
paquete de software complementario, excepto donde fue sustituido por otro archivo en /etc. No
se impone ninguna estructura sobre la disposición interna de /var/opt/<subdir>.
Fundamento
Consulte la justificación de /opt.
7
Tenga en cuenta que /var/mail puede ser un enlace simbólico a otro directorio.
5.13. /var/run : Datos variables en tiempo de ejecución
5.13.1. Propósito
Este directorio fue pensado una vez para los datos de información del sistema que describen el
sistema desde que se inició. Estas funciones se han movido a /run; este directorio existe para
garantizar la compatibilidad con los sistemas y software que utiliza una versión anterior de esta
especificación.
5.13.2. Requisitos
En general, los requisitos para /run también se aplicarán a /var/run. Es válido implementar
/var/run como un enlace simbólico a /run.
El archivo utmp, que almacena información sobre quién está utilizando actualmente el sistema, se
encuentra en este Directorio.
Los programas no deben tener acceso a /var/run y /run directamente, excepto para acceder a
/var/run/utmp. 8
5.14. /var/spool : Datos de la cola de la aplicaciones

5.14.1. Propósito
/var/spool contiene datos que esperan algún tipo de procesamiento posterior. Datos en
/var/spool representa el trabajo que se realizará en el futuro (por un programa, usuario o
administrador); a menudo los datos se eliminan una vez procesados. 9

Los siguientes directorios, o enlaces simbólicos a directorios, deben estar en /var/spool, si el
lpd Directorio de cola de impresión (opcional)
mqueue Cola de correo saliente (opcional)
news Directorio de cola de noticias (opcional)
rwho Archivos rwhod (opcional)
uucp Directorio de spool para UUCP (opcional)
5.14.3. /var/spool/lpd : Colas de impresión de daemon de

impresora de línea (opcional)
El archivo de bloqueo para lpd, lpd.lock, debe colocarse en /var/spool/lpd. Se sugiere que el
archivo de bloqueo para cada impresora se colocará en el directorio de cola de impresión para esa
impresora específica y se llamará bloqueo.
8
Esto es para evitar confusiones sobre dónde se encuentran los archivos transitorios. En general, un programa debe usar /var/run o
/run para acceder a estos archivos, no ambos.
9
Los archivos de bloqueo UUCP deben colocarse en /var/lock. Consulte la sección anterior sobre /var/lock.
printer Spool para una impresora específica (opcional)
5.14.4. /var/spool/rwho: Archivos Rwhod (opcional)

Este directorio contiene la información de rwhod para otros sistemas en la red local.
Fundamento
Algunas versiones de BSD utilizan /var/rwho para estos datos; dada su ubicación histórica en
/var/spool en otros sistemas y su ajuste aproximado a la definición de datos 'en cola', esta
ubicación se consideró más apropiada.
5.15. /var/tmp : Archivos temporales conservados entre reinicios

del sistema
5.15.1. Propósito
El directorio /var/tmp está disponible para programas que requieren archivos temporales o
directorios que se conservan entre los reinicios del sistema. Por lo tanto, los datos almacenados en
/var/tmp son más persistentes que los datos en /tmp.
Los archivos y directorios ubicados en /var/tmp no deben eliminarse cuando se inicia el sistema.
Aunque los datos almacenado en /var/tmp normalmente se eliminan de una manera específica
del sitio, se recomienda que se produzcan eliminaciones a un intervalo menos frecuente que /tmp.
5.16. /var/yp : Servicio de Información de Red(NIS) archivos de

base de datos (opcional)
5.16.1. Propósito
Datos variables para el Servicio de Información de Red (NIS), anteriormente conocido como Sun
Yellow Pages (YP), debe colocarse en este directorio.
Fundamento
/var/yp es el directorio estándar para los datos NIS (YP) y se utiliza casi exclusivamente en
documentación y sistemas NIS. 10
10
NIS no debe confundirse con Sun NIS+, que utiliza un directorio diferente, /var/nis.
Capítulo 6. Específico del sistema operativo
Anexo
Esta sección es para requisitos y recomendaciones adicionales que solo se aplican a un sistema
operativo específico. El material de esta sección nunca debe entrar en conflicto con el estándar
básico.
6.1. Linux
Este es el anexo del sistema operativo Linux.
6.1.1. / : Directorio root

En sistemas Linux, si el kernel está ubicado en / , recomendamos usar los
nombres vmlinux o vmlinuz ,que se han utilizado en los paquetes fuente del kernel de Linux
recientes.
6.1.2. / bin: Binarios de comandos de usuario esenciales (para

uso de todos los usuarios)
Los sistemas Linux que los requieren colocan estos archivos adicionales en /bin :
• setserial
6.1.3. / dev: Dispositivos y archivos especiales

Los siguientes dispositivos deben existir en /dev .
/dev/null Todos los datos escritos en este dispositivo se descartan. Una lectura de este
dispositivo devolverá un EOF condición.
/dev/zero Este dispositivo es una fuente de datos puestos a cero. Todos los datos escritos en este
dispositivo se descartan. Una lectura desde este dispositivo devolverá tantos bytes con el valor cero
como se solicitó.
/dev/tty Este dispositivo es sinónimo de terminal de control de un proceso. Una vez que se abre,
todas las lecturas y escrituras se comportarán como si el dispositivo terminal de control real hubiera
sido abierto.
Razón fundamental
Las versiones anteriores de FHS tenían requisitos más estrictos para /dev . También pueden existir
otros dispositivos en /dev . Los nombres de dispositivos pueden existir como enlaces simbólicos a
otros nodos de dispositivos ubicados en /dev o subdirectorios de /dev . No hay ningún requisito
con respecto a los valores numéricos mayores / menores.
6.1.4. / etc: configuración del sistema específico del host

Los sistemas Linux que lo requieren colocan estos archivos adicionales en /etc .
• lilo.conf
6.1.5. / proc: Sistema de archivos virtual de información de
proceso y kernel
El sistema de archivos /proc es el método estándar de facto de Linux para manejar la información
del proceso y del sistema, en lugar de /dev/kmem y otros métodos similares. Recomendamos
encarecidamente esto para el almacenamiento y recuperación de información del proceso, así como
otra información del kernel y de la memoria.
6.1.6. / sbin: binarios esenciales del sistema

Los sistemas Linux colocan comandos relacionados con el mantenimiento del sistema de archivos y
la administración del cargador de arranque en /sbin .
Archivos opcionales para /sbin :
• Binarios estáticos:
• ldconfig
• sln
• ssync
Static ln ( sln ) y static sync ( ssync ) son útiles cuando algo sale mal. El uso principal de sln (es
reparar enlaces simbólicos incorrectos en /lib después de una actualización mal orquestada) ya no
es una preocupación importante ahora que el programa ldconfig (generalmente ubicado
en /usr/sbin ) existe y puede actuar como guía en la actualización las librerías dinámicas. Static
ssync es útil en algunas situaciones de emergencia. Tenga en cuenta que no es necesario que sean
versiones vinculadas estáticamente del estándar ln y sync , pero pueden serlo.
El binario ldconfig es opcional para /sbin ya que un sitio puede optar por ejecutar ldconfig en el
momento del arranque, en lugar de que solo al actualizar las librerías compartidas. (No está claro si
es ventajoso ejecutar ldconfig en cada arranque). Aun así, algunas personas les gusta ldconfig por la
siguiente situación (demasiado común):
1. Acabo de eliminar /lib/<file> .
2. No puedo encontrar el nombre de la librería porque ls está vinculado dinámicamente, estoy usando
un shell que no tiene ls incorporado, y no sé si usar " echo * " como reemplazo.
3. Tengo un sln estático , pero no sé cómo llamar al enlace.
• Varios:
• ctrlaltdel
• kbdrate
Para hacer frente al hecho de que algunos teclados tienen una tasa de repetición tan alta que no se
pueden utilizar, kbdrate puede estar instalado en /sbin en algunos sistemas.
Dado que la acción predeterminada en el kernel para la combinación de teclas Ctrl-Alt-Supr es un

reinicio completo instantáneo, Por lo general, es recomendable desactivar el comportamiento antes
de montar el sistema de archivos raíz en modo lectura-escritura.
Algunas suites de inicio pueden deshabilitar Ctrl-Alt-Del, pero otras pueden requerir
el programa ctrlaltdel , que se puede instalar en /sbin en esos sistemas.
6.1.7. / sys: Sistema de archivos virtual de información del
kernel y del sistema
El sistema de archivos /sys es la ubicación donde se encuentra la información sobre dispositivos,
controladores y algunas características del kernel. expuesto. Su estructura subyacente está
determinada por el kernel de Linux particular que se esté utilizando en este momento, y no está
especificado de otra manera.
6.1.8. / usr / include: Archivos de encabezado incluidos por

programas C
Estos enlaces simbólicos son necesarios si se instala un compilador C o C ++ y solo para sistemas
que no se basan en glibc.
/usr/include/asm -> /usr/src/linux/include/asm-<arch>

/usr/include/linux -> /usr/src/linux/include/linux
6.1.9. / usr / src: código fuente

Para los sistemas basados en glibc , no existen pautas específicas para este directorio. Para los
sistemas basados en revisiones de libc de Linux anteriores de glibc , se aplican las siguientes
pautas y fundamentos:
El único código fuente que debe colocarse en una ubicación específica es el código fuente del kernel
de Linux. Está ubicado en /usr/src/linux .
Si se instala un compilador C o C ++, pero no se instala el código fuente completo del kernel de
Linux, entonces los archivos de inclusión del código fuente del kernel deben estar ubicados en estos
directorios:
/usr/src/linux/include/asm-<arch>
/usr/src/linux/include/linux
<arch> es el nombre de la arquitectura del sistema.
Nota
/usr/src/linux puede ser un enlace simbólico a un árbol de código fuente del kernel.
Razón fundamental
Es importante que los archivos de inclusión del kernel estén ubicados en /usr/src/linux y no
en /usr/include para que no haya problemas cuando los administradores del sistema actualicen
su versión del kernel por primera vez.
6.1.10. / var / spool / cron: Trabajos at y cron

Este directorio contiene los datos variables para los programas cron y at .
Capítulo 7. Apéndice
7.1. La lista de correo de FHS
La lista de correo de FHS se encuentra
en <[email protected]> (suscripción requerida como medida de
limitación de spam). Información de suscripción a listas de correo, archivos, etc. Están
en https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss [https://lists.linux-
foundation.org/mailman/listinfo/fhs-discus]
7.2. Antecedentes de la FHS

El proceso de desarrollo de una jerarquía de sistema de archivos estándar comenzó en agosto de 1993
con un esfuerzo por reestructurar la estructura de archivos y directorios de Linux. El FSSTND, un
estándar de jerarquía del sistema de archivos específico al sistema operativo Linux, se publicó el 14
de febrero de 1994. Las revisiones posteriores se publicaron el 9 de octubre de 1994 y 28 de marzo
de 1995.
A principios de 1995, el objetivo de desarrollar una versión más completa de FSSTND para abordar
no solo Linux, pero se adoptaron otros sistemas similares a UNIX con la ayuda de miembros de la
comunidad de desarrollo BSD. Como resultado, se hizo un esfuerzo concertado para centrarse en
problemas que eran generales en los sistemas similares a UNIX. En reconocimiento de esta
ampliación del alcance, el nombre del estándar se cambió a Jerarquía del sistema de archivos
Estándar o FHS para abreviar.
Los voluntarios que han contribuido ampliamente a este estándar se enumeran al final de este
documento. Esta estándar representa una opinión de consenso de esos y otros contribuyentes.
Gracias a Operaciones de red en la Universidad de California en San Diego, y luego a SourceForge,

quien nos permitió utilizar sus excelentes servidores de listas de correo durante las primeras fases de
desarrollo.
7.3. Reglas generales

Estas son algunas de las pautas que se han utilizado en el desarrollo de este estándar:
• Resolver problemas técnicos limitando las dificultades de transición.

• Hacer que la especificación sea razonablemente estable.
• Obtener la aprobación de distribuidores, desarrolladores y otros tomadores de decisiones en grupos
de desarrollo relevantes y fomentar su participación.
• Proporcionar un estándar que sea atractivo para los implementadores de diferentes sistemas
similares a UNIX.
7.4. Alcance
Este documento especifica una jerarquía de sistemas de archivos estándar para los sistemas de
archivos FHS especificando la ubicación de los archivos y directorios, y el contenido de algunos
archivos del sistema.
Este estándar ha sido diseñado para ser utilizado por integradores de sistemas, desarrolladores de
paquetes y administradores de sistemas en la construcción y mantenimiento de sistemas de archivos
compatibles con FHS. Está destinado principalmente para ser una referencia y no un tutorial sobre
cómo administrar una jerarquía de sistema de archivos conforme.
El FHS surgió de trabajos anteriores en FSSTND, un estándar de organización de sistemas de

archivos para el sistema operativo Linux. Se basa en FSSTND para abordar problemas de
interoperabilidad no solo en la comunidad de Linux, sino en un campo más amplio que incluye
sistemas operativos basados en 4.4BSD. Incorpora lecciones aprendidas en el mundo BSD y en otros
lugares sobre el soporte de múltiples arquitecturas y las demandas de redes heterogéneas.
Aunque este estándar es más completo que los intentos anteriores de estandarización de la jerarquía
del sistema de archivos, las actualizaciones periódicas pueden ser necesarias a medida que cambian
los requisitos en relación con la tecnología emergente. También es posible que se descubran mejores
soluciones a los problemas aquí abordados, de modo que nuestras soluciones ya no serán las mejores
soluciones posibles. Es posible que se publiquen borradores suplementarios además de las
actualizaciones periódicas de este documento. Sin embargo, un objetivo específico es la
compatibilidad con versiones anteriores de una versión de este documento a la siguiente.
Los comentarios relacionados con esta norma son bienvenidos. Cualquier comentario o sugerencia de
cambios puede dirigirse a la lista de correo de FHS, o archivados como errores, o ambos. Se deben
archivar comentarios tipográficos o gramaticales. como errores. El rastreador de errores está
en http://bugs.linuxfoundation.org ; use la categoría FHS.
Antes de enviar un correo a la lista de correo, se solicita que primero eche un vistazo a los archivos
de la lista de correo para evitar la repetición excesiva de temas antiguos.
En ocasiones, pueden surgir preguntas sobre cómo interpretar los elementos de este documento. Si
tienes necesidad de una aclaración, comunícate con la lista de correo de FHS. Dado que esta norma
representa un consenso de muchos participantes, es importante asegurarse de que cualquier
interpretación también represente su opinión colectiva. Por esta razón, es posible que no sea posible
proporcionar una respuesta inmediata a menos que la consulta haya sido tema de discusión previa.
7.5. Expresiones de gratitud

Los desarrolladores de FHS desean agradecer a los desarrolladores, administradores de sistemas y
usuarios cuyas aportaciones fueron esenciales para este estándar. Deseamos agradecer a cada uno de
los colaboradores que ayudaron a escribir, compilar, y componer este estándar.
El Grupo FHS también desea agradecer a los desarrolladores de Linux que apoyaron el FSSTND, el
predecesor a este estándar. Si no hubieran demostrado que el FSSTND era beneficioso, el FHS nunca
podría haber evolucionado.
7.6. Colaboradores
Brandon S. Allbery Thomas Sippel-Dau Lennart Poettering Jeff Licquia
John A. Martin Rik Faith Fred N. van Kempen Russell oxidado
Mike Sangrey Ian Murdock Ian Jackson Christopher Yeoh
Keith Bostic Theodore Ts'o Daniel Quinlan
Ian McCloghrie Karl Goetz Bernd Warken
David H. Silber David C. Niemi Andreas Jaeger
Drew Eckhardt Stephen Tweedie Eric S. Raymond
Chris Metcalf Stephen Harris Mats Wichmann

Filesystem Hierarchy Standard FHS-3.0 - ESP

Cargado por

Copyright:

Formatos disponibles

Filesystem Hierarchy Standard FHS-3.0 - ESP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Filesystem Hierarchy Standard FHS-3.0 - ESP

Cargado por

Copyright:

Formatos disponibles

Capítulo 1.

• Software para predecir la ubicación de los archivos y directorios instalados, y

• Especificar principios rectores para cada área del sistema de archivos,

Es posible definir dos distinciones independientes entre archivos: compartibles vs no compartibles,

Esto facilita el almacenamiento de archivos con diferentes características de uso en diferentes

Los archivos "variables" son archivos que no son estáticos.

• Ocasionalmente se monta desde medios muy pequeños.

Cada directorio mencionado anteriormente se especifica en detalle en subsecciones separadas a

3.3. Opciones específicas

Cada directorio mencionado anteriormente se especifica en detalle en subsecciones separadas a

Los siguientes comandos, o enlaces simbólicos a comandos, son necesarios en /bin:

cat Utilidad para concatenar archivos a salida estándar

Los comandos [ y test deben colocarse juntos en /bin o /usr/bin.

3.4.3. Opciones específicas

/bin/csh puede ser un vínculo simbólico a /bin/tcsh o /usr/bin/tcsh.

3.5. /boot : Archivos estáticos del gestor de arranque

3.5.2. Opciones específicas

3.6. /dev : Archivos de dispositivo

3.7. /etc : Configuración del sistema específica del Host

Se recomienda que los archivos se almacenen en subdirectorios de /etc en lugar de directamente

"Binario ejecutable" en este contexto se refiere a código de máquina directa o pseudocódigo no

Los siguientes directorios, o enlaces simbólicos a directorios son necesarios en /etc:

Opt Configuración para /opt

3.7.3. Opciones específicas

X11 Configuración para el sistema X Window (opcional)

mtab no se ajusta a la naturaleza estática de /etc: se exceptúa por razones históricas. 4

3.7.5. /etc/X11 : Configuración para el sistema X Window (opcional)

3.7.5.2. Opciones específicas

3.7.7. /etc/xml : Archivos de configuración para XML (opcional)

3.8. /home : Directorios de inicio de usuario (opcional)

3.9. /lib : Librerías compartidas esenciales y Módulos kernel

3.10. /lib<qual> : Formato alternativo esencial de librerías

3.11.2. Opciones específicas

3.12. /mnt : Punto de montaje para un sistema de archivos

Los directorios /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib y

La estructura de los directorios debajo de /opt/<provider> se deja en manos del

3.14. /root : Directorio de inicio para el usuario root (opcional)

Los siguientes comandos, o enlaces simbólicos a comandos, son necesarios en /sbin:

3.16.3. Opciones específicas

4.3. Opciones específicas

/usr/spool -> /var/spool

4.4.3. Opciones específicas

4.5. /usr/include : Directorio para archivos de inclusión

4.5.2. Opciones específicas

4.6.2. Opciones específicas

4.7. /usr/libexec : Binarios dirigidos por otros programas

4.9. /usr/local : Jerarquía local

El software instalado localmente debe colocarse dentro de /usr/local en lugar de /usr a

4.9.3. Opciones específicas

Si el directorio /usr/share/color existe como se especifica en este documento, entonces el

4.9.4. /usr/local/share : Jerarquía Independiente de la

4.10. /usr/sbin : Binarios del sistema estándar no esenciales

4.11. /usr/share : Datos Independientes de la arquitectura

4.11.3. Opciones específicas

Se recomienda colocar aquí directorios independientes de la arquitectura y específicos de la

4.11.4.2. Opciones específicas

4.11.5. /usr/share/dict : Listas de palabras (opcional)

4.11.5.2. Opciones específicas

Otras listas de palabras deben incluirse aquí, si están presentes.