Drive cannot be mounted automatically, but manual mount is successful

Question

I have an external hard disk that all of a sudden gives an error when Linux Mint attempts to auto mount the thing when it is plugged in. For some reason I see two "External Drive" (the drive's name) labels in Nemo, but both give a similar error when attempting to access them. The only difference being the second drive access error has /dev/sdb2, rather than sdb3 as shown below.

Error mounting /dev/sdb3 at /media/branden/External_Drive: Command-line `mount -t "ntfs" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,dmask=0077,fmask=0177" "/dev/sdb3" "/media/branden/External_Drive"' exited with non-zero exit status 12: NTFS signature is missing.
Failed to mount '/dev/sdb3': Invalid argument
The device '/dev/sdb3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

I went to manually mount the thing but was met with something even more strange. The command that worked was:

mount /dev/sdb /mnt

Which appears to be mounting the drive rather than a partition. I am able to access the entire drive by doing this, but I am unsure why it worked this way. There should be only a single partition on the external, so I am not sure why the following results (shown below) are being observed. If I attempt to mount /dev/sdbX, where X is 1, 2, 3, or 4, I am met with "special device /dev/sdbX does not exist".

Here is the output one gets from fdisk -l, text formatting was terrible, so I'll post an image:

And again from parted -l:

Any suggestions?

---

Again, the text formatting due to special characters in /etc/fstab made it illegible.

I never made special provisions to mount this device at a particular point in my directory structure. It simply is mounted as a media device on boot once it is recognized. I did a drive clone recently and following that the drive did not mount on boot any longer.

---

Output of ls /dev/sdb*

/dev/sdb  /dev/sdb2  /dev/sdb3

tl;dr - Drive does not mount as media device (since it is an external HDD with USB interface) after HDD clone from another disk. Also, I must mount the device to the directory structure as mount /dev/sdb /mnt, rather than selecting a particular partition as in mount /dev/sdb1 /mnt. The outputs of fdisk and parted are different, with the former showing multiple partitions that should not exist.

Answer 1

What happened?

So I spent some time looking into this and I am fairly sure that this is caused by a kernel bug. The bug is triggered by the fact that you have an NTFS filesystem on the root of the disk (ie the filesystem begins right at the start of the disk). Usually the root of the disk will contain a partition tables and the filesystem(s) would be within the individual partitions.

Normally this would work fine with other filesystems, but it seems that the fact it is NTFS has the kernel confused. Instead of recognising the NTFS filesystem and passing over it, it instead recognises it as an MBR partition table and proceeds to create some device files relating to non-existent partitions.

I'm not sure why you don't get an sdb1. Both the start and end of the disk are passed the end of the disk for sdb4, hence it doesn't appear. Presumably the kernel finds some other problem with sdb1 and doesn't create it. You do get sdb2 and sdb3 however.

Workaround

The workaround is to try to get the rest of the system to ignore the dodgy partitions. To do this, first run the command sudo udevadm info /dev/sdb | grep ID_SERIAL= when the disk is plugged in to find out its serial number, this is everything after the =. Next create a file with the path /etc/udev/rules.d/99-hide-partitions.rules. Put the two lines below in it, and replace xxxxx with your serial number from before.

ID_SERIAL=xxxxx, ID_PART_ENTRY_NUMBER=="2", ENV{UDISKS_IGNORE}="1"
ID_SERIAL=xxxxx, ID_PART_ENTRY_NUMBER=="3", ENV{UDISKS_IGNORE}="1"

After saving the file, unplug and plug your disk and things should be ok.

Alternative

The alternative of course is to reformat the disk and either put a partition table and an NTFS filesystem on it or just use a different filesystem.

This may be the better solution for the long run as presumably the reason for having an NTFS partition is for Windows compatibility. My experience with Windows is that it doesn't like disks with no partition table either (probably the reason why this bug hasn't came up in Linux before). You can check (or maybe you already know) if the drive works with Windows. If this is the case having an NTFS filesystem that doesn't work with Windows on a disk that doesn't work well in Linux probably isn't much use.

Note that if you want a filesystem that plays nicely with both Linux and Windows, a good one to try is UDF.

Bug report

It would probably be a good idea to report this bug to the kernel developers. What would be useful is a copy of the first 512 bytes of the drive which is misinterpreted as an MBR partition table. It would be useful to reproduce the bug in case it doesn't appear with every NTFS filesystem. To copy the section of the drive do to mbr.bin:

sudo dd if=/dev/sdb of=mbr.bin bs=512 count=1

If you want to report the bug yourself, feel free. Otherwise, please post the file online somewhere so that someone here can do it. If you are going to reformat, obviously do this first.