A failed mount shows up two ways: a filesystem that should be there isn't, or — far scarier — a server that won't finish booting because a bad /etc/fstab entry dropped it into emergency mode. Both come down to a mismatch between what fstab expects and what's actually attached.
1. Read the error
Try the mount by hand and let it tell you why:
mount -a # mount everything in fstab; prints the failure journalctl -b | grep -i mount # what happened at boot lsblk -f # what disks/filesystems actually exist + UUIDs
wrong fs type means the ext4/xfs field is wrong or the disk is unformatted; special device ... does not exist means the device/UUID in fstab no longer matches reality (a renamed disk).
2. Fix fstab the safe way
Prefer UUIDs over /dev/sdb1 names — device letters can change between boots, UUIDs don't. Get the UUID from lsblk -f (or blkid) and match the fstab line to it:
UUID=xxxx-xxxx /data ext4 defaults 0 2 # add 'nofail' so a missing disk never blocks boot: UUID=xxxx-xxxx /data ext4 defaults,nofail 0 2
3. Validate before you trust it
The golden rule: never reboot on an untested fstab. After editing, run mount -a — if it returns cleanly, every entry mounts and the file is safe for boot. If it errors, fix it now, while you still have a shell. Add nofail to non-critical mounts so a missing disk degrades gracefully instead of dropping you into emergency mode.
Practise disk incidents
Failed mounts are incidents in the simulator. Work them on a live box with Linux troubleshooting practice, and see no space left on device for the full-disk cousin.