How to Fix ‘Failed to Mount /etc/fstab’ and Emergency Mode in Ubuntu

Few sights are more unnerving when powering up an Ubuntu desktop or server than watching the normal boot animation vanish, replaced by a wall of red systemd error text declaring “Failed to mount /etc/fstab” or “You are in emergency mode”. Below this warning, the system drops into a spartan root emergency shell prompting: “Press Enter for maintenance (or press Control-D to continue)”.

Pressing Control-D invariably results in an immediate loop back to the same emergency shell. This boot failure occurs because systemd-fstab-generator parses /etc/fstab at early boot to mount essential storage volumes. If a hard drive listed in the file is disconnected, an external backup drive is powered off, a partition Universally Unique Identifier (UUID) changed after repartitioning, or a filesystem is corrupted, systemd marks the mount dependency as critical and refuses to enter standard multi-user targets. This recovery guide explains how to repair your fstab configuration and restore normal Ubuntu booting.

Method 1: Inspect the Boot Journal to Identify the Broken Mount

Before editing system files blindly, inspect the systemd journal logs to discover precisely which storage partition or filesystem mount failed.

1. Press Enter at the emergency prompt and type your root administrative password.
2. Query the systemd journal for critical mount errors by running:

   journalctl -xb | grep -i mount

3. Look for lines highlighted in red displaying:

   Failed to mount /mnt/data: Unit mnt-data.mount entered failed state.

   or messages mentioning “Timed out waiting for device /dev/disk/by-uuid/…”.
4. Note the failing mount point path and disk UUID identified in the logs.

Method 2: Remount the Root Filesystem in Read-Write Mode

In emergency mode, Ubuntu frequently mounts the root partition (/) as read-only to prevent accidental data corruption. You must remount it as read-write before you can save changes to configuration files.

1. In the emergency shell, attempt to test write access:

   mount -o remount,rw /

2. Verify that the filesystem is now mounted read-write:

   mount | grep "on / "

3. The output should include (rw,relatime) instead of (ro,relatime). You can now safely edit configuration files.

Method 3: Comment Out Non-Essential Mounts in /etc/fstab

If the failing mount corresponds to a secondary data drive, external USB disk, or network share that is temporarily unavailable, commenting out its entry in /etc/fstab allows Ubuntu to complete boot into the normal desktop or server environment.

1. Create a backup of the existing configuration:

   cp /etc/fstab /etc/fstab.bak

2. Open the fstab file in the nano editor:

   nano /etc/fstab

3. Locate the line corresponding to the failing mount point identified in Method 1.
4. Add a hash symbol (#) at the very beginning of the line to comment it out. For example:

   # UUID=a1b2c3d4-e5f6-7890-abcd-1234567890ab /mnt/backup ext4 defaults 0 2

5. Press Ctrl + O followed by Enter to save the file, then Ctrl + X to exit nano.
6. Test rebooting the system:

   systemctl reboot

Method 4: Verify and Correct Partition UUID Mismatches

If you recently cloned a drive, created new partitions in GParted, or formatted a drive, the filesystem UUID changed, causing fstab references to point to non-existent disk signatures.

1. List all currently connected storage block devices and their true UUIDs:

   blkid

2. Compare the actual UUID of your partition (e.g., /dev/nvme0n1p2 or /dev/sda1) against the UUID string written in /etc/fstab.
3. If the strings differ, edit /etc/fstab using nano /etc/fstab and update the entry with the correct UUID output from blkid.
4. To prevent non-critical storage drives from halting boot in the future, append the nofail mount option to secondary drives:

   UUID=your-uuid-here /mnt/storage ext4 defaults,nofail 0 2

   The nofail flag instructs systemd to continue booting normally even if this specific drive is missing or disconnected.

Method 5: Check and Repair Corrupted Filesystems with fsck

If the UUID is correct but the filesystem metadata suffered corruption following an unexpected power loss, systemd halts boot to prevent compounding data damage.

1. Identify the target partition path using lsblk.
2. Ensure the partition is unmounted:

   umount /dev/sda1

3. Run the filesystem check and repair tool:

   fsck -y /dev/sda1

4. The -y parameter automatically repairs detected superblock inconsistencies and orphaned inodes.
5. Once fsck reports the filesystem is clean, reboot the machine:

   reboot

Ubuntu fstab & Emergency Mode Reference Matrix

Use the matrix below to identify typical boot-stopping mount errors and their remedies:

Boot Error Symptom	Underlying Root Cause	Standard Remedial Command
“Timed out waiting for device”	Incorrect UUID or disconnected physical drive	Check blkid; add “nofail” option to /etc/fstab
“Cannot save file: Read-only filesystem”	Root partition mounted read-only in emergency shell	mount -o remount,rw /
Emergency mode loops on Control-D	Critical systemd mount unit failure unresolved	Examine journalctl -xb; comment out bad fstab line
“Bad superblock on /dev/sdX”	Filesystem corruption following unclean shutdown	fsck -y /dev/sdX
Samba/NFS network share stalls boot	Network stack not initialized before filesystem mount	Add “_netdev,nofail” to fstab mount options

Preventing Network Share Boot Hangs with _netdev

If your /etc/fstab mounts networked Samba (CIFS) or NFS shares, standard boot sequences attempt to mount them before the network interface has acquired an IP address via DHCP. This triggers a guaranteed boot timeout. Always append _netdev,nofail to every network mount in /etc/fstab. The _netdev parameter explicitly delays mounting until systemd brings up local network connectivity, preventing emergency mode lockouts.