Fix Linux Mount Point Missing in /etc/fstab

Simple Fix (30 Seconds) — Check if Mount Point Exists

I know this error is infuriating. You run mount /data and get "mount point not found in /etc/fstab" or something similar. First thing: your mount point might not exist at all. The error can be misleading.

Run this:

ls -ld /data

If you see "No such file or directory", that's your problem. Create it quick:

sudo mkdir -p /data

Then try mounting again. This tripped me up the first time too. The kernel needs a directory to attach the filesystem to. Without it, the mount command fails even if the fstab entry is perfect. If the directory exists and you still get the error, move to the next step.

Moderate Fix (5 Minutes) — Check and Edit /etc/fstab

So the mount point exists. Next, check if the entry is actually in /etc/fstab. Run:

cat /etc/fstab | grep /data

No output? Then the entry is missing. This happens when you add a new disk, copy an fstab from another system, or someone deleted it by accident. I've seen it on Ubuntu 22.04 and CentOS 7 after a system migration.

Here's how to add it. First, find the device or UUID. I prefer UUID because it won't change if you move disks around. Run:

sudo blkid /dev/sdb1

You'll get something like:

/dev/sdb1: UUID="abc123-..." TYPE="ext4"

Now edit fstab:

sudo nano /etc/fstab

Add a line like this at the end:

UUID=abc123-... /data ext4 defaults 0 2

The last two numbers are dump and pass. For data drives, I use 0 and 2. For system partitions, use 0 and 1. Save and exit.

Now test your entry without rebooting:

sudo mount -a

If no error, you're good. If you get "mount point not found" again, double-check your mount point path in fstab — maybe a typo like /deta instead of /data. Also make sure the directory exists (you already checked that in step 1).

Advanced Fix (15+ Minutes) — Systemd and Mount Unit Conflicts

This one got me on Fedora 38. Your fstab entry looks perfect, the mount point exists, but mount -a still says "mount point not found in /etc/fstab".

The real fix here: systemd might have a mount unit file that conflicts with your fstab entry. Systemd translates fstab entries into mount units automatically, but if there's a leftover manual unit file, it can block things.

Check for existing mount units:

systemctl list-units --type=mount | grep data

If you see something like data.mount that's active or failed, that's your culprit. Disable it:

sudo systemctl stop data.mount
sudo systemctl disable data.mount

Also check for unit files in /etc/systemd/system/ or /usr/lib/systemd/system/:

ls /etc/systemd/system/*.mount 2>/dev/null
ls /usr/lib/systemd/system/*.mount 2>/dev/null | grep data

If you find one, remove it with sudo rm. Then reload systemd:

sudo systemctl daemon-reload

Now try sudo mount -a again. This should work. If not, there's one more thing: SELinux or AppArmor blocking the mount. On Red Hat-based systems, check SELinux:

sudo ausearch -m avc -ts recent | grep mount

If you see denials, you can temporarily set SELinux to permissive to test:

sudo setenforce 0

Then mount. If it works, you need to relabel the filesystem or create a policy. For most users, the systemd fix is enough.

One Last Tip

If you're using a bind mount or a network filesystem like NFS, the fstab syntax is different. For example, an NFS mount looks like:

server:/export /mnt/nfs nfs defaults 0 0

Not UUID-based. Make sure you're matching the filesystem type. I've seen people copy-paste ext4 entries for NFS and wonder why it fails.

That's it. Start with the 30-second check, then the fstab edit, then the systemd deep dive. You'll fix it without rebooting or re-installing.