Ferhat

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.

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.

One practical note: a swap file is as good as a swap partition on any modern kernel, and it is far easier to resize.

So the argument about how much to allocate at install time is largely obsolete — allocate a modest partition or none, and add a file later if monitoring shows you want more. Deciding a permanent partition size at install, for a machine whose workload you have not run yet, is the part of the old advice that has aged worst.