A formatted partition is only usable once mounted on a directory of the tree; for it to come back after a reboot, it must be listed in /etc/fstab. This guide shows how to mount with mount, check with findmnt, unmount cleanly, then make the mount persistent by UUID. It insists on the check before rebooting, where mount -a alone proves nothing: you must add findmnt --verify to it. For beginner to intermediate administrators. Outputs from an AlmaLinux 10 test.
What you will learn
- Mount and unmount a file system (
mount,umount) - Check a mount with
findmnt - Write a reliable
/etc/fstabentry by UUID - Check the file before rebooting with
mount -a,findmnt --verifyandsystemctl daemon-reload - Avoid a blocked boot thanks to
nofail
Prerequisites
- A formatted partition (ext4, XFS...) and the right disk identified
sudoaccess
Mount a partition manually
The mount point is an existing directory where the file system becomes accessible. Create it, then mount:
sudo mkdir -p /mnt/data1sudo mount /dev/sda1 /mnt/data1Check with findmnt, more readable than mount because it only shows what interests you:
findmnt /mnt/data1TARGET SOURCE FSTYPE OPTIONS/mnt/data1 /dev/sda1 ext4 rw,relatime,seclabelThe SOURCE column confirms the right device, FSTYPE the file system and OPTIONS the active options. This mount is temporary: it disappears at the next reboot as long as it is not written into /etc/fstab.
Do not worry if your list of options is longer than this one: it depends on the file system and the distribution. The seclabel above comes from SELinux, active by default on AlmaLinux and RHEL. An XFS volume shows many more, all set automatically by the kernel:
TARGET SOURCE FSTYPE OPTIONS/mnt/data1 /dev/sda1 xfs rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquotaThese extra options signal no particular configuration: they are XFS's default values. No need to look for where they come from.
Unmount cleanly
Before unplugging an external disk, unmount it to guarantee that all writes are finished:
sudo umount /mnt/data1Make the mount persistent with /etc/fstab
The /etc/fstab file (file systems table) lists the file systems mounted at boot. The golden rule: reference by UUID, never by /dev/sdX (which can change if the disk order moves). Get the UUID:
sudo blkid /dev/sda1/dev/sda1: UUID="16ef4b6e-8295-414a-8450-1e84ce52ca1d" TYPE="ext4"Add a line to /etc/fstab. Its six columns: device, mount point, type, options, dump, check pass.
UUID=16ef4b6e-8295-414a-8450-1e84ce52ca1d /mnt/data1 ext4 defaults 0 2- UUID: stable identifier of the file system.
- Mount point:
/mnt/data1, which must exist. - Type:
ext4,xfs... - Options:
defaults, or a list (defaults,noatime). - Dump:
0(legacy backup, disabled). - Pass: order of the
fsckcheck at boot.
The pass deserves a word, because two contradictory rules are read everywhere: "1 for the root, 2 for the rest" on one side, "0 for XFS" on the other. The criterion is simple: the pass is 0 as soon as the file system is not checked by fsck at boot, which is the case for XFS and Btrfs, which have their own tools. For the systems that lend themselves to it, such as ext4, you put 1 on the root and 2 elsewhere.
It is the criterion that decides, not the mount point. The /etc/fstab shipped by AlmaLinux 10 shows it: the root is declared there as XFS with a pass of 0, despite the "1 for /" rule.
UUID=1f5fce98-... / xfs defaults 0 0Test before rebooting: the vital reflex
It is the step people forget, and it costs dearly. A wrong /etc/fstab line (typo, non-existent UUID) blocks the boot: the system falls into emergency mode and waits for a root password. The online check takes two commands, and you really need both.
sudo mount -asudo findmnt --verifyWhy mount -a alone is not enough
It is the point that surprises, and the one that loses machines. mount -a mounts what is not mounted yet, nothing more. It does not reread what already is, and it does not judge the file's consistency. Three broken /etc/fstab files, measured on AlmaLinux 10, go through it with exit code 0:
Broken /etc/fstab | What mount -a does |
|---|---|
| Wrong file system type on a point already mounted | rc=0, no message. The line is never evaluated |
Missing source with the nofail option | rc=0, no message, nothing is mounted |
| Incomplete line (two fields instead of six) | parse error at line 15 -- ignored, and rc=0 anyway |
The first case is the most treacherous: as long as the mount point stays busy, everything looks healthy. Unmount, rerun mount -a, and the truth comes out at once:
mount: /mnt/data1: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.Except that at reboot, everything is unmounted. The moment the error shows up is therefore precisely the one when you no longer have control.
findmnt --verify catches all three
findmnt --verify mounts nothing: it rereads the file and compares it with the real state of the devices. None of the three cases above escapes it.
sudo findmnt --verify0 parse errors, 0 errors, 2 warnings/mnt/data1 [W] xfs does not match with on-disk ext4 [W] your fstab has been modified, but systemd still uses the old version; use 'systemctl daemon-reload' to reloadTwo lessons in this output. The first, xfs does not match with on-disk ext4, is exactly the error mount -a let through: the file announces xfs, the disk carries ext4. The second is a reminder that the file alone is not enough, and it leads to the third command.
systemd keeps its own copy of the file
Editing /etc/fstab is not enough to inform systemd, which builds .mount units from it at boot and keeps the previous version until it is made to reread it:
sudo systemctl daemon-reloadIt is not a precaution of our own invention: the header of the /etc/fstab shipped by AlmaLinux asks for it in black and white, and findmnt --verify reminds you of it on its own in its output.
# After editing this file, run 'systemctl daemon-reload' to update systemdThe complete sequence before a reboot is therefore: mount -a, then findmnt --verify whose output you read, then systemctl daemon-reload.
Common cases
A few /etc/fstab entries depending on the need:
# Internal XFS data disk (boot depends on it, pass 0: XFS does not go through fsck)UUID=... /data xfs defaults 0 0# External USB disk (must not block the boot)UUID=... /mnt/backup ext4 defaults,nofail,x-systemd.device-timeout=5 0 2# Read-only volumeUUID=... /mnt/archive ext4 ro 0 2The x-systemd.device-timeout=5 option limits the wait to 5 seconds if the device is slow, useful combined with nofail.
Troubleshooting
Mount failures all look alike from afar: "it does not come back". The table below separates them by observable symptom, because that is what you have at hand when the problem strikes. The first two lines cover the most expensive case, the one where the check lied before the reboot.
| Symptom | Probable cause | Solution |
|---|---|---|
Boot in emergency mode after an fstab change | Wrong UUID or invalid option | fix the line, or comment it out; mount -a and findmnt --verify before any reboot |
mount -a silent, but the boot breaks anyway | the point was already mounted, or the line carries nofail | findmnt --verify: it rereads the file instead of just mounting |
umount: target is busy | process inside the mount point | fuser -vm <pt>, leave the directory |
| External disk blocks the boot | no nofail | add nofail to the line |
| Mount missing after reboot | line forgotten in /etc/fstab | add the entry, then mount -a, findmnt --verify and systemctl daemon-reload |
| The mount behaves as before the edit | systemd still uses the old version of the file | systemctl daemon-reload |
Put it into practice
An /etc/fstab entry can only be judged after a reboot: that is exactly what the lab checks. You mount an additional disk on /srv/data, referenced by UUID rather than by device name, and you validate the line with mount -a then findmnt --verify before proving that the persistent mount survives the reboot.
Key points
- A file system is only usable once mounted;
findmntchecks the result. - Unmount (
umount) before unplugging;fuser -vmfinds what is blocking. - In
/etc/fstab, reference by UUID (stable), never by/dev/sdX. - The pass is
0for systems not checked byfsck(XFS, Btrfs),1for an ext4 root and2elsewhere. - The check before rebooting is
mount -aandfindmnt --verify:mount -aalone exits with 0 on at least three broken/etc/fstabfiles. findmnt --verifyexits with 0 even when it complains: read its output, do not test$?.- After editing,
systemctl daemon-reload: otherwise systemd keeps the old version of the file. nofailon non-essential disks avoids a boot in emergency mode.
Knowledge check
Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Mount file systems on demand with autofs
A new full quiz with random questions
Work again only on the questions you missed