Linux Filesystem Structure

1. Overview

Linux has a unique filesystem structure. Unlike Microsoft Windows operating systems, which commonly use drive letters like C:\ or D:\, Linux follows a single-rooted tree structure. Fundamentally, every file and directory connects to the root, /. Moreover, even the Filesystem Hierarchy Standard (FHS) differs slightly among different Linux flavours.

In this tutorial, we’ll see the filesystem organization in Ubuntu 24.04 Linux. Also, we’ll try to go deeper into each directory with practical examples.

Eventually, the above approach will help us understand the types of files in each directory and their importance in the overall system.

2. Background and Context

Before we start exploring the Linux filesystem, let’s briefly see how the filesystem evolved.

Linux distributions used to have their own way of working with the directory layout. As a result, this started creating problems.

The Linux Filesystem Structure (FSSTND) document was created to unify filesystem layouts. Since its release, most distributors have adopted it to standardize their system layout. Eventually, this greatly improved consistency and usability for Linux users.

Yet, although Linux and macOS share similarities in their file structure from UNIX, there isn’t a /proc directory, for example, on macOS. Further, the user’s home directory goes by the name /Users on macOS.

Still, in Linux, documentation and logging are often centralized:

• docs go to /usr/share/doc/[program]
• manual pages to /usr/share/man/man1–man9
• info pages to /usr/share/info
• log files to /var/log
  

As a result, the above centralized approach makes it easier for users to find specific types of files.

3. Linux Filesystem Hierarchy Standard (FHS)

The Linux filesystem hierarchy has different types of directories. Each directory has its own role. This way, we can usually understand Linux directories easily even in a real-world environment.

To make the concept simple, we’ve grouped the directories based on their primary purpose.

4. Essential System Binaries and Libraries

In this context, binaries are small programs that help Linux do basic jobs. For example, commands like ls, cp, and mkdir are binaries. These tools are needed even before the system fully starts.

Next, libraries are like helpers for the above binary tools. They contain small code snippets and functions that provide extra features, like doing math, talking to hardware, or printing text. Eventually, binaries call on them as needed.

Notably, on the latest Linux systems, we can often find both directories under /usr.

Let’s see the main directories included in this category.

4.1. /bin

Generally, /bin has common programs for both the root and standard users. So, here we can find general commands like cp, ls, and shells like bash, csh, and similar. These are essential binaries. As a result, they are required in single-user mode and early boot.

In summary, command binaries like ls, cp, sh, and cat live in /bin so that basic operations work even if /usr is unavailable. On many distributions like Ubuntu, /bin now links to /usr/bin.

4.2. /sbin

/sbin keeps system administration commands and utilities for system recovery, booting, and similar. For example, it stores commands like fdisk, mkfs, and fsck. The root user typically employs these for system management.

4.3. /lib

The /lib directory keeps the essential shared libraries for programs in /bin, /sbin, and /usr/bin.

4.4. /lib64

The /lib64 directory is similar to /lib but designed for 64-bit systems. Also, on some systems, we can see a separate /lib32 directory. This separation ensures that both 32-bit and 64-bit applications can coexist and function correctly.

5. System Configuration (/etc)

In Linux, /etc is where the system keeps all the configuration files. These files set the system-wide behavior for programs.

The /etc directory contains files for system and third-party programs:

• network settings in /etc/hostname, /etc/hosts, and others
• user account settings go in /etc/passwd and /etc/shadow
• system services files are in /etc/systemd/system.conf, /etc/sysctl.conf

For example, programs like Apache or Nginx store their settings in /etc/apache2/apache2.conf or /etc/mysql/conf.d/mysql.cnf

Basically, if a program needs to run a certain way, its config is probably in /etc.

6. User Data and Personal Files (/home)

The /home directory is meant to save the personal space of each user. It means each user account receives a subdirectory here.

For example, if a username is Baeldung, it may get a home directory like /home/baeldung.

Eventually, all the user-related personal files, documents, settings, and application-specific configurations should go in the /home subdirectory.

