File System Hierarchy

Last Updated: 2023-09-03

Linux Filesystem Hierarchy Standard (FHS). Different from macOS.

Check the list of top level folder by $ ls /:

  • /bin: binaries
  • /boot: boot loader files
  • /dev: device files
  • /etc: configuration files (originally the etcetera directory for files do not belong to other folders)
  • /home: users' home directories
  • /lib: libraries
  • /media: removable media
  • /mnt: mounted file systems
  • /opt: optional application software packages
  • /proc: virtual filesystem providing process and kernel information as files, e.g. $ cat /proc/meminfo or $ cat /proc/cpuinfo. Only available in Linux.
  • /root: root user's home directory
  • /run: run-time variable data, will be cleared at the beginning of the boot process
  • /sbin: essential system binaries, e.g. fsck, init, route
  • /srv: srv=serve, site specific data to be served by the system
  • /sys: information about devices, drivers, and some kernel features. /sys is an interface to the kernel.
  • /tmp: temporary files
  • /usr: user utilities and applications
  • /var: variable files

/bin vs /usr/bin

  • /sbin - Binaries needed for booting, low-level system repair, or maintenance (run level 1 or S)
  • /bin - Binaries needed for normal/standard system functioning at any run level.
  • /usr/bin - Application/distribution binaries meant to be accessed by locally logged in users.
  • /usr/sbin - Application/distribution binaries that support or configure stuff in /sbin.
  • /usr/share/bin - Application/distribution binaries or scripts meant to be accesed via the web, i.e. Apache web applications.

/bin and /usr/bin can be on separate disks/partitions, /bin must be on the same disk as /. /usr/bin can be on another disk.

Historically the utilities in the /bin and /sbin directories were used to mount the usr partition. This job is nowadays done by initramfs, and splitting the directories therefore no longer serves any purpose.

Recently some Linux distros are merging /bin into /usr/bin and relatedly /lib into /usr/lib. Sometimes also /sbin to /usr/bin (Arch Linux). So /usr is expected to be available at the same time as /.

Scattering utilities over different directories is no longer necessary and storing them all in /usr/bin simplifies the file system hierarchy.

Check if your system symlinked /bin:

$ ls -l /bin
lrwxrwxrwx 1 root root  /bin -> usr/bin

Add H to actually see the content of the /usr/bin

$ ls -lH /bin

/var and /run

/var: contains files to which the system writes data during the course of its operation.

  • /var/cache: cached data from application programs.
  • /var/games: variable data relating to games in /usr.
  • /var/lib: dynamic data libraries and files; state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Will survive reboots.
  • /var/lock: (usually link to /run/lock) lock files created by programs to indicate that they are using a particular file or device.
  • /var/log: log files.
  • /var/run: (usually link to /run) PIDs and other system information that is valid until the system is booted again.
  • /var/spool: mail, news and printer queues.

After systemd, /run replaces /var/run, will be cleared at the beginning of the boot process. (Why? Because in some cases /var/run isn't always available at early boot.)

  • /run: directory as a temporary filesystem (tmpfs) which stores volatile runtime data.
  • /run/lock: lock files created by programs to indicate that they are using a particular file or device.
  • /run/user/$uid: created by systemd, local to the system, only accessible by the target user, the same as $XDG_RUNTIME_DIR.

/usr vs /usr/local

/usr is for software built elsewhere and then installed on the machine (mostly from your distributions package management system)

/usr/local is for software built locally



Why mountinfo is per process (/proc/$pid/mountinfo)? Because not all processes see the same mount points. chroot is a traditional Unix feature that makes it possible to restrict processes to a subtree of the filesystem tree. A chrooted process would not see mount points outside its root. Linux takes this further with namespaces: a process can compose its own view of the filesystem by grafting subtrees around.

Under Linux, df now bases its output on the contents of /proc/self/mountinfo; entries there are listed in the order in which they were added to the current mount namespace.

$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev                                             /dev
tmpfs                                            /run
/dev/sda1                                        /
tmpfs                                            /dev/shm
tmpfs                                            /run/lock
tmpfs                                            /sys/fs/cgroup
/dev/sda15                                       /boot/efi

Kernel Image

FHS requires the Linux kernel image to be located in either / or /boot.