The Filesystem Layout — What Lives Where

On Windows, every drive gets a letter. The system lives on C:, your data on D:, the USB stick takes whatever letter is free. Linux throws all of that away. There is one tree, it starts at /, and everything gets grafted onto that tree somewhere: a second disk, a USB stick, a network share. No drive letters, just places.

The places have names that look cryptic at first. /etc, /usr, /var, /proc. Each has a job, and the jobs barely change between distros. The Navigating the Filesystem chapter taught you how to move (pwd, cd, ls); this page is about the destinations, and why you would look there.

Everything here was checked on Ubuntu 26.04, Fedora 44 and Arch. Where the three disagree, the text says so.

Here is the tree in one picture:

/                        the root of everything
├── home/                one folder per ordinary user
├── root/                home of the root (admin) user
├── etc/                 system-wide settings, plain text
├── usr/                 installed software
│   ├── bin/             programs from distro packages
│   ├── local/           what you install yourself
│   └── share/doc/       documentation shipped with packages
├── var/                 data that changes while the system runs
│   └── log/             logs, including the systemd journal
├── tmp/                 scratch space, disposable
├── opt/                 add-on software bundles
├── srv/                 data served to the network
├── boot/                kernel and bootloader files
├── dev/                 devices as files
├── proc/                live process view from the kernel
├── sys/                 live hardware view from the kernel
├── run/                 runtime state, cleared at boot
├── mnt/                 for filesystems you mount by hand
└── media/               removable drives (desktop convention)

A real system has a few more entries at the top level (a couple of library directories, for a start), but that is the map. The actual listing from the Ubuntu test box, one name per line:

$ ls /
bin
boot
dev
etc
home
lib
lib64
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var

Fedora adds a single entry, afs. It is not part of the standard layout, and it does not appear in the FHS spec linked at the end of this page. This particular image just ships it. A stock Ubuntu desktop carries one more: /snap — same idea as /opt, bundled software in one folder. Arch’s container has no media and carries two stray files at the top level, pkglist.x86_64.txt and version, leftovers from its image build. That is surface noise. Underneath, the layout is the same.

Your ground: /home and /root

/home is where ordinary users’ files live, one folder per login. If your username is mira, your files live in /home/mira, and the contents are yours to arrange however you like.

The shell has a shortcut for it: the tilde, ~, always means your own home directory. A bare cd with no arguments also takes you there, from anywhere on the tree.

One habit worth building early: plain ls hides any name that starts with a dot. Run ls -a in your home folder and a second population appears. Files like .bashrc are per-program settings, one file per tool, and later in this guide one of them gets a starring role.

The root user does not live downstairs with everyone else. The admin’s home is /root, up at the very top of the tree, separate from /home. Its contents are whatever the distro set up: on the Arch test box, ls -a /root turns up .bash_history, .config and .ssh, and no .bashrc at all. Do not count on any particular dotfile being present, even for root.

The settings floor: /etc

Where your dotfiles hold preferences for one user, /etc holds settings for the whole machine, in plain text you can read with nothing fancier than cat.

The distro leaves its ID card here. /etc/os-release names what you are running, and the three test boxes report, respectively:

PRETTY_NAME="Ubuntu 26.04 LTS"
PRETTY_NAME="Fedora Linux 44 (Container Image)"
PRETTY_NAME="Arch Linux"

(The Fedora string says Container Image because that is the variant tested; a Fedora workstation words it differently.)

/etc is also where each package manager keeps its instructions, and the paths differ by family. Spotting one tells you at a glance what you are sitting on:

• Ubuntu and Debian: /etc/apt/sources.list.d
• Fedora: /etc/dnf and /etc/yum.repos.d
• Arch: /etc/pacman.conf

Do not assume any one file is guaranteed to be here, though. /etc/hostname exists on the Ubuntu test box and is absent on the Fedora and Arch containers. What ends up in /etc depends on the install.

The programs: /usr, /bin and /usr/local

/usr is where software lives. Programs from distro packages land in /usr/bin (ls, bash and friends), while /usr/local/bin is yours: scripts you write, programs you compile, tools installed outside the package system. That is the agreed spot for self-installed software.

/opt is reserved for the other kind of self-installed software: a whole third-party bundle in one self-contained folder, like /opt/foo, rather than individual files collected under /usr/local.

This retroactively explains a line from the Systemd Timers guide, whose example service ran ExecStart=/usr/local/bin/foo.sh. The script lived there because that is where such a script belongs.

Two listings worth a close look:

$ ls -ld /bin /tmp
lrwxrwxrwx+  1 root root   7 Apr 20 08:46 /bin -> usr/bin
drwxrwxrwt+  9 root root 180 Sep  2 19:21 /tmp

The first line says /bin is not a real directory any more. The l at the front of the mode string marks a symlink, and the arrow gives the target: /bin is another name for usr/bin. This is the merged-usr layout. Distros fold the historic /bin into /usr/bin and leave the symlink behind, so a program reached as /bin/ls and one reached as /usr/bin/ls are the same file, and every old script that hardcodes /bin keeps working. (The trailing symbol on that line varies: Fedora’s ends with a dot, Arch’s with nothing — the + you see on this box marks an access-control list, extra rules layered on top of the base modes. The date is just when the image was built. The arrow is the part that matters.)

There is one more wrinkle in the same family. On Ubuntu, /sbin is a symlink to usr/sbin, and /usr/sbin is a real directory. On Fedora, both names chain through /usr/sbin: /sbin points to usr/sbin, and /usr/sbin points to plain bin, meaning /usr/bin. On Arch it is shorter: both /sbin and /usr/sbin point straight into usr/bin. Keep that in mind for the capstone below, where it explains a surprise.

