Ubuntu adheres strictly to the Filesystem Hierarchy Standard (FHS) — the same specification that governs most modern Linux distributions. This standardized layout ensures predictability, portability of scripts and tools, support for read-only root filesystems in embedded/container scenarios, and clean separation between static/shareable content and variable/machine-specific data.
While the core hierarchy is identical between Ubuntu Desktop and Ubuntu Server, practical differences emerge in defaults (e.g., partitioning schemes, mounted volumes, and filesystem choices during installation). This article explains the FHS layout in depth, highlights Ubuntu-specific conventions (as of 24.04 LTS through 25.10+ in 2026), and covers modern storage management approaches including LVM, Btrfs, and ZFS.
1. The Filesystem Hierarchy Standard (FHS) – Core Principles
FHS (latest version 3.0 from 2015, still current in 2026) classifies directories along two orthogonal axes:
- Shareable vs Unshareable Shareable files can be placed on NFS-exported or read-only media shared across hosts (e.g., /usr, /opt). Unshareable files are host-specific (e.g., /etc, /var).
- Static vs Variable Static content rarely changes (binaries, libraries, documentation). Variable content changes during normal operation (logs, spool, runtime state).
This classification enables advanced setups: read-only /usr mounted from network or squashfs, /var on tmpfs or separate partition, etc.
2. Key Directories in Ubuntu (FHS + systemd conventions)
| Directory | Purpose & Contents | Shareable? | Static? | Ubuntu Notes (2024–2026) |
|---|---|---|---|---|
| / | Root of the entire hierarchy; minimal set required for booting | No | Mixed | Usually on separate partition; often LUKS-encrypted |
| /bin | Essential user command binaries (ls, cat, cp, etc.) | Yes | Yes | Merged into /usr/bin since systemd merge (/bin → symlink) |
| /boot | Kernel images, initramfs, GRUB config; often unencrypted even on encrypted root | No | Yes | Separate partition recommended (FAT32 for EFI) |
| /dev | Device nodes (managed by udev); dynamic | No | No | tmpfs or devtmpfs |
| /etc | Host-specific configuration files (passwd, fstab, netplan YAML, systemd units) | No | Mostly | Critical; backup regularly |
| /home | User home directories; personal files & settings | No | No | Often on separate partition or LVM LV for easy resize |
| /lib | Essential shared libraries & kernel modules | Yes | Yes | Merged into /usr/lib |
| /media | Mount point for removable media (USB drives, CDs) | No | No | Managed by udisks/automount |
| /mnt | Temporary mount point for sysadmin use | No | No | Legacy; prefer /media or custom mounts |
| /opt | Optional/add-on software packages (e.g., third-party vendor installs) | Yes | Yes | Common for manually installed tools |
| /proc | Virtual filesystem with process & kernel info | No | No | procfs; kernel-generated |
| /root | Home directory for the root user | No | No | Not /home/root |
| /run | Runtime variable data (PIDs, sockets, lock files); cleared on reboot | No | No | tmpfs by default (systemd requirement) |
| /sbin | Essential system binaries (fsck, ifconfig, reboot) | Yes | Yes | Merged into /usr/sbin |
| /srv | Data served by the system (www, ftp, rsync, cvs repos) | Yes | No | Underused; good for separation |
| /sys | Virtual filesystem exposing kernel device tree & sysfs | No | No | sysfs; kernel-generated |
| /tmp | Temporary files; cleared on reboot (systemd-tmpfiles) | No | No | tmpfs by default since ~18.04 |
| /usr | Read-only, shareable hierarchy (binaries, libs, man pages, share) | Yes | Yes | Can be mounted read-only; growing merger with / |
| /var | Variable data (logs, spool, caches, databases) | No | No | Frequently on separate partition or tmpfs subdirs |
Important modern convention (systemd era): Many traditional root-level directories (/bin, /sbin, /lib, /lib64) are now symlinks into their /usr counterparts. This usr-merge simplifies packaging, initramfs, and allows fully stateless /usr.
3. Ubuntu-Specific Layout Nuances
- Server vs Desktop The FHS layout is identical. Differences are in:
- Installation partitioning defaults (Server uses subiquity guided storage → more LVM/flexible options; Desktop favors simplicity).
- Default renderer for networking (Netplan + systemd-networkd on Server; NetworkManager on Desktop).
- Preinstalled packages and services (snapd more prominent on Desktop).
- /home often encrypted/separate on Desktop installs; Server tends toward minimal / + /boot + optional data LVs.
- /snap directory Canonical-specific: contains mounted squashfs images for Snap packages. Appears after first snap install. Not part of FHS but ubiquitous on Ubuntu.
- /var/lib/snapd and /var/snap Snap metadata and per-snap writable areas.
4. Storage Management on Ubuntu Servers
Ubuntu supports multiple layers for flexible, resilient storage:
- Traditional partitioning Simple, fast, predictable. Use for boot-critical areas (/boot/efi, /boot).
- LVM (Logical Volume Manager) Most common server choice. Advantages: online resize of logical volumes, thin provisioning, snapshots (copy-on-write), easy addition of PVs. Typical layout: /boot separate → LVM VG containing root LV + data LVs. Snapshots useful for backups or testing upgrades.
- Btrfs Modern CoW filesystem with built-in RAID-0/1/10, snapshots, subvolumes, compression (zstd), transparent checksumming. Strengths: easy snapshot-based rollback (Ubuntu supports subvolume layout like @, @home), send/receive for backups. Weaknesses: RAID-5/6 still considered experimental/unstable in 2026; higher CPU/memory overhead than ext4. Best for: home servers, development, workstations needing snapshots; avoid for critical production RAID-5/6 arrays.
- ZFS (via zfsutils-linux or OpenZFS) Advanced CoW filesystem with native RAID-Z (similar to RAID-5/6 but self-healing), compression, deduplication, snapshots, send/receive. Strengths: exceptional data integrity (checksums + self-healing), mature RAID-Z, ARC caching. Weaknesses: higher RAM usage (especially with dedup), CDDL license (not mainline kernel), slightly more complex administration. Best for: NAS/file servers, backup repositories, environments prioritizing integrity over raw write speed.
2026 Recommendation Landscape
- General-purpose server → ext4 on LVM (predictable, mature, low overhead).
- Data integrity critical (NAS, archival) → ZFS (preferred over Btrfs for production RAID).
- Snapshot-heavy workflows (dev/test, rollbacks) → Btrfs with subvolumes.
- Cloud/VM hosts → ext4 or XFS on LVM (thin LVs for VM disks).
Summary: Mental Model
Think of the Ubuntu filesystem as three layers:
- FHS root hierarchy — static rules for where things live (shareable/static vs unshareable/variable).
- Physical/logical storage — partitions, LVM VGs/PVs/LVs, mdadm RAID, or native RAID (ZFS/Btrfs).
- Mount points & options — /etc/fstab or systemd .mount units control how/when filesystems are mounted (noatime, compress, discard for SSDs).
Mastering this separation lets you design resilient layouts: small /boot (unencrypted), encrypted root on LVM or ZFS, large /var or /srv on separate volumes/filesystems, /home snapshotted or backed up independently.
Whether you’re hardening a production server or building a home NAS, the FHS provides the predictability — while LVM/ZFS/Btrfs give you the flexibility to adapt storage to workload demands without breaking conventions.