Mounting a drive fails with "wrong fs type, bad option, bad superblock" — what is it actually telling me?

The rule that has saved me data: before running any repair, mount read-only and copy off what matters.

sudo mount -o ro,noload /dev/sdX1 /mnt

Many filesystems will mount read-only when they refuse to mount writable, precisely so the data can be rescued. Copy first, repair second.

And if the drive is making noises, showing read errors in the kernel log, or the checker is reporting large numbers of problems, stop and take an image of the whole device with a tool that tolerates bad sectors before doing anything else. Repairs write to the disk, and a failing disk is the worst place to be writing.

That fourth step is the one to lead with next time. The kernel almost always says something specific — unknown filesystem, bad magic number, needs recovery, mounted read-only because of errors — and the generic message is just the userspace tool's summary.

On the two cases that come up most:

A filesystem needing recovery after an unclean removal. Common on external drives pulled without unmounting. The kernel says so in the log and the fix is to run the checker for that filesystem. For the Windows-format filesystems there is a specific one, and running the wrong checker for the filesystem type is how a recoverable drive becomes an unrecoverable one.

A drive that was hibernated rather than shut down from a Windows machine. The filesystem is marked in use and refuses to mount writable, by design, because writing to it would corrupt the hibernated state. Mount read-only to get the data, and boot the other machine and shut it down properly to clear it.

You have read it correctly — the tool genuinely does not know. The kernel refused the mount and returned a generic failure, and the message lists the common causes because it cannot distinguish them.

Narrow it down before touching anything, in this order.

1. Ask what the filesystem is.

sudo blkid /dev/sdX1
sudo file -s /dev/sdX1

If these identify a filesystem, the drive is readable and the problem is elsewhere. If they report nothing, you are looking at the wrong device or genuine damage.

2. Check you are mounting the partition, not the disk. /dev/sdb is the whole disk and /dev/sdb1 is the partition. Mounting the disk produces exactly this error and is the single most common cause.

3. Check the driver is present. Some filesystems need a package installed — the message's "helper program" clause. lsmod and trying an explicit -t will tell you.

4. Read the kernel log. dmesg | tail -30 immediately after the failed attempt usually contains the real reason in plain words, which the mount command did not pass on.

One mundane cause worth ruling out early because it costs nothing: the enclosure or the cable.

External drives fail to enumerate properly with a marginal cable or an under-powered hub, and the symptom can be a partition table that reads intermittently and a mount that fails. If dmesg shows the device connecting and disconnecting, or resetting, stop debugging filesystems and change the cable and the port first.