skip to content

Mounts and fstab

16 roadmaps6 questions

Storage becomes usable only by being mounted into the directory tree. You will learn to mount by UUID, write durable fstab entries, use bind mounts, and unstick a busy filesystem.

part ofLinux & distributionsoverview, primer and where to startread it →
on this pageshow

explore

questions

6

An /etc/fstab entry names a disk as /dev/sdb1. Why is that fragile on a Linux server, and how do UUID=, LABEL= and PARTUUID= differ as replacements?

level: juniorimportance: must knowfreq 70%

answer

  1. device nodes are discovery order
  2. identity lives in the superblock
  3. filesystem UUID vs partition UUID
  4. cloning copies it too

basics

~20 s

Kernel names like /dev/sdb1 depend on device discovery order, so a new disk or a slow controller can renumber them and mount the wrong filesystem. Prefer UUID= from the filesystem superblock, or PARTUUID= from the partition table.

solid answer

~50 s

`/dev/sdb1` is not an identity — it is the slot the kernel happened to assign while probing devices. Add a disk, move a cable, or let an adapter probe more slowly, and yesterday's `sdb` becomes today's `sdc`; the fstab line then mounts the wrong filesystem or fails outright. So in fstab I use a stable identifier. `UUID=` is the filesystem's own UUID, written into the superblock by `mkfs` — it follows the data even if the disk moves to another controller or machine. `LABEL=` is the human-readable string in the same superblock: readable, but easy to collide. `PARTUUID=` (and `PARTLABEL=`) come from the partition table rather than the filesystem, so they survive a reformat — useful when a partition is reimaged. I read them with `blkid` or `lsblk -f`, and the one gotcha to remember is that cloning a disk clones the filesystem UUID too.

go deeper

for a junior

Know that /dev/sdX names come from probe order and can change, and that fstab should use UUID= instead. Be able to say you would find it with blkid or lsblk -f.

for a middle

Explain where each identifier physically lives — filesystem superblock for UUID and LABEL, partition table for PARTUUID and PARTLABEL — and what operation invalidates each one.

for a senior

Show you have been burned: duplicate UUIDs from cloned images, automation that hard-codes a UUID and breaks on reformat, and the habit of validating with mount -a before rebooting a remote box.

for a principal

Frame it as a fleet convention: decide whether images are provisioned by UUID, PARTUUID or by-id paths, who owns rewriting fstab after a reformat, and how the golden image avoids shipping duplicate identifiers.

## Why a device node is not an identity When the kernel probes storage it hands out names in the order devices come up: the first SCSI/SATA disk it enumerates becomes `/dev/sda`, the next `/dev/sdb`, and so on. Nothing in that name is derived from the hardware. Probing is asynchronous and driver-dependent, so the order can change when you add or remove a disk, when a controller initialises more slowly after a firmware update, when a USB device is attached at boot, or when a virtual machine's disks are re-ordered by the hypervisor. NVMe names (`/dev/nvme0n1`) are more stable but not guaranteed either. The consequence in `/etc/fstab` is nasty because it is silent in the good case and catastrophic in the bad one: an entry that says `/dev/sdb1 /data ext4 defaults 0 2` will happily mount whatever filesystem now sits on `sdb1`. If the renumbering swapped two data disks, the system boots and serves the wrong data. ## The stable identifiers **`UUID=`** — a 128-bit identifier stored inside the filesystem superblock, generated by `mkfs` at format time. It travels with the filesystem: change the cable, the controller or the machine and the UUID is unchanged. This is the default choice for fstab and for the kernel `root=` parameter. **`LABEL=`** — a short human-readable string in the same superblock, set by `mkfs -L` or later by tools such as `e2label` for ext4 or `xfs_admin -L` for XFS. Readable in fstab (`LABEL=backup /backup ...`), but two disks can carry the same label, and then resolution is ambiguous. **`PARTUUID=` / `PARTLABEL=`** — these come from the *partition table*, not the filesystem. On GPT every partition has a UUID and an optional name; on an MBR disk `PARTUUID` is synthesised from the disk signature plus the partition index and looks like `c0ffee12-01`. The key difference: reformatting a partition creates a new filesystem UUID but leaves the PARTUUID alone. That makes PARTUUID the right choice for provisioning flows that reimage a partition in place. udev also maintains symlink trees under `/dev/disk/`: `by-uuid`, `by-label`, `by-partuuid`, plus `by-id` (vendor/serial) and `by-path` (physical topology). `by-id` is a good choice when you want "the physical drive in that bay" rather than "whatever is formatted on it". ## How the name is resolved `mount` and the initramfs use libblkid, which scans block-device superblocks and partition tables and caches the result. `blkid` prints what it found; `lsblk -f` shows the same data in tree form; `findmnt` shows what is currently mounted and by which source. In fstab the tag form goes in the first field exactly as `UUID=1b3f...` — no `/dev/` prefix and no quotes needed. ```bash blkid -s UUID -o value /dev/sdb1 # 6f3c1e6a-06a1-4c39-9ad3-2f9f2b7f8a11 ``` ## The traps *Cloning duplicates UUIDs.* Copying a disk with `dd`, or cloning a VM from a template, copies the superblock and therefore the filesystem UUID. Two visible filesystems then claim the same UUID and `mount` resolves to whichever libblkid returns first — a genuinely confusing failure. The fix is to reset one of them (`tune2fs -U random` on ext4, or `xfs_admin -U generate` on XFS) and update fstab. *Reformatting changes the UUID.* Any automation that recreates a filesystem must re-read the UUID and rewrite fstab; a hard-coded UUID in a configuration-management template rots the first time someone runs `mkfs` again. *Editing fstab does not mount anything.* The entry takes effect at the next `mount -a` or reboot. On a systemd machine, run `systemctl daemon-reload` after editing so the fstab generator re-reads the file, and test with `mount -a` before you reboot — validating on a running system is far cheaper than debugging from an emergency shell.

  • You cloned a VM from a template and now two block devices report the same filesystem UUID. What breaks, and how do you fix it?
    Resolution becomes ambiguous: `mount UUID=...` and the initramfs pick whichever device libblkid returns first, so the machine can mount the wrong disk or fail to find root. Fix it by regenerating one filesystem's UUID — `tune2fs -U random` on ext4, `xfs_admin -U generate` on an unmounted XFS — then update the fstab entry and the initramfs if it was the root filesystem.
  • When would you deliberately prefer PARTUUID= over UUID= in fstab or on the kernel command line?
    When the partition gets reformatted but must keep the same role. PARTUUID lives in the partition table, so it survives `mkfs`; the filesystem UUID does not. Imaging pipelines that lay a fresh root filesystem into a fixed partition use `root=PARTUUID=...` for exactly this reason. It is also the only option for content that has no filesystem superblock to read.
  • What is the last field of an fstab line for, and what does setting it wrong cost you?
    It is the fsck pass number. `1` means check in the first pass and is reserved for the root filesystem; `2` means check afterwards, in parallel across devices; `0` means never check. Giving a data disk `1` serialises it with root and slows boot; giving root `0` means a corrupt root filesystem is mounted unchecked. The field before it, dump, is a legacy backup flag and is effectively always `0`.

