Filesystems and Mounts: fstab, UUID, and Recovery

Filesystems and Mounts: fstab, UUID, and Recovery

Practical patterns for Linux filesystem management — fstab syntax, UUID vs LABEL, mount options, automounting, and recovery steps when things go wrong.

Tested on: Ubuntu 20.04 LTSUbuntu 22.04 LTSUbuntu 24.04 LTS

Every Ubuntu system — desktop, server, Raspberry Pi — boots by reading /etc/fstab, and a surprising number of boot failures, missing drives, and permission headaches trace back to a single wrong character in that file. This page covers fstab syntax, the UUID vs LABEL debate, mount options that actually matter for performance and reliability, automounting external and NTFS drives, and the recovery steps you need when a mount goes sideways. It’s built from years of writing fstab entries by hand, rescuing systems from emergency mode, and learning which defaults to trust and which to override. For more foundational command-line knowledge, our Documentation hub ties everything together.

fstab Syntax and Common Patterns

The file lives at /etc/fstab. Each non-comment line has six whitespace-separated fields:

<device>  <mount point>  <type>  <options>  <dump>  <pass>

A typical Ubuntu root entry:

UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890  /  ext4  errors=remount-ro  0  1

Breaking that down: the device is identified by UUID (more on that in a moment), mounted at /, formatted as ext4, with an option that remounts the filesystem read-only if errors are detected — a sensible safety net. The 0 means “don’t dump” and the 1 means “check this filesystem first during boot” (only the root filesystem should be 1; other partitions use 2, and anything you don’t want checked gets 0).

A secondary data partition might look like:

UUID=deadbeef-1234-5678-9abc-def012345678  /mnt/data  ext4  defaults,noatime,nofail  0  2

The nofail option is critical for non-essential drives — it tells systemd to continue booting even if this mount fails. Without it, a disconnected USB drive or a dead secondary disk will dump you into emergency mode. For the authoritative field-by-field breakdown, the fstab(5) man page is the definitive reference.

UUID vs LABEL Identification

You have three main ways to identify a device in fstab:

  • Device path: /dev/sda1 — simple, but unreliable. Add a USB drive and suddenly your /dev/sdb1 is now /dev/sdc1. Bad.
  • UUID: UUID=a1b2c3d4-... — assigned at filesystem creation, globally unique, doesn’t change when you rearrange SATA cables or plug in a thumb drive. This is the right default.
  • LABEL: LABEL=DataDrive — human-readable, convenient, but only unique if you enforce it yourself. Two drives labeled “Data” will cause undefined behavior.

Find your UUIDs and labels:

sudo blkid

Or for a prettier tree view:

lsblk -f

The output shows device, fstype, label, UUID, and mount point. Bookmark this command — you’ll run it constantly when debugging mount issues.

For the vast majority of setups, UUID is the answer. Use LABEL only when you’re managing a fleet of identically configured machines where human-readable names improve automation clarity, and you have strict naming controls.

Mount Options That Matter

The defaults keyword expands to rw,suid,dev,exec,auto,nouser,async. That’s fine for most partitions, but a few additional options are worth knowing:

noatime — stops the kernel from updating the “last accessed” timestamp on every file read. On SSDs, this reduces unnecessary writes. On HDDs, it’s a minor performance win. Ubuntu 22.04+ uses relatime by default (only updates the timestamp when the previous atime is older than the mtime), which is a good compromise, but noatime is still slightly faster if you don’t care about access times at all.

errors=remount-ro — on ext4 root partitions, this remounts the filesystem read-only when corruption is detected instead of continuing to write to a damaged disk. Ubuntu’s installer sets this on / by default. Leave it.

nofail — already mentioned, but worth repeating: add this to every entry that isn’t your root partition or essential for boot. Your system should not refuse to start because an external drive was unplugged.

discard — enables continuous TRIM on SSDs. Alternatively, Ubuntu runs a weekly fstrim.timer service by default on 20.04+, so continuous discard is often unnecessary. Check with systemctl status fstrim.timer.

uid and gid — for filesystems that don’t support Unix permissions natively (FAT32, NTFS, exFAT), these options set the owning user and group. Without them, files are often owned by root, leaving your regular user unable to write.

Automounting USB, NTFS, and ext4

Modern Ubuntu desktops automount USB drives through udisks2 and the file manager — plug it in, it appears in Nautilus under /media/your-username/DriveName. But servers and headless systems don’t have a file manager. Two options:

fstab entry with nofail:

UUID=xxxx-xxxx  /mnt/usb  vfat  defaults,nofail,uid=1000,gid=1000  0  0

The drive mounts at boot if present and is silently skipped if absent.

