← Back to Developer Notes

The Linux Filesystem

Jul 21, 2026

A beginner's look at several important Linux directories and how I decided to organize the projects on my Raspberry Pi homelab.

The Linux filesystem felt a little daunting when I first started looking through it. There are a lot of top-level directories, and many of them have short names that do not immediately explain what they contain.

Once I started researching them, however, I realized that most of the directories have a fairly understandable purpose. The layout is also largely based on conventions. Following those conventions makes a system easier to understand and maintain, but there is still some flexibility depending on what the machine is being used for.

There are also several directories that I probably will not need to interact with unless I eventually work on something much deeper within the operating system. An example being the /dev where you can interact with hardware or drivers as if they were regular files which is cool but quite niche, at least with my current understanding.

Next I'll go over a few folders that seemed like they could be useful down the line:

/etc

/etc contains system-wide configuration files.

This includes configuration for the operating system, installed applications, networking tools, and services. Many of these files are plain text and can be edited directly, although changing them often requires elevated permissions.

I find it helpful to think of /etc as the place where the system's configuration lives.

/var

/var contains variable data, meaning files that are expected to change while the operating system and its services are running.

Common examples include:

  • Logs
  • Caches
  • Queues
  • Temporary application state
  • Some persistent service data

This feels like a directory I will interact with more as the homelab becomes more complex, especially when troubleshooting logs or managing services.

/home

/home contains the home directories for regular users registered on the system.

For example, my user might have a directory such as:

/home/ebarr

That directory can contain personal files, shell configuration, development projects, and other user-specific data.

It is also a common place to clone Git repositories when the code is being managed and run by a particular user.

/usr

Despite its name, /usr is not where individual users store their personal files. It contains much of the software and supporting data used by the system.

For example:

  • /usr/bin contains many executable programs.
  • /usr/lib contains libraries used by those programs.
  • /usr/share contains shared files such as documentation.
  • /usr/local is commonly used for software installed locally by the system administrator rather than through the operating system's package manager.

The distinction between /usr and /usr/local is useful because it helps separate operating-system-managed software from software installed or managed manually.

My /storage Directory

Normally, I could keep my cloned Git repositories somewhere inside my home directory. However, I installed an additional SSD in my Raspberry Pi and wanted the projects associated with the homelab to be grouped together.

I created a new top-level directory named:

/storage

This is not one of the standard Linux filesystem directories. It is a structure I intentionally added for my own homelab.

Because the Raspberry Pi now boots from the SSD, /storage resides on the SSD-backed root filesystem. I use it as the main location for the repositories and projects I develop for the homelab.

This gives me a simple rule to follow:

Anything I build for the homelab should live somewhere inside /storage.

That does not mean every file related to those projects belongs there. Service configuration may belong in /etc, logs may belong in /var, and systemd unit files should remain in their expected system directories.

The source code and repositories themselves, however, have a clear home inside /storage.

After reviewing the current layout, I did not find a reason to move anything simply for the sake of following a convention more strictly. The existing setup is understandable and working, so documenting why it is organized this way is more useful than reorganizing it without a clear benefit. Plus if I run into any issues in the future, I'll just treat it as another learning opportunity.

Reference that I recommend: This youtube video [link] was super helpful in explaning the folders in a short and direct manner. Of course it didn't go in super depth but it was the perfect introductory video