Linux Filesystem Hierarchy

Every Linux system you’ll ever touch — a laptop, a cloud server, a container — organizes its files the same fundamental way. That’s not an accident or a convention people just happen to follow. It’s a specification called the Filesystem Hierarchy Standard (FHS), and it’s the reason a sysadmin who’s never seen a particular server can still guess, correctly, where its web server logs live or where a config file should go.

Skip this chapter and you can still get things done — you’ll just be guessing at paths, copying commands you don’t understand, and occasionally putting files in places that break on the next system update. Learn it once, and every Linux system you touch afterward feels a little less unfamiliar. You don’t need to memorize but concept matters.

Everything Starts At One Root

Unlike systems that split storage across drive letters, Linux has a single tree, starting at one root directory, written as /. Every file and every other directory — no matter what physical disk it actually lives on — hangs somewhere off that one root.

    flowchart TB
    R["/"] --> BIN["/bin, /sbin"]
    R --> ETC["/etc"]
    R --> HOME["/home"]
    R --> ROOT["/root"]
    R --> VAR["/var"]
    R --> TMP["/tmp"]
    R --> USR["/usr"]
    R --> OPT["/opt"]
    R --> DEV["/dev"]
    R --> PROC["/proc"]
    R --> BOOT["/boot"]
    R --> MNT["/mnt, /media"]
  

You’ll get comfortable moving through this tree in the next chapter. For now, the goal is knowing what each major branch is for — because that’s what turns “some path I copied from a tutorial” into “a location I chose on purpose.”

The Directories That Matter Most

/etc — System Configuration

This is where nearly all system-wide configuration lives — network settings, user account definitions, service configuration, package manager sources. If a program on Linux is configurable at the system level, its config file is very likely somewhere under /etc.

Put here: configuration files for installed software and system services. Avoid: anything that isn’t configuration. /etc should never contain user data, logs, or binaries — its entire reputation as “the place to check first” depends on it staying that way.

/home — Personal User Data

Every regular user account gets a subdirectory here — /home/alice, /home/bob — for their personal files, downloads, and per-user configuration.

Put here: anything belonging to a specific person’s day-to-day use — documents, personal scripts, their own dotfiles. Avoid: shared application data or anything the whole system depends on. If a service stops working because someone cleaned out their home directory, that data was in the wrong place.

/root — The Root User’s Home

Easy to confuse with /, but unrelated — this is simply the home directory for the root account, kept separate from /home so the superuser’s files aren’t mixed in with regular users’ data (and so root still has a usable home directory even if /home lives on a separate disk that isn’t mounted yet during early boot).

Put here: nothing, generally, unless you’re intentionally working as root. Avoid: treating it as a general-purpose storage or scratch space — it’s easy to reach for since you’re often already root when you need to fix something, but files left here have a way of being forgotten.

/var — Variable Data

Short for “variable,” this holds data that’s expected to grow and change while the system runs — logs, caches, spool files, databases in some setups.

Put here: log files (/var/log), data that services generate over time. Avoid: treating it as infinite. /var filling up is one of the most common causes of a Linux server grinding to a halt, since logs and caches can grow unnoticed for months.

/tmp — Temporary Files

A scratch space for short-lived files. On many distributions, /tmp is cleared automatically on reboot — sometimes even on a timer while the system is running.

Put here: files a program only needs during a single run or session. Avoid: anything you need to survive a reboot. This trips people up constantly — /tmp feels convenient precisely because anyone can write to it, but that convenience is exactly why nothing important belongs there long-term.

/usr — Installed Software And Shared Resources

Despite the name, this has nothing to do with “user” home directories — it holds the bulk of installed software: program binaries, libraries, documentation, and shared resources installed by your package manager.

Put here: nothing directly, in normal use — this directory is managed by your package manager (apt, in our case), not by hand. Avoid: manually dropping files into /usr itself. If you need to install software outside the package manager, that’s what /usr/local is for instead (see below) — keeping the two separate means a system update will never silently overwrite something you added yourself.

/bin and /sbin — Essential Binaries

/bin holds essential command binaries needed for the system to function at a basic level — things like ls, cp, cat. /sbin holds the same idea but for system administration commands, historically meant to be run by root.

Put here: nothing, in normal use. Like /usr, this is package-manager-managed territory.

/opt — Optional, Self-Contained Software

Reserved for third-party software that prefers to keep all its files bundled together in one self-contained directory, rather than scattering binaries, configs, and libraries across /usr the way package-manager-installed software does.

Put here: large, self-contained third-party applications that ship their own directory structure. Avoid: using it as a general dumping ground for anything you are not sure where to put in — /opt is specifically for software that wants to own its own subdirectory, not a catch-all.

/dev, /proc — Not Really “Files” At All

These look like ordinary directories full of files, but they’re not storing data on disk at all. /dev contains entries representing hardware devices (disks, terminals, etc.) that programs interact with as if they were files. /proc is even stranger — it’s a live, virtual view into the running kernel’s state, including a subdirectory for every currently running process.

Put here: nothing — these are generated dynamically by the kernel and don’t persist anything you write there in the way a normal directory would. Avoid: editing anything under /proc unless you specifically know what that file controls — a surprising number of entries there are writable, and writing to the wrong one can change live kernel behavior immediately, with no confirmation prompt.

/mnt and /media — Attachment Points

Both exist as conventional places to attach additional filesystems — /mnt traditionally for something an administrator mounts deliberately and temporarily, /media for removable media like USB drives, often mounted automatically. We’ll cover mounting itself in the Storage section.

Put here: nothing directly — these are meant to stay empty except for whatever’s currently mounted into them.

/boot — Bootloader And Kernel Files

Holds the files needed to actually start the system — the kernel image itself and bootloader configuration.

Put here: nothing, ever, by hand. This is one directory where a mistake can leave a system unable to start at all.

A General Rule Of Thumb

If you’re ever unsure where something belongs, ask these questions in order:

1. Is it configuration? → /etc
2. Is it a specific person’s personal data? → /home
3. Is it generated/growing data like logs? → /var
4. Is it truly temporary and disposable? → /tmp
5. Is it software you installed outside the package manager? → /usr/local (or /opt if it’s a large self-contained bundle)

If none of those fit, that’s usually a sign to stop and ask what the file actually is before picking a location for it — reaching for / or /root out of convenience is how systems end up hard to reason about six months later.

What’s Next

You now know what each part of the tree is for. The next chapter makes it practical — actually moving through that tree, checking where you are, and starting to create, copy, and remove files and directories yourself.