saying these in an interview costs you the question

  • Thinks /dev/sda is permanently assigned to a physical disk
  • Believes UUIDs survive reformatting the partition
  • Copies a UUID from a cloned image without regenerating it
  • Assumes editing fstab mounts the filesystem immediately
  • Confuses the filesystem LABEL with the partition PARTLABEL

context

resolving links…

open as a page

`umount /data` returns "target is busy". What kinds of references make a Linux filesystem busy, and what does `umount -l` actually do that a plain unmount does not?

level: seniorimportance: must knowfreq 58%

basics

~20 s

A filesystem is busy while anything still references it: open file descriptors, a process whose working directory or root is inside it, memory-mapped files, an active swap file, or a submount. umount -l (MNT_DETACH) only detaches the subtree from the path namespace — the filesystem stays alive until the last reference goes away.

open as a page

On Linux, what does `mount --bind /srv/data /var/www/html` actually create, how does it differ from putting a symlink at that path, and what does `--rbind` add?

level: middleimportance: should knowfreq 50%

basics

~20 s

A bind mount makes an existing directory (or file) appear at a second path as a real mount entry, with both paths referring to the same underlying data. Unlike a symlink it is a genuine mount, not a link the caller can detect or refuse; --rbind also replicates any submounts.

open as a page

In an /etc/fstab entry, what do the mount options nosuid, nodev and noexec each enforce on Linux, and why is noexec on /tmp weaker protection than people assume?

level: middleimportance: should knowfreq 45%

basics

~20 s

nosuid makes the kernel ignore setuid and setgid bits (and file capabilities) on that mount; nodev makes device special files there non-functional; noexec makes execve fail for files under it. noexec is weak because an interpreter can still read and run a script as data.

open as a page

You add an fstab entry for a new data disk, reboot, and the machine drops to an emergency shell instead of coming up. Why can one fstab line stop the whole boot, and which mount options let a non-critical filesystem fail without taking the system down?

level: seniorimportance: should knowfreq 55%

basics

~20 s

Every fstab entry becomes a boot-time dependency: on a systemd machine the fstab generator turns each line into a mount unit that local-fs.target requires, so a missing device or failed mount fails the target and drops you to emergency mode. Mark optional filesystems nofail.

open as a page

Linux mounts carry a propagation type — shared, private or slave. What do those mean, and why does a filesystem mounted inside a separate mount namespace sometimes appear on the host and sometimes not?

level: seniorimportance: nice to knowfreq 28%

basics

~20 s

Propagation controls whether mount and unmount events on one mount are replicated to its peers. Shared mounts propagate both ways, private mounts propagate nothing, and slave mounts receive events from their master but send none back — which is why a mount made in an isolated tree may or may not become visible elsewhere.

open as a page