The File System

The Linux file system hierarchy is a well-organized, tree-like structure that provides a consistent way to access and manage files and directories. Designed to follow the Filesystem Hierarchy Standard (FHS), it ensures that users and programs can interact with the file system in a predictable and logical manner across different Linux distributions.

The Linux file system is structured as a single tree, starting from the root directory (/). Unlike Windows, which uses separate drive letters (e.g., C:\, D:), Linux integrates all storage devices and partitions into a unified directory structure.

The root directory (/) is the starting point of the hierarchy, and all files and directories are located beneath it. Each directory has a specific purpose, ensuring that system files, user files and application data are logically separated.

I’ve compiled this story by taking information from the Linux Filesystem Hierarchy Standard and editing it, subtracting about 90% of the FHS and adding my own understanding of different features of Linux. I’ve also added information from other sources, including ChatGPT.

Its a learning experience for me and a lesson in my holistic healing and teaching enterprise, for anyone interested in learning how to develop your own personal cloud of artificial intelligence. Like many of my stories, this is really just a primer, designed to help you get started in your own self-directed investigation of Linux and other free and open source software.

The ls command will show you your home directory. ls / will show you the Linux file system on your computer. Browse around in there. Be careful. Don’t change anything that you don’t understand. Just look around.

/etc is where you will find the configuration files that you can edit, to configure your applications the way you want them. Usually its best to create a ~/.config/file.d file that will override your configuration file, rather than directly editing your configuration files. That way, your configuration settings are not over-written when that application is updated.

Create a dot-files directory in your home directory, and in at least one external hard drive of some kind, where you can copy all your configuration files. Then, whenever you install Linux on a computer, you can copy and paste your configuration files into your new Linux machine.

Filesystem Hierarchy Standard

Some files are sharable, some are not. Some files are static and others are variable. Sharable files can be stored on one host and used on another. Unsharable files cannot be shared.

Static files are binaries, libraries, documentation files and others that do not change, unless you change them. Variable files are files that the operating system changes while it is operating.

Linux File System

• / (Root Directory): The top-level directory of the file system. All other directories and files branch out from here.
• /bin (Binary Files): Contains essential command-line programs needed for system operation, such as ls, cp, mv, and cat.
• /boot (Boot Files): Stores files required for booting the system, including the Linux kernel (vmlinuz) and bootloader configuration files (e.g., GRUB).
• /dev (Device Files): Contains special files representing hardware devices (e.g., sda for disks, tty for terminals). Linux treats devices as files for easy interaction.
• /etc (Configuration Files): Houses configuration files and scripts for system-wide settings, such as network configurations, user authentication and startup services.
• /home (User Home Directories): Contains personal directories for each user (e.g., /home/user1, /home/user2), storing their files, preferences and settings.
• /lib (Libraries): Holds shared libraries (.so files) required by essential system binaries in /bin and /sbin.
• /media (Removable Media): Temporary mount points for external storage devices like USB drives and CDs.
• /mnt (Mount Points): A general-purpose directory for mounting additional file systems or temporary storage.
• /opt (Optional Software): Stores additional software and third-party applications that are not part of the standard installation.
• /proc (Process Information): A virtual file system that provides real-time information about system processes and hardware (e.g., /proc/cpuinfo, /proc/meminfo).
• /root (Root User Home Directory): The home directory for the system administrator (root) user.
• /run (Runtime Files): Holds temporary files related to system services and processes created during the current boot.
• /sbin (System Binaries): Contains essential binaries used for system administration, such as fdisk, ifconfig, and shutdown.
• /srv (Service Data): Used for storing data for specific services like web servers or FTP servers.
• /sys (System Information): A virtual file system providing information about hardware and kernel-level processes.
• /tmp (Temporary Files): Used for storing files temporarily. Contents are often cleared during reboot.
• /usr (User Utilities and Applications): Contains user-space applications, libraries, and documentation. Subdirectories include:
  • /usr/bin: Non-essential user binaries.
  • /usr/lib: Libraries for user applications.
  • /usr/share: Shared data, such as icons and documentation.
  • /usr/local: Locally installed software.
• /var (Variable Data): Stores files that change frequently, such as logs (/var/log), spools (/var/spool) and temporary cache files (/var/cache).

How the Linux File System Works

All files and directories are organized under a single root (/). Devices, network resources and external drives are integrated seamlessly into the hierarchy using mount points.

• Every file and directory has three types of permissions:
  • Read (r): Allows viewing the file’s content.
  • Write (w): Allows modifying the file.
  • Execute (x): Allows executing the file or accessing a directory.
• Permissions are assigned to:
  • Owner: The user who owns the file.
  • Group: A group of users with shared access.
  • Others: All other users.

Directories like /proc and /sys are virtual file systems that provide dynamic information about the system, generated in real-time by the kernel.