The only exception is the root user, which has its own separate home at /root.

7. User Programs and Shared Data (/usr)

In /usr, we generally find user-related programs and data. The data content in /usr is vast:

• non-essential user binaries
• documentation for binaries
• libraries
• header files

Files in /usr are often read-only. As a result, programs can’t write their log files here. The log files are thus put in the /var directory.

Let’s take a look at a few important directories in /usr.

7.1. /usr/bin

/usr/bin holds most of the binaries on the system. The executables here are pretty varied. For example, we can find programs like vi, gcc, gnome-session, and other user-related programs.

On some systems, we can use the package manager to see which packages installed files under this directory:

$ dpkg -S /usr/bin/io*
util-linux: /usr/bin/ionice
sysstat: /usr...

Thus, we use dpkg to see packages that installed a binary in /usr/bin.

7.2. /usr/share/doc

/usr/share/doc is the go-to place for documentation. We can find general program files like copyright, Readme, changelogs, and others.

For example, we can see the content of the copyright file for trash-cli:

$ cat /usr/share/doc/trash-cli/copyright | head
Format: https://www.debian.org/doc/packaging...
Upstream-Name: trash-cli
Source: https://github.com/...
...

In the same way, we can expect to find other documents here.

7.3. /usr/include

/usr/include holds header files. Generally, we might need them if we’re compiling programs from source.

Notably, this location doesn’t hold the kernel headers.

7.4. /usr/lib and /usr/lib64

/usr/lib and /usr/lib64 store shared libraries. On newer systems, we might find two /lib directories:

• /lib: for 32-bit programs
• /lib64: for 64-bit programs

The shared libraries help programs run without having to rewrite common code.

7.5. /usr/sbin

The /usr/sbin directory often contains tools used for system administration.

For example, we find system binaries like adduser, addgroup, add-shell, and similar:

$ dpkg -S /usr/sbin/add*
...
adduser: /usr/sbin/addgroup
...

Moreover, programs in /usr/sbin need root user permission to run.

7.6. /usr/local

In the /usr/local directory, the system administrator installs applications at the local level. This is similar to /opt. However, the applications installed here should follow the conventional UNIX rules for the directory layout.

8. Variable Data Files (/var)

The /var directory is the home to variable data files. These files change frequently while the system runs. Normally, we can find log files, email inboxes, databases, and caches here.

There are several common subdirectories under /var. Let’s explore a few important ones.

8.1. /var/log

/var/log is the main location where system and application logs are written. However, some applications might also write to other places:

• /opt/appname/logs/
• /home/username/logs/
• /tmp/appname.log

In the same way, we can see system logs under /var/log/journal. Also, if we have a central logging mechanism, we can’t see logs locally at all. Indeed, application developers may decide where to put the logs.

In short, while /var/log is the go-to place, logs can and often do land elsewhere.

8.2. /var/lib

/var/lib keeps the application data that changes over time. The data saved here may include certificates, databases, and similar.

For example, the /var/lib/dpkg keeps track of installed packages on the system.

8.3. /var/cache

/var/cache stores cache data, or simply temporary data of applications. For example, we can find old versions of installed software inside /var/cache/apt/archives/:

$ ls /var/cache/apt/archives/
...
brave-browser_1.77.101_...
brave-browser_1.78.94_...
...

For instance, on a YUM-based system, we can find the package cache in /var/cache/yum.

8.4. /var/run

The /var/run directory is now symlinked to /run. Linux uses /run to take note of the system info when we turn on the system.

8.5. /var/opt

The applications installed in /opt put their variable data inside /opt/var/app.

8.6. /var/tmp

/var/tmp is also for temporary files. However, unlike /tmp, files here aren’t auto-deleted when we reboot the system.

9. Temporary Files (/tmp)

Temporary files created by the system and users are placed in /tmp. When the system reboots, the files are cleared.

10. Device and Kernel Information (/dev)

/dev holds device or special files. A Linux system uses them to talk to hardware or virtual devices.

For example, /dev/sda is a file that represents a hard drive.

