Fix "mount: wrong fs type, bad option, bad superblock"

sudo dmesg | tail -20
lsblk -f

What the error means

Current util-linux prints:

$ sudo mount /dev/sdb /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

The mount() system call returned a generic error (EINVAL), and mount lists every common reason because it cannot tell which one applies. The superblock (the block that describes a file system's layout) is only one candidate. The kernel log usually names the real problem, so always read dmesg first:

sudo dmesg | tail -20
# or
journalctl -k -n 20

Example output, three different causes:

EXT4-fs (sdb): VFS: Can't find ext4 filesystem
CIFS: VFS: cifs_mount failed w/return code = -22
ntfs3(sdc1): It is recommened to use chkdsk. Volume is dirty and "force" flag is not set!

Cause 1: you are mounting the disk instead of a partition

A disk such as /dev/sdb or /dev/nvme1n1 holds a partition table, not a file system. The file system lives on a partition: /dev/sdb1, /dev/nvme1n1p1.

lsblk -f

Example output:

NAME   FSTYPE FSVER LABEL  UUID                                 MOUNTPOINTS
sdb
└─sdb1 ext4   1.0   backup 3f1c...e9a2

Mount the entry that shows an FSTYPE: sudo mount /dev/sdb1 /mnt. If FSTYPE is LVM2_member or crypto_LUKS, see mount: unknown filesystem type for how to open those layers first. The disk management guide covers lsblk, partitions and mounting in depth.

Cause 2: missing helper for network shares

CIFS (SMB/Windows shares) and NFS need userspace helpers (mount.cifs, mount.nfs). Without them the kernel receives raw options it cannot parse and fails with this error.

sudo mount -t cifs //nas/share /mnt/share -o username=alice,uid=$(id -u),gid=$(id -g)
sudo mount -t nfs nas:/export/data /mnt/data

If CIFS still fails with return code = -22 or -95, the server may only speak an old SMB version; try -o vers=3.0 (or vers=2.1). Avoid vers=1.0 unless the device cannot be upgraded; SMB1 is insecure.

Cause 3: wrong file system type or a bad option

Forcing a type that does not match (-t ext4 on an NTFS partition), or an option the driver does not know, produces the same error. Typos in /etc/fstab are common: default instead of defaults, ext4 options on an XFS volume, or uid= on ext4 (only FAT/NTFS/exFAT accept it). Let mount detect the type and remove options one by one:

sudo mount /dev/sdb1 /mnt          # no -t, no -o
sudo findmnt --verify              # checks /etc/fstab for errors

A broken fstab line for a non-essential disk can drop the system into emergency mode at boot; add nofail to such entries.

Cause 4: NTFS volume is dirty or hibernated

The in-kernel ntfs3 driver refuses to mount an NTFS partition that Windows left in an unclean state, which happens whenever Windows Fast Startup or hibernation is on. The kernel log says "Volume is dirty". Boot Windows and shut down fully (hold Shift while clicking Shut down), disable Fast Startup, or run chkdsk /f there. You can mount read-only meanwhile with -o ro. Full details are in the NTFS mounting guide.

Cause 5: the superblock really is damaged

If dmesg reports a corrupt or unreadable superblock on the right partition, repair it. First check the hardware, because repairing a failing disk can make things worse:

sudo smartctl -H /dev/sdb

ext4

ext4 keeps backup superblocks. List them without changing anything, then point e2fsck at one:

sudo dumpe2fs /dev/sdb1 2>/dev/null | grep -i 'backup superblock'
sudo e2fsck -f -b 32768 /dev/sdb1

If dumpe2fs cannot read anything, sudo mke2fs -n /dev/sdb1 prints where backups would be. The -n is essential: without it mke2fs creates a new, empty file system over your data.

XFS

sudo xfs_repair -n /dev/sdb1      # dry run, reports only
sudo xfs_repair /dev/sdb1

xfs_repair searches for secondary superblocks automatically. If it complains about a dirty log, see "Structure needs cleaning" before using -L.

Btrfs

sudo btrfs check --readonly /dev/sdb1
sudo mount -o ro,rescue=usebackuproot /dev/sdb1 /mnt

Copy data off first; run btrfs check --repair only as a last resort.

Distro-specific notes

• Ubuntu cloud and minimal images may lack less common file system modules; install linux-modules-extra-$(uname -r) if dmesg says the type is unknown.
• Fedora Workstation uses Btrfs by default; Fedora Server and RHEL-family systems use XFS. Use the matching tool above.
• Arch: after a kernel update without reboot, modules for the running kernel are gone and mounting a new file system type can fail. Reboot.
• openSUSE defaults to Btrfs for the root file system, often with XFS for /home on older installs.

How to prevent it

• Use UUID= in /etc/fstab instead of /dev/sdX names, which can change between boots, and run sudo findmnt --verify after editing.
• Install cifs-utils/NFS tools before adding network mounts.
• Disable Windows Fast Startup on dual-boot machines.
• Unmount or safely eject removable drives before unplugging them, and watch SMART status.

Frequently asked questions