Linux uses the mount command to integrate file systems into the hierarchy, such as external drives or network shares. The umount command is used to detach file systems.

Linux supports various types of file system, including:

• ext4: Default for most Linux distributions.
• XFS and Btrfs: Used for advanced features like snapshots and scalability.
• NTFS: Used for compatibility with Windows drives.

Every file and directory is represented by an inode, which stores metadata such as file permissions, ownership and timestamps. Symbolic Links (symlinks) act as shortcuts pointing to other files or directories. Hard Links create additional references to the same file, sharing the same inode.

The Linux File System Hierarchy ensures predictability across Linux distributions. It easily integrates new devices and file systems into the existing structure. Permissions and ownership help protect sensitive files. Virtual file systems like /proc provide real-time system information, without using physical storage.

The file system is a robust and logical framework that underpins the operation of Linux-based systems. By organizing files and directories in a predictable structure and leveraging powerful mechanisms like inodes, permissions and mount points, Linux provides a flexible and efficient environment for both users and administrators.

root

/ is your root filesystem. It must be able to boot, restore, recover and/or repair the system. It needs to be able to mount other file systems. It includes boot loader information, configuration files, utilities and other essential start-up data.

Keep your root filesystem as small as possible, to make it more compatible with other systems and easier to repair. /usr, /opt and /var can be located on another partition or filesystem.

boot

/boot – Contains static files of the boot loader. Everything required for the boot process is contained in /boot, except configuration files not needed at boot time and the map installer.

/boot stores data that is used before the kernel begins executing user-mode programs. The operating system kernel must be located in either / or /boot.

/efi – Sometimes EFI System Partition (ESP) is separate from /boot. On my KDE Neon system, /efi is located within the /boot directory, as in, /boot/efi. Same with Kubuntu, naturally.

http://www.linuxbase.org/betaspecs/fhs/fhs.html

bin

/bin contains essential command-line programs needed for system operation, such as ls, cp, mv, and cat. It is a sub-directory of the root directory in Linux that contains the executable (ready to run) programs necessary for booting and repairing the operating system. This is where Linux runs.

No sub-directories are allowed in /bin. It contains commands that are used by all users and are required when no other filesystem is mounted (single user mode).

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

etc

/etc is where your host (each individual computer) specific system configuration files go. Configuration files are local files, which are static and not executable binaries, and are used to control the operation of a program. This is where you can customize your Linux operating system.

/etc may contain executable scripts, such as the command scripts commonly called by systemd to start and shut down the system and to start daemon processes. “Executable binary,” in this context, refers to direct machine code or pseudocode in a non-human-readable format, such as native ELF executables.

Files should be stored in sub-directories of /etc, rather than directly in /etc. Host-specific configuration files, for application software packages installed on your computer, must be installed in the /etc/opt directory. The static data for packages are stored in a sub-tree with the same name as the package in /etc/opt.

If the package or system needs it to be in a different location in order to function properly, the configuration files may be somewhere other than /etc/opt.

Your Home Directory

/home is a site-specific filesystem, containing a home directory for each individual user. Host is the computer, users are individual users that can each specify a different configuration of the host. Programs should query for the location of the home directory, rather than assume any specific location for it.

Your file manager displays your home directory when started by default. User specific configuration files for applications, are often stored in a “dot file or .file” in your home directory. Lately, there is a .config file in your home directory and new applications usually install their configuration file in there. When configuration files are stored in the .config file, they do not need to have a dot.

Dot files are files that are not displayed by default. You can set your file browser to display them. You can display hidden files in your terminal with the command ls -a. The -a switch tells your terminal to display all files and directories.

Applications that need to create more than one .dot file should place them in a “dot directory, ie., .directory”, a sub-directory with a name starting with a ‘.’ character. Files contained in a .directory should not be .files.

Applications that you install may want to place files and directories in your home directory. They should follow the following basic structure. Some of these directories are also standardized, though more weakly, by the XDG Base Directory Specification. Additional locations for high-level user resources are defined by xdg-user-dirs.

The tilda, ~, in the following sections signifies your home directory.

~/.cache contains persistent user cache data. Applications may place non-essential data in this directory. Flushing this directory should not effect the operation of programs, other than slowing them down while they rebuild the cache. If an application finds $XDG_CACHE_HOME set, it should use the directory specified in it, instead of this directory.

~/.config contains application configuration and state files. When a new user is created, this directory will be empty or not exist at all. Applications should fall back to defaults if their configuration or state in this directory is missing. If an application finds $XDG_CONFIG_HOME set, it should use the directory specified in it, instead of this directory.

~/.local/bin – contains executables that appear in the user’s $PATH search path. Placing executables in this directory, which you cannot execute from a shell, is not recommended. They should be placed in a sub-directory of ~/.local/lib instead.

