The scenario
You plug in an external drive, add a new disk, or try to mount a partition after a reboot. Then this hits you:
mount: /mnt/data: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or helper program, or other error
The disk shows up in lsblk just fine — but mounting fails. This error has five distinct causes, and the fix depends on which one you're dealing with.
Quick diagnosis first
Start here before touching anything else. Find out what filesystem is actually on the partition:
sudo blkid /dev/sdb1
Typical output:
/dev/sdb1: UUID="a1b2c3d4-..." TYPE="ext4" PARTUUID="..."
No output from blkid? The partition is either unformatted, corrupted, or you're targeting the wrong device. Cross-check with:
lsblk -f
sudo fdisk -l /dev/sdb
Cause 1: Wrong filesystem type specified
This is the most common culprit. You're asking the kernel to read ext4 as ntfs, or vfat as ext4 — it won't work. Two ways to fix it:
# Let the kernel auto-detect (works 90% of the time)
sudo mount /dev/sdb1 /mnt/data
# Or pin the exact type from blkid output
sudo mount -t ext4 /dev/sdb1 /mnt/data
sudo mount -t ntfs /dev/sdb1 /mnt/data
sudo mount -t vfat /dev/sdb1 /mnt/data
sudo mount -t exfat /dev/sdb1 /mnt/data
Getting a "missing codepage or helper program" error with ntfs or exfat? The userspace tools aren't installed. That's a separate fix:
# Ubuntu/Debian
sudo apt install ntfs-3g exfatprogs
# CentOS/RHEL
sudo yum install ntfs-3g exfatprogs
# Arch
sudo pacman -S ntfs-3g exfatprogs
Then retry the mount.
Cause 2: Corrupted superblock
The superblock holds critical filesystem metadata — block size, inode count, UUID. Damage it and the kernel can't read the filesystem at all. Run a read-only check first to see what you're dealing with:
sudo fsck -n /dev/sdb1
The -n flag is important here. It reports issues without touching anything. If errors show up, unmount and do a real repair:
sudo umount /dev/sdb1
sudo fsck -y /dev/sdb1
The -y flag auto-confirms every repair prompt. On a typical 500 GB ext4 partition with moderate corruption, this takes 2–5 minutes. Try mounting again afterward.
Primary superblock completely gone? ext2/ext3/ext4 always write backup copies at fixed offsets. Find them:
sudo dumpe2fs /dev/sdb1 | grep -i superblock
Output looks like this:
Primary superblock at 0, Group descriptors at 1-6
Backup superblock at 32768, ...
Backup superblock at 98304, ...
Pick the first backup and use it to repair:
sudo e2fsck -b 32768 /dev/sdb1
Then mount normally.
Cause 3: Dirty bit set (NTFS)
Hard shutdown, power cut, or a Windows machine with Fast Startup enabled — all of these leave NTFS partitions with a dirty flag. Linux refuses to mount them read-write until it's cleared. Check the status first:
sudo ntfsfix -n /dev/sdb1
Dirty flag confirmed? Clear it:
sudo ntfsfix /dev/sdb1
This works as a bandage fix. For the root cause on the Windows side, turn off Fast Startup: Control Panel → Power Options → Choose what the power buttons do → Turn on fast startup → uncheck. Otherwise the flag comes back every time Windows shuts down.
Cause 4: Targeting the wrong device node
A surprisingly common mistake — mounting the whole disk instead of a partition:
# Wrong — /dev/sdb is the entire disk, no filesystem there
sudo mount /dev/sdb /mnt/data
# Right — /dev/sdb1 is the first partition
sudo mount /dev/sdb1 /mnt/data
List all partitions on the disk to confirm what's there:
sudo parted /dev/sdb print
Cause 5: Mount point doesn't exist
Small thing, easy to miss. If /mnt/data doesn't exist yet, mount fails before it even tries:
sudo mkdir -p /mnt/data
sudo mount /dev/sdb1 /mnt/data
Permanent fix via /etc/fstab
Mounting this disk on every boot? Add it to /etc/fstab. Use UUID instead of device names — /dev/sdb1 can shift to /dev/sdc1 if you add another disk, but the UUID never changes:
# Get the UUID
sudo blkid /dev/sdb1
# Output: /dev/sdb1: UUID="a1b2c3d4-5678-..." TYPE="ext4"
Add this line to /etc/fstab:
UUID=a1b2c3d4-5678-... /mnt/data ext4 defaults,nofail 0 2
The nofail option is worth understanding: without it, a missing or failed disk will hang your boot for 90 seconds waiting for a timeout. With it, the system boots fine and simply skips the mount. Test the entry without rebooting:
sudo mount -a
No errors? You're done.
Verify the fix
# Confirm it's mounted
mount | grep sdb1
# or
df -h | grep /mnt/data
# Check you can read files
ls /mnt/data
# Quick write test
touch /mnt/data/testfile && echo "Write OK" && rm /mnt/data/testfile
When nothing works
blkid returns nothing. fsck can't repair it. The partition table or filesystem is severely damaged — possibly hardware failure. At that point, stop writing to the disk immediately.
- Recover the partition table with
testdisk:sudo apt install testdisk && sudo testdisk /dev/sdb - Recover individual files with
photorec(comes with testdisk) - Suspect the drive is physically failing? Clone it first with
ddrescue, then work on the clone
# Clone a failing disk — do this before anything else
sudo apt install gddrescue
sudo ddrescue -d -r3 /dev/sdb /dev/sdc recovery.log
The -r3 flag tells ddrescue to retry bad sectors up to 3 times. It logs which sectors failed, so you can resume if the process gets interrupted.