Mounting external hard drive on boot can be very tricky, troublesome operation. First, it adds delay to the boot sequence, then the drive has to be recognized and mounted. Imagine, if for some reason, the OS can't find the drive. It will get stuck at its boot sequence, waiting for the user to tell it to continue or not. You don't want this to happen.

What you need is autofs. Just apt-get install autofs and configure automounts -> create an entry for this drive in /etc/auto.master.

Example: /mnt /etc/auto.mnt --timeout=120 --ghost; Then in /etc/auto.mnt put: ``backup -fstype=ntfs,rw UUID=

I can reproduce your problem and explain it. And fix it, I think.

Short explanation

For some reason the first sector of your disk, when interpreted as MBR, contains semi-valid partition table. Either OS has no reason to assume it is a superfloppy.

Long explanation

MBR vs VBR

Most disks we use have been partitioned. It this case the first 512 bytes of the disk is Master Boot Record (MBR). Even in GUID Partition Table (GPT) the first 512 bytes form some kind of MBR for legacy reasons. The important thing is: every modern OS expects to find MBR at the very beginning of the disk.

Superfloppy is a disk that has been treated as a partition while creating a filesystem. In this case the first 512 bytes contain Volume Boot Record (VBR), like the beginning of a partition would normally do.

Some filesystems utilize VBR to keep their important metadata, NTFS is one of them. Both MBR and VBR can contain bootstrap code. On non-bootable devices this "code" may be trivial, protective or even insane. There is no clear pattern, that's why you cannot tell for sure if your 512-byte sector is MBR or VBR or something else.

In general case the best thing you can do is check if the appropriate fragment looks like a sane MBR partition table. I think this is what operating systems do. Unfortunately it is possible to have a VBR that passes this test.

The problem

Let's compare a basic MBR layout (from here) to NTFS VBR layout (from here):

    MBR    │ byte offset │  NTFS VBR
           │  hex / dec  │
───────────┼─────────────┼─────────────
           │ 0x000 / 000 │ mainly NTFS
 bootstrap │      …      │  metadata
   code    ├─────────────┼─────────────
           │ 0x054 / 084 │
           │      …      │  bootstrap
───────────┼─────────────┤    code
 partition │ 0x1BE / 446 │
   table   │      …      │
───────────┼─────────────┼─────────────
   0x55    │ 0x1FE / 510 │    0x55
   0xAA    │ 0x1FF / 511 │    0xAA
───────────┴─────────────┴─────────────

I took my USB stick and created NTFS superfloppy with mkntfs -F -f /dev/sdc. The tool overwrote the whole first sector, including the bootstrap code area. Windows or another OS can assume for a while it's MBR and check its partition table area. This is what it will get:

#fdisk -l /dev/sdc

Disk /dev/sdc: 31.5 GB, 31466323968 bytes
64 heads, 32 sectors/track, 30008 cylinders, total 61457664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2052474d

This doesn't look like a partition table
Probably you selected the wrong device.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   ?     6579571  1924427647   958924038+  70  DiskSecure Multi-Boot
/dev/sdc2   ?  1953251627  3771827541   909287957+  43  Unknown
/dev/sdc3   ?   225735265   225735274           5   72  Unknown
/dev/sdc4      2642411520  2642463409       25945    0  Empty

Partition table entries are not in disk order

As you can see fdisk is able to tell that "this doesn't look like a partition table". Windows will tell basically the same thing, then it will assume the sector is VBR, find NTFS signature in it, finally mount. Indeed ye olde Windows XP had no problem with this. Also my Kubuntu reported in dmesg:

sdc: unknown partition table

but then KDE offered to mount it as superfloppy.

Note that any tool that probes for partition table reads in fact a fragment of bootstrap code from the VBR. This code is not needed for NTFS to work. I checked with hexdump that the fragment is not code; it looks like a set of text messages that will be displayed if I try to boot from this device, e.g.:

Press Ctrl+Alt+Del to restart

This means I can create a semi-valid partition table and it will only mangle with the text messages which I would probably never see anyway.

Well, I did just that, with fdisk I created a partition table that looks valid. Of course it points to "partitions" without filesystems, because the only filesystem is still the NTFS on the superfloppy.

In Windows XP the drive behaves almost as your drive. Almost, because I got a letter assigned to the first partition. My real (superfloppy) NTFS filesystem is fresh and empty, yours is not. One of its sectors is interpreted as VBR for the first fake partition. Our sectors surely contain different data, maybe this is the reason. Nevertheless I believe I have just solved your mystery.

It looks as if somebody was about to partition your superfloppy and changed their mind between fdisk and mkfs.

The fix

In my case it was enough to write zeros to the partition table:

dd if=/dev/zero of=/dev/sdc bs=1 seek=446 count=64

If I want to restore the whole "bootstrap code" fragment of my superfloppy, I can copy it from another NTFS partition created by mkntfs:

fallocate -l 2MiB tmp.ntfs
mkntfs -F -f tmp.ntfs
dd if=tmp.ntfs of=/dev/sdc bs=1 skip=84 seek=84 count=426
rm tmp.ntfs