~/.local/lib contains static, private vendor data that is compatible with all architectures.

~/.local/lib/arch-id contains the location for placing public dynamic libraries.

~/.local/share contains resources shared between multiple packages, such as fonts or artwork. Usually, the precise location and format of files stored below this directory is subject to specifications that ensure interoperability. If an application finds $XDG_DATA_HOME set, it should use the directory specified in it, instead of this directory.

root

/root is the home directory for the root account. It may be determined by distribution developer or by local preference, but this is the recommended default location.

srv

/srv contains site-specific data which is served by your system. This enables users to find the location of the data files for a particular service. Its also a good place for services which require a single tree for read-only data, writable data and scripts (such as cgi scripts).

Data that only you are interested in, should go in your home directory. If you do not want the directory and file structure of the data to be exposed to your customers, it should go in /var/lib.

One way of structuring data under /srv is by protocol, as in, ftp, rsync, www and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc.

This setup will differ from host to host. Therefore, no program should rely on a specific sub-directory structure of /srv or on any data necessarily being stored in /srv. However, /srv should always exist on FHS compliant systems and should be used as the default location for such data.

tmp

/tmp must be made available for programs that require temporary files. Programs must not assume that any files or directories in /tmp are preserved between instances of the program. This is another directory, like /bin and /run, that running programs use to run.

Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.

run

/run contains system information data, describing the system since it was booted. Files under this directory must be cleared at the beginning of the boot process. Programs that use more than one run-time file can use sub-directories in /run. Users may also have sub-directories of /run.

Process identifier (PID) files must be placed in /run.

/run/log system components may place private logs in this directory. It is always writable.

/run/user contains user runtime directories for each individual user. They are usually individually mounted instances of “tmpfs”. They are always writable and flushed during reboot and whenever the user logs out.

usr

The /usr hierarchy contains vender supplied operating system resources

/usr contains shareable, read-only data. Information that is host-specific or information that changes over time, is stored elsewhere. Large software packages must not use a direct sub-directory under the /usr hierarchy.

/usr/bin contains most user commands. It is the primary directory for executable commands on your system. There cannot be any sub-directories in /usr/bin.

/usr/include contains standard include files. It is where all of the system’s general-use include files for the C programming language should be placed.

/usr/lib contains libraries for programming and packages, includes object files and libraries. It may also include internal binaries that are not intended to be executed directly by users or shell scripts.

Applications may use a single sub-directory under /usr/lib. If an application uses a sub-directory, all architecture-dependent data used exclusively by the application must be placed within that sub-directory.

Use the /usr/local hierarchy when installing software. It needs to be secured against being overwritten, when system software is updated.

/usr/share contains architecture-independent data, for all read-only architecture independent data files.

var

The /var hierarchy contains persistent, variable system data.

/var/tmp contains temporary files preserved between system reboots.

/var/yp contains Network Information Service (NIS) database files (optional).

/var contains variable data files, including spool directories and files, administrative and logging data and transient and temporary files.

Some parts of /var are not shareable between different systems. For instance, /var/log, /var/lock and /var/run are not shareable. Other parts are shareable, notably /var/mail, /var/cache/man, /var/cache/fonts and /var/spool/news.

dev

/dev – contains device files, virtual kernel and API file systems

Special or device files are located in /dev. It must contain a command named MAKEDEV, for creating devices manually.

The root directory for device nodes, usually mounted as an instance of “devtmpfs”, may be different in sand-boxed or containerized setups. The operating system kernel and systemd-udevd jointly manage this directory. Special purpose file systems may be mounted in the /dev directory.

proc

/proc is a virtual kernel file system, exposing the process list and other functionality. /proc is primarily an API for interfacing with the kernel and not a place for normal files.

sys

/sys is a virtual kernel file system, exposing discovered devices and other functionality. It is also, primarily an API for interfacing with the kernel and not a place for normal files. Special purpose virtual file systems may be mounted in this directory. /sys is usually mounted read only in containerized setups.

lib

/lib contains essential shared libraries and kernel modules, including the shared library images needed to boot the system and run the commands in the root filesystem, such as binaries in /bin and /sbin. The modules, loadable kernel modules (optional), directories or symbolic links to it, must be in /lib, if the corresponding subsystem is installed.

media

/media contains sub-directories used as mount points for removable media such as USB, DVD and zip disks.

mnt

/mnt is a mount point for temporarily mounting a filesystem. You can use it to mount a temporary filesystem as needed. It cannot be used by installation programs. A suitable temporary directory, which is not being used by the system, must be used for that. The content of /mnt is a local issue and should not affect the way any program runs.

opt

/opt contains add-on application software packages that you’ve installed.

/opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib and /opt/man are reserved for you to use. Packages may include “front-end” files that you can place (by linking or copying) in these reserved directories. The package must function normally in the absence of these reserved directories.

