Mount a data filesystem

A mount attaches a filesystem to one directory in the visible tree. Until a filesystem is mounted, the data on it exists but nothing can reach it.

For a data drive on a server, you want two things: mount it by UUID so device-name shuffling can’t hit the wrong disk, and make the mount survive reboots without being able to break the boot.

Mount it by hand first

Take the UUID of your practice filesystem from the inventory you saved in the previous lesson, then:

sudo mkdir -p /srv/data
sudo mount UUID=YOUR-LAB-UUID /srv/data
findmnt /srv/data

Do not copy the placeholder UUID. Use the real one from lsblk on your machine.

findmnt confirms the mount: it prints the target, the source device, the filesystem type, and the options. If it prints nothing, the mount didn’t happen. You should now be able to ls /srv/data and see the filesystem’s contents.

Make it survive a reboot

Startup mounts belong in /etc/fstab with deliberate failure behavior. Add one line:

UUID=3f6c9d81-real-uuid-here /srv/data ext4 defaults,nofail 0 2

The option that matters is nofail. Without it, a missing or dead data drive stops the whole boot and drops the server into emergency mode. That’s a terrible trade for a headless machine: you’d lose SSH access because a data disk died. With nofail, the system boots, and you fix the disk over SSH.

Validate before rebooting

A typo in fstab is the classic way to break a boot. Test the file while the system is running:

sudo umount /srv/data
sudo mount -a
findmnt /srv/data

mount -a mounts everything listed in fstab that isn’t mounted yet, using the same parsing the boot process relies on. If your line is wrong, you get an error here, in a working shell, instead of at a boot prompt. If systemd warns that fstab changed, run sudo systemctl daemon-reload and repeat.

Only after mount -a works cleanly, reboot once and check findmnt /srv/data again. Now the mount is proven, not assumed.