In the same way, when we plug in a USB drive, a new file appears or becomes accessible under /dev. The file name is often like /dev/sdb or /dev/sdc.

In fact, /dev also holds entries for other hardware:

• /dev/cdrom for the CD/DVD drive
• /dev/tty and /dev/tty0, and similar for terminals
• /dev/null, a trash can for data
• /dev/random for generating random numbers, often for the purposes of security

Basically, Linux lets us talk to hardware by reading from or writing to /dev files.

For instance, to make a bootable USB drive, we might run dd with the specific /dev file:

$ sudo dd if=linux.iso of=/dev/sdb bs=4M

Thus, /dev holds all the important files that deal with devices.

11. Boot Loader Files (/boot)

As the name suggests, /boot contains boot loader files. For example, these files can be the kernel initrd, vmlinux, grub files, and others.

Notably, this directory is usually a mount point for a separate boot partition, as recommended by the best practices.

12. Mount Points (/media, /mnt)

The /mnt location is usually a place to temporarily mount filesystems such as NFS shares.

For example, we can mount a shared network drive:

$ mount www.example.com:/nfs/share/ /mnt/

On the other hand, /media is where Linux automatically mounts removable media when we plug them in. These devices can be USB drives, SD cards, and DVDs.

13. Service Data (/srv)

/srv is for storing data that’s shared by services running on the system. This data is made available to other users or computers over a network.

For example, the data here can be Web pages for a website that can go in /srv/www, FTP files we want to share that can go in /srv/ftp, and similar.

So, if someone visits a hosted website or FTP server, they might be getting files from /srv. In practice, this directory might often only contain symlinks.

14. Special Purpose Directories (/opt)

Now, /opt, which stands for optional, is used for third-party apps or data that we install manually and aren’t part of the main system.

For example, we can store a custom application in /opt:

$ sudo mkdir /opt/ourapp
$ sudo tar -xzvf ourapp.tar.gz -C /opt/ourapp

Later, we can run the app from /opt/ourapp. Also, if we want to remove it, we delete it from /opt. This keeps extra apps separate from the rest of the system.

15. Virtual Filesystem (/proc)

Critically, /proc is a special, virtual filesystem. It shows detailed information about the system and all running processes.

For example, we can see the details of the CPU as:

$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 142
model name	: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
...

In the same way, we can use the meminfo command to see the RAM usage, as extracted from the relevant virtual file.

Further, every running program has a directory in /proc named by its process ID (PID), such as /proc/1234.

So, if a program has PID 4762, we can check its status:

$ cat /proc/4762/status
Name:	chrome_crashpad
Umask:	0002
State:	S (sleeping)
Tgid:	4762
Ngid:	0
Pid:	4762
PPid:	2095
...

Unlike regular directories, /proc doesn’t contain files stored on the main system storage. Instead, the kernel creates and updates the /proc files and directories in real time.

16. Why Is Linux Designed This Way?

The filesystem structure might look complex at first. However, Linux has a flexible and modular design, so it’s actually very logical:

• each directory has a job
• system files go in one place, user programs in another, and temporary files somewhere else
• permission sets restrict access at different levels

As a result, data is stored in a fairly simple and easily manageable way. Also, Linux borrows ideas from UNIX, which is why there are clear boundaries between user files and system files.

The design also makes automation easier. Tools and scripts can predict where files could or should be.

17. Distro-Specific Variations

Linux systems don’t always stick to the same rules of the FHS guidelines. This is due to many reasons:

• different design ideas
• system requirements
• user preferences

As an example, Debian and Ubuntu use /etc/apt/ for package management settings. Yet, Red Hat, CentOS, and Fedora prefer /etc/yum.repos.d/ for repository configs.

There are other differences, but the FHS mostly enables users and administrators to get a handle on the vast data landscape.

18. Conclusion

In this article, we saw the purpose of each directory in Linux as viewed from the Filesystem Hierarchy Standard (FHS).

In summary, the Linux filesystem hierarchy is a tree-like structure. Understanding this hierarchy ensures efficient administration and troubleshooting.