Variable package files, which change during normal operation, must be installed in /var/opt. Host-specific configuration files must be installed in /etc/opt.

No package files may exist outside of the /opt, /var/opt and /etc/opt hierarchies, other than the package files that must reside in specific locations within the filesystem tree, in order to function properly. For example, device lock files must be placed in /var/lock and device drivers must be located in /dev.

Generally, all data required to support a package on a system, must be present within /opt, including files intended to be copied into /etc/opt and /var/opt, as well as reserved directories in /opt.

sbin

/sbin contains system binaries essential for booting, restoring, recovering and/or repairing the system in addition to the binaries in /bin. There cannot be any subdirectories in /sbin.

Utilities used for system administration and other root-only commands, are stored in /sbin, /usr/sbin and /usr/local/sbin. System administration programs that you install, should be placed in /usr/local/sbin.

XDG Standard

XDG is a set of standards and guidelines developed by the freedesktop.org initiative to ensure consistency and interoperability between desktop environments and applications on Linux systems. XDG stands for “X Desktop Group”, reflecting its origin in standardizing graphical desktop environments.

By adhering to XDG standards, Linux desktop environments such as GNOME, KDE, XFCE and others can provide a consistent and unified user experience. These standards cover various aspects, including file placement, application menus, desktop files and MIME type handling.

XDG Base Directory Specification defines a standardized structure for storing configuration files, user data and cache files. It helps prevent clutter in the home directory and improves file organization. Environment variables determine where specific files are stored:

• XDG_CONFIG_HOME: Directory for user-specific configuration files (default: ~/.config).
• XDG_DATA_HOME: Directory for user-specific data files (default: ~/.local/share).
• XDG_CACHE_HOME: Directory for user-specific cache files (default: ~/.cache).

XDG Desktop Entry Specification defines how desktop files (~/.desktop) are structured. These files provide metadata for applications, such as their name, icon and command to execute.

• Example .desktop file:
  ini [Desktop Entry] Name=ExampleApp Exec=example-app Icon=example-icon Type=Application Categories=Utility;
• Desktop files enable applications to appear in application menus and integrate with the desktop environment.

XDG Menu Specification standardizes how applications are categorized and displayed in desktop menus. Applications are grouped into categories like “Office,” “Development,” and “Multimedia” based on their desktop files.

XDG MIME Applications Specification provides a standardized way to handle file types (MIME types) and associate them with applications. For example, associating .pdf files with a PDF viewer like Evince or Okular.

XDG Icon Theme Specification ensures consistency in application icons across different environments. Applications can use generic icon names (e.g., document-save) that map to specific themes installed on the system.

XDG Autostart Specification defines how applications can be set to start automatically when a user logs in. Applications place .desktop files in the ~/.config/autostart directory.

XDG Trash Specification standardizes how deleted files are moved to the trash directory. It ensures trash functionality works consistently across different file managers.

XDG User Directories Specification standardizes the naming and placement of common user directories, such as Documents, Pictures, and Downloads. The xdg-user-dirs tool manages these directories and allows users to customize their locations.

How XDG Works

The XDG specifications operates by providing guidelines for how applications, desktop environments and file managers interact with user data and system resources.

XDG relies heavily on environment variables to define where files and directories are located. For example, when an application needs to store configuration files, it checks XDG_CONFIG_HOME. If the variable is not set, it defaults to ~/.config.

Desktop environments use .desktop files, menus and icon themes as defined by XDG to ensure a cohesive experience. For example, when you install an application, its .desktop file is placed in /usr/share/applications (system-wide) or ~/.local/share/applications (user-specific).

MIME type information and associated applications are standardized across environments. For example, opening a .jpg file will launch the default image viewer regardless of the desktop environment.

Applications that need to run at startup place their .desktop files in the autostart directory. The desktop environment reads these files during login.

The xdg-user-dirs tool initializes and manages directories like Music and Videos. Applications reference these directories using variables like $XDG_MUSIC_DIR.

Using XDG Standards ensures applications behave predictably across different Linux desktop environments. It provides a clean and organized file structure in the home directory. It makes it easier for applications to integrate with various desktop environments. Users can override default locations and settings by modifying environment variables. The XDG Standard simplifies development by providing clear guidelines for file placement and desktop integration.

Not all applications and environments fully adhere to XDG standards, leading to inconsistencies. Some older applications may still use non-standard paths like ~/ directly. Understanding and customizing XDG directories might be challenging for beginners.

XDG standards play a vital role in creating a unified and efficient Linux desktop experience. By defining consistent guidelines for file organization, application integration and user interaction, XDG ensures that Linux systems remain flexible, organized and user-friendly. For developers and users alike, understanding and leveraging XDG specifications can lead to smoother application behavior and better system management.