How can I read a HPFS/NTFS (Bootable) partition on Ubuntu (15.10)?

I would like to read the contents of an old hard drive that is formatted as a HPFS/NTFS (Bootable) partition; I'm not sure if the bootable part makes a difference. I have tried to mount the drive but cannot. How can I read this drive?

When using sudo fdisk -l, the drive shows up as:

:~$ sudo fdisk -l
Device     Boot Start       End   Sectors   Size Id Type
/dev/sdf1  *       63 488392064 488392002 232.9G  7 HPFS/NTFS/exFAT

Attempt using mount:

:~$ sudo mount /dev/sdf1 /mnt/ntfs1
mount: wrong fs type, bad option, bad superblock on /dev/sdf1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

Attempt using ntfs-3g;

:~$ sudo ntfs-3g /dev/sdf1 /mnt/ntfs1
NTFS signature is missing.
Failed to mount '/dev/sdf1': Invalid argument
The device '/dev/sdf1' 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?

Edit:

Attempt using mount -t exfat:

:~$ sudo mount -t exfat /dev/sdf1 /mnt/ntfs1
FUSE exfat 1.1.0
ERROR: exFAT file system is not found.

fsck report:

:~$ sudo fsck -f /dev/sdf1
fsck from util-linux 2.26.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdf1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Solution 1:

To begin, NEVER run fsck on a partition when you don't know that doing so is the right course of action. The problem is that fsck is a repair tool, and as such, it's likely to write data to the disk. In your case, you applied it before you even knew what filesystem was in use on the disk. This is extremely dangerous, since the repair tool might have become confused and made matters worse rather than better. Such an outcome is unlikely, but possible. You probably did no harm, but there's a slim chance that you've done more damage to the disk by using fsck on it.

To learn what sort of filesystem is on the disk, use blkid, as in:

$ sudo blkid /dev/sdb3
/dev/sdb3: UUID="493344495F520D15" TYPE="ntfs"

Of course, your output is likely to be different, but this example does show an NTFS volume. If you get no output whatsoever, that means that blkid couldn't identify the filesystem, which in turn means that it's very badly damaged. If there is output but TYPE= shows something other than ntfs, then that means that it's not an NTFS volume. Maybe the output will be obvious and you can proceed from there, or maybe you'll need to post back with details for more advice.

With the filesystem known, you can use filesystem-specific mount tools, and possibly repair tools. You've already tried mounting with the likely tools (NTFS and exFAT). The type code for the partition (0x07) was once commonly used for HPFS, but that would be likely only if the disk had been used with OS/2, and you say it was used with Windows 7.

Before using potentially destructive repair tools, it's wise to do a low-level backup, as in:

sudo dd if=/dev/sdf1 of=/path/to/lots/of/space/sdf1.img

This command backs up /dev/sdf1 to the file sdf1.img in /path/to/lots/of/space/. Be sure that there's enough free space to hold the entire partition -- about 233 GiB in your case. Making this backup will give you a way to recover if a repair tool makes matters worse, as does sometimes happen.

My hunch is that the disk uses NTFS but that it's damaged and/or was not properly shut down. If so, you must first repair it with Windows tools. The Linux ntfsfix utility is poorly-named; it does only the most minimal checks and then flags the disk as needing attention in Windows. There is no Linux support for NTFS in fsck, so you should not try to use fsck on an NTFS volume.

It's also conceivable that there's something more exotic going on. For instance, the disk might have been used in a RAID array, in which case you might not be able to recover anything without the other disk(s) from the same array. (Specifics would depend on the type of RAID used and other details.)

In a worst-case scenario, you may be able to use PhotoRec to recover individual files.

One more point: In your comments, you said you ran GParted on /dev/sdf1. This is useless -- and even potentially dangerous. /dev/sdf1 is the partition, but GParted is meant to be used on the whole disk -- that is, /dev/sdf.

Solution 2:

In my case, this issue was resolved using dislocker as I had a windows 10 bitlocker locked hard drive.