EXT4 Superblock Corruption: Fix in Under 10 Minutes

When This Error Hits

You try to mount a drive and get hit with something like: "EXT4-fs error (device sda1): ext4_find_entry: …" or "couldn't mount because of unsupported optional features" — sometimes just "Input/output error". The drive is there, lsblk shows it, but mount fails instantly.

This usually happens after an unclean shutdown — power loss, kernel panic, or yanking an external USB drive. It also shows up on drives that are starting to fail (SMART reallocated sectors). The superblock, which sits at the very beginning of the partition, got corrupted. The filesystem can't read its own metadata.

Root Cause (Plain English)

The superblock is the master index for your filesystem. It stores block size, inode count, free blocks, and the checksum for itself. If that checksum mismatches or the block is unreadable, the kernel refuses to mount. Period.

EXT4 doesn't rely on just one superblock. It keeps copies every 64k blocks (if using 4k block size) or at other fixed offsets. The trick is finding a clean copy. The culprit here is almost always a partial write to the superblock during the last unmount or a bad sector taking out that exact block.

The Fix: Step by Step

1. Unmount the partition if it's mounted read-only. Run:
   sudo umount /dev/sda1
2. Find backup superblocks with dumpe2fs. This command lists all superblock copies:
   

   sudo dumpe2fs /dev/sda1 | grep -i "superblock"

   
   If the primary superblock is totally trashed, this might fail. In that case, use:
   

   sudo dumpe2fs -ob 1024 /dev/sda1 | grep -i "superblock"

   
   Look for lines like "Backup superblock at 32768". Note the numbers — they're block numbers.
3. Try the first backup superblock with e2fsck. Pick the smallest backup superblock (usually 32768 or 16384):
   

   sudo e2fsck -b 32768 -y /dev/sda1

   
   -b tells fsck which superblock to use. -y auto-answers yes to fixes. If you prefer to approve each change, drop the -y.
4. If e2fsck crashes or hangs, try the next backup superblock. Rerun with 32768, then 40960, then 81920, etc. The output from dumpe2fs lists them all. Skip the first one if it fails — I'd go straight for 32768 on most drives.
5. Once e2fsck finishes clean (no errors, or errors fixed), mount the partition normally:
   

   sudo mount /dev/sda1 /mnt

6. Optionally, rebuild the primary superblock from the backup you used. Only do this if you plan to keep using the drive and want clean metadata:
   

   sudo mkfs.ext4 -O has_journal -b 4096 -S /dev/sda1

   
   Warning: -S rewrites the superblock but doesn't touch data. Still, back up anything critical first.

What To Do If e2fsck Still Fails

If none of the backup superblocks work — every single one returns corruption errors — the problem isn't the superblock. Here's what to check:

• Bad drive hardware: Check SMART data. sudo smartctl -a /dev/sda. Look for Reallocated_Sector_Ct, Current_Pending_Sector, or Reported_Uncorrect. If those are non-zero, replace the drive. No software fix works.
• Wrong partition start: Did you recently resize or move partitions? Run sudo fdisk -l /dev/sda and verify the partition starts at the right sector. A misaligned partition looks like superblock corruption.
• Filesystem type mismatch: Ensure it's actually EXT4. Run blkid /dev/sda1. If it says TYPE="ext2" or "ext3", you need the matching fsck variant: e2fsck -t ext2 or e2fsck -t ext3.

If the drive passes SMART and the partition is correct, you might be looking at a RAID or LVM layer issue. Check cat /proc/mdstat for RAID status, or sudo lvdisplay to see if the logical volume is active.

I've seen cases where the superblock is physically gone — zeroes where the magic number should be. In that situation, run sudo mke2fs -n /dev/sda1 (dry-run) to see what superblock offsets the filesystem would create, then use those offsets with e2fsck. If that still fails, accept the data loss, back up whatever you can with ddrescue, and reformat.