Fix EXT Filesystem Metadata Corruption on Linux

The Quick Fix: Force a Filesystem Check (30 seconds)

Most of the time, metadata corruption is caused by a dirty shutdown. The kernel marks the filesystem as dirty, then refuses to mount it properly. The fastest fix is forcing a check on next reboot.

1. Boot from a live USB (Ubuntu or any Linux installer).
2. Open a terminal and run:

sudo touch /forcefsck
sudo reboot

If you can’t boot at all, pass fsck.mode=force at the kernel command line in GRUB. Press e at boot to edit, find the line starting with linux, add that parameter, then Ctrl+X to boot.

This forces a full fsck on all EXT filesystems during boot. For a single partition, use:

sudo tune2fs -c 1 /dev/sda1   # force check after 1 mount
sudo reboot

After the check, set it back to default with sudo tune2fs -c -1 /dev/sda1 or it'll keep checking every boot.

If the error persists after reboot, the corruption is deeper. Move to the moderate fix.

Moderate Fix: Run e2fsck from a Live Environment (5 minutes)

The live USB is your best friend here. Boot it, then find your partition with lsblk or blkid. Unmount it first – never run fsck on a mounted filesystem, it'll make things worse.

sudo umount /dev/sda1
sudo e2fsck -f -y -v /dev/sda1

Flags explained:

• -f – Force check even if clean
• -y – Auto-answer yes to all prompts (saves time)
• -v – Verbose so you see what it fixed

e2fsck will scan every inode and block group. It'll fix orphaned inodes, bad block checksums, and directory entries pointing to nothing. Expect output like:

Pass 1: Checking inodes, blocks, and sizes
Inode 12345 has an invalid file type. Fix? yes
Pass 2: Checking directory structure
Missing '..' in directory entry. Fix? yes

Don't be scared by the red text. This is normal. Let e2fsck run to completion. If it reports “FILE SYSTEM WAS MODIFIED” – reboot right away.

Common issue: e2fsck says the filesystem is clean but the error still shows. That usually means the superblock is corrupt but the data is fine. That's when you need the advanced fix.

Advanced Fix: Restore Backup Superblock and Rebuild Journal (15+ minutes)

If the superblock (the first 1024 bytes of the partition) is toast, e2fsck can't even read the filesystem metadata. But EXT stores backup superblocks at regular intervals. Find them with:

sudo mke2fs -n /dev/sda1

Don’t run mke2fs without -n – that flag just prints the backup superblock locations without formatting. You'll see a list like:

Superblock backups stored on blocks:
  32768, 98304, 163840, 229376, 294912

Now restore from the first backup block (32768 is usually the safest bet):

sudo e2fsck -b 32768 -y /dev/sda1

If that fails, try 98304, then 163840. One of them will work – EXT4 always keeps at least 3 copies.

Once e2fsck runs successfully with the backup superblock, check the journal. A corrupted journal can cause metadata corruption on every mount:

sudo dumpe2fs -h /dev/sda1 | grep 'Journal'
sudo e2fsck -j /dev/sda1   # forces journal replay

If the journal is completely broken, you can create a new one:

sudo tune2fs -O ^has_journal /dev/sda1
sudo e2fsck -f /dev/sda1
sudo tune2fs -j /dev/sda1

That removes the journal, checks the filesystem, then adds a fresh journal. Works 90% of the time.

Real-world trigger this happens

I see this mostly on cloud VPS instances after a forced poweroff by the provider (AWS, Linode, DigitalOcean). Or on laptops where the battery died and the user had open file handles. The kernel can't sync metadata to disk, so you get partial writes to inode tables.

When to give up and restore from backup

If e2fsck still fails after trying all backup superblocks and rebuilding the journal, the metadata is physically corrupted on disk. You'll see “Couldn't find valid filesystem superblock” even from backups. At that point, mount it read-only and copy out what you can with ddrescue or testdisk. Then restore from backup. Don't waste hours – I’ve seen people chase phantom superblock fixes for a whole shift.

Summary of commands

Save yourself the headache – always keep backups of your metadata-critical partitions. A 5-minute cron job with dump or tar beats a 2-hour recovery session.