Home

The Linux filesystem layout, explained

Linux follows the Single Hierarchical Directory Structure Unix tradition — everything starts at / (root) and branches out from there. The layout under / is broadly defined by the Filesystem Hierarchy Standard (FHS, formerly FSSTND). Different distros take small liberties with it, but the bones are the same everywhere.

A few quick conventions Linux inherits from Unix:

There's also the famous "everything is a file" rule: devices, kernel state, even running processes show up as files (under /dev, /proc, etc.) so they can be read and written with the same tools as anything else.

Mounting

Mounting is how you make a partition, USB stick, CD or network share usable on Linux. Windows auto-mounts everything it sees on boot; Linux is more deliberate — you mount things at the path you choose, and only when you choose. The kernel sees the raw device under /dev/<something> (e.g. /dev/sda1); to actually read its files you mount it somewhere user-visible like /mnt/sda1 or /media/usb.

The whole point of this single-tree-with-mounts design is to make distributed systems easy: you can mount /home from a network share, /var/mail from another, the web server's content from a third, and the user sees one cohesive filesystem.

The top-level directories (per FHS)

bash
/bin     core executables required for boot and recovery/boot    bootloader files and the kernel image/dev     device files/etc     system configuration/home    per-user home directories/lib     shared libraries and kernel modules/media   mount points for removable media (CDs, USB)/mnt     generic mount point for temporary mounts/opt     third-party software (self-contained)/proc    virtual fs exposing kernel and process state/root    home directory of the root user/run     runtime data (PIDs, sockets) since boot/sbin    sysadmin executables/srv     data served by the system (e.g. webroots)/tmp     temporary files (often wiped on reboot)/usr     user-shared programs, libs, docs (read-only)/var     variable data: logs, mail, print queues, caches

The rest of this post is a closer look at the directories you'll actually interact with.

/home

Per-user data. Each user gets /home/<username> with their files and dotfiles (the hidden ~/.config, ~/.ssh, etc.). Equivalent in spirit to the Windows Users\ directory.

/boot

Boot-time stuff: the kernel image (vmlinuz-*), initramfs, and the bootloader (GRUB). Don't touch unless you're doing kernel work or unbreaking a busted boot.

/lib and /lib64

Shared libraries — the Linux equivalent of Windows DLLs (file extension .so). Kernel modules live under /lib/modules/<version>/. On 64-bit systems, 64-bit libs may be split into /lib64.

/opt

For self-contained third-party software. If you install something that comes as a tarball or vendor .deb, it'll often land here as /opt/<vendor>/.

/mnt and /media

Both are mount points for non-OS storage:

The split is convention, not enforced; you can mount wherever you want.

/srv

Files served by the system to the network — webroots, FTP shares, that kind of thing. Many distros leave it empty by default.

/usr

Counter-intuitively, not user data — that's /home. /usr holds user-shared data: programs, libraries, docs, locales. Most of what your package manager installs lands here:

/bin

Core commands needed to boot and recover the system: cat, cp, ls, mv, rm, mkdir, etc. On modern distros /bin is often a symlink to /usr/bin (the "merged-/usr" layout).

/sbin

Sysadmin commands — fsck, mount, ifconfig, etc. Same merged-/usr symlink story applies on modern distros.

/etc

System config. If you need to change how the OS or any installed service behaves, you almost certainly touch a file under /etc. A few examples:

Configs here are declarative — they describe state, not running processes.

/dev

Device files. Everything from disks (/dev/sda1) to terminals (/dev/tty1) to random number sources (/dev/urandom) shows up here.

A handful you'll see most:

bash
/dev/sda            first SCSI/SATA/USB disk/dev/sda1           first partition on /dev/sda/dev/null           the bit bucket anything written here disappears/dev/zero           an infinite stream of null bytes/dev/random         high-entropy randomness/dev/urandom        non-blocking randomness/dev/tty            controlling terminal/dev/loop*          loop devices for mounting disk images

/proc

A virtual filesystem exposing kernel and process state. Nothing on disk — every read returns the live value. A few useful entries:

/var

Variable runtime data. Logs (/var/log), mail (/var/mail), the print queue, package manager caches (/var/cache/apt), database files for things that don't ship their own data dir.

/tmp

Scratch space for programs. Wiped on reboot on most distros (or after some TTL). Don't keep anything important here.

/root

The root user's home directory. (Why not /home/root? Historically /home could be on a separate filesystem that wasn't mounted in single-user mode, and the root user needs to be able to log in before /home is mounted to fix things. So root's home stays on the root filesystem.)

/lost+found

When fsck finds orphaned files (typically after an unclean shutdown), it puts them here. If you're missing files after a crash, this is where to look. Owned by root and readable only with elevated privileges.

That's the tour. The TL;DR for new admins: configs in /etc, logs in /var/log, your stuff in /home, packages in /usr, kernel state in /proc. Everything else you'll learn when you need it.