One you will be glad exists: /usr/share/doc, the pile of documentation files that came with your packages.

The changing stuff: /var and /tmp

/var holds data that changes while the system runs, as opposed to programs, which mostly sit still. Its most visited corner is /var/log, where logs pile up; the systemd journal keeps its files in /var/log/journal. The Services & Logs chapter is entirely about reading those.

/tmp is scratch space, and the second line of that earlier listing explains its personality: drwxrwxrwt. The t at the end is the sticky bit, which is what keeps a directory that everyone can write to from turning into a free-for-all; the Permissions & Ownership chapter takes the mode string apart properly.

On all three test machines, /tmp is a tmpfs: it lives in memory rather than on disk, and its contents do not survive a reboot. That is this fleet’s configuration, and it varies by distro and setup. Other installs may well have /tmp as an ordinary directory on disk. Either way the practical rule is the same: treat /tmp as disposable. Never put anything there you would miss.

Where the kernel pretends: /proc, /sys and /dev

Three top-level directories are not really files on disk at all. The kernel invents them as you look.

/proc is the kernel’s window on running processes, and its numeric subdirectories are named after process IDs, each one belonging to the running process with that PID. You can check this yourself: run ps aux, pick a PID from the left column, and /proc has a directory with that number. Your own shell and the ps command itself get PID directories too.

The files in /proc come with one warning: do not trust the size column.

$ ls -l /proc/uptime
-r--r--r-- 1 nobody nogroup 21 Sep  2  2026 /proc/uptime

That file claims to be 21 bytes. Some of its neighbours report 0, others report thousands. On current kernels the sizes in /proc and /sys are a mixed bag, so read the column as decoration. (The nobody nogroup owner is a side effect of the container’s user mapping, not something you would see on a regular install.)

/sys runs the same trick for hardware: a live view of the devices and drivers the kernel knows about. The same warning about sizes applies.

/dev is where devices become files. Its most famous resident is /dev/null, shown by ls -l as crw-rw-rw-, where the leading c marks a character device. Anything sent to /dev/null disappears without a trace, which has made it the official landfill for unwanted output. Scripts write to it on purpose when they want a command’s noise to go away.

Mount points and the rest: /mnt, /media, /run, /boot

A few directories exist mostly to be mount points, places where other filesystems get attached to the tree.

/mnt is the traditional spot for something you attach yourself, by hand. /media is the desktop convention: on a machine with a graphical session, removable drives get mounted under it. A headless machine may not have the directory at all; on the Arch test container, /media simply does not exist.

/run is where the running system keeps live state. It is a tmpfs, cleared at boot, so whatever is in it was put there this boot and only matters this boot.

/boot holds the files a machine needs to start: the kernel and the bootloader. On a real install you will find them there, but the exact file names differ between distros and setups, so there is no universal listing to memorize. In these minimal test containers, /boot is completely empty.

/srv is meant for data this machine serves to the network, and on a desktop it is an empty directory that will most likely stay empty for the life of the machine.

One program through the tree: bash

To make the map concrete, follow one program through it: the shell you have been typing into all along. Three distros, three transcripts.

Ubuntu:

$ which bash
/usr/bin/bash
$ ls -l /usr/bin/bash
-rwxr-xr-x+ 1 root root 1540520 Feb 13  2026 /usr/bin/bash
$ ls -l /etc/bash.bashrc
-rw-r--r--+ 1 root root 2553 Feb 13  2026 /etc/bash.bashrc

Fedora:

$ which bash
/usr/sbin/bash
$ ls -l /usr/sbin/bash
-rwxr-xr-x. 1 root root 1551104 Jan 16  2026 /usr/sbin/bash
$ ls -l /etc/bashrc
-rw-r--r--. 1 root root 2709 Jan 17  2026 /etc/bashrc

Arch:

$ which bash
/usr/sbin/bash
$ ls -l /usr/sbin/bash
-rwxr-xr-x 1 root root 1195144 Jun 10 04:32 /usr/sbin/bash
$ ls -l /etc/bash.bashrc
-rw-r--r-- 1 root root 733 Jun 10 04:32 /etc/bash.bashrc

Fedora’s and Arch’s which bash answer looks as if the shell moved to some admin corner. It did not. On Fedora, /usr/sbin is a symlink to bin, so /usr/sbin/bash is /usr/bin/bash reached by a different name; on Arch, both names point straight into usr/bin. Same file, second door. Ubuntu’s /usr/sbin is a real directory, and Ubuntu’s bash sits in /usr/bin.

The config stops tell their own story. Each distro ships a system-wide bashrc for all users, but the name differs: Ubuntu and Arch call it /etc/bash.bashrc, Fedora calls it /etc/bashrc. Your own tweaks go in .bashrc in your home directory, which brings the tour full circle, back to the dotfiles from the start. And that Arch /root from earlier, the one with no .bashrc? Nothing is broken. A home directory contains what the distro, or you, put there.

The one-page map

Where you are now

You can read a path like a street address now. /etc is settings, /var is changing data, /usr/bin is distro software, /usr/local/bin is yours. When the Troubleshooting guide drills into a full disk with du and finds /var growing, that will not be a mystery: logs live there, and logs grow.

One distinction this page stayed away from: directories versus filesystems. Everything above is about the directory tree. Which filesystem (ext4, btrfs, swap) backs each piece of it is a separate question, and the Disks & Storage chapter owns that one.

For the formal version of the map, three sources worth keeping:

• Filesystem Hierarchy Standard 3.0, the spec itself
• hier(7), the layout manual, readable online
• Linux man-pages project, the project that maintains hier(7)

None of this needs memorizing. Keep the table within reach, run ls in unfamiliar places, and the map fills itself in.