systemd automount: Create a .mount and .automount unit pair. The drive mounts on first access rather than at boot — useful for network shares or drives that aren’t always connected.

For NTFS drives, Ubuntu 22.04+ includes the in-kernel ntfs3 driver which offers better performance than the older ntfs-3g FUSE driver. An fstab entry:

UUID=1234ABCD5678EF90  /mnt/windows  ntfs3  defaults,uid=1000,gid=1000,nofail  0  0

If you’re on 20.04, stick with ntfs-3g. Either way, make sure the Windows partition was shut down cleanly (no hibernation, no Fast Startup) or the driver will refuse to mount read-write.

Recovery Steps: Read-Only Rescue and fsck

Things go wrong. Power cuts, bad sectors, full disks — the filesystem gets damaged and suddenly you’re staring at a blinking cursor or an emergency shell. Here’s the playbook.

Symptom: system drops to emergency mode at boot.

This usually means an fstab entry failed. At the emergency prompt:

journalctl -xb | grep -i mount

Find the failing entry. Edit fstab:

nano /etc/fstab

Comment out or fix the broken line. Then:

systemctl daemon-reload
exit

The system retries boot.

Symptom: filesystem is mounted read-only unexpectedly.

Check dmesg for ext4 errors:

dmesg | grep -i ext4

If corruption is detected, you need fsck — but never on a mounted filesystem. Boot from a live USB, or if it’s a non-root partition, unmount it first:

sudo umount /mnt/data
sudo fsck -y /dev/sda2

The -y flag automatically answers “yes” to repair prompts. For the root filesystem, you’ll need a live USB or recovery mode.

Symptom: “wrong fs type, bad superblock” error.

Usually means the filesystem type in fstab doesn’t match the actual filesystem on the device. Verify with blkid, correct the entry, and retry.

Common Pitfalls

Editing fstab without a backup. Always cp /etc/fstab /etc/fstab.bak before making changes. One misplaced character can prevent boot. Having a backup means recovery is a one-line fix from emergency mode.

Forgetting nofail on removable drives. That USB drive you mounted last week? When it’s not plugged in next boot, your system hangs or drops to emergency mode. Every non-essential mount gets nofail. No exceptions.

Using device paths instead of UUIDs. Seems fine until you add a second hard drive and your partitions shift. We’ve seen /dev/sdb1 become /dev/sdc1 and suddenly the wrong partition is mounted as /home. UUIDs prevent this entirely.

NTFS and Windows Fast Startup. Windows 10 and 11 enable Fast Startup by default, which doesn’t fully shut down — it hibernates the kernel. This leaves the NTFS filesystem in a dirty state, and Linux drivers will mount it read-only (or refuse entirely). Disable Fast Startup in Windows Power Options, or use shutdown /s /t 0 instead of the normal shutdown.

Running fsck on a mounted filesystem. This will cause data loss. Always unmount first, or run from a live environment. There are no shortcuts here.

Check the front matter of this page for internal links to related Ubuntu Portal documentation, including our CLI basics guide and the broader documentation hub.

Frequently Asked Questions

What happens if I make a mistake in fstab?
If a device listed in fstab cannot be mounted at boot, Ubuntu will drop you into emergency mode — a minimal root shell where you can edit the file and fix the problem. This is why the nofail option exists: adding it to non-critical entries (like a secondary data drive) tells the boot process to continue even if that mount fails.
Should I use UUID or LABEL in fstab?
UUID is the safer default. It is assigned when the filesystem is created and does not change unless you reformat. Labels are human-readable and convenient, but they are not guaranteed to be unique — two drives with the same label will cause ambiguous mounts. Use labels only when you control the naming and know no duplicates exist.
How do I find the UUID of a partition?
Run sudo blkid to list all block devices with their UUIDs, types, and labels. For a tree view that also shows mount points and sizes, use lsblk -f. Both commands work without mounting the device first.
Can I edit fstab on a running system without rebooting?
Yes. Edit the file, save it, then run sudo systemctl daemon-reload followed by sudo mount -a. The mount -a command attempts to mount everything in fstab that is not already mounted. It will report errors immediately rather than waiting until the next boot.
What does the dump field in fstab do?
The fifth column (dump) is used by the dump backup utility to decide whether a filesystem should be backed up. Almost nobody uses dump anymore. Set it to 0 for every entry — this is what Ubuntu’s installer does by default.
How do I mount an NTFS drive with read-write access?
Install the ntfs-3g package (sudo apt install ntfs-3g) if it is not already present. Then mount with the ntfs-3g filesystem type, or simply use ntfs3 (the in-kernel driver available from kernel 5.15 onward). In fstab, an entry like UUID=xxxx /mnt/data ntfs3 defaults,uid=1000,gid=1000 0 0 gives your user read-write access.