How do I mount a multi-disk Windows NTFS RAID/logical drive on Linux?

▲
5
▼

I have two 500GB hard drives from an old Windows laptop at my workplace. My boss has asked me to copy the contents to the file server if possible, with the caveat that absolutely no data may be lost.

Normally, backups would suffice for this, but this was from the earlier days of the operation when stuff like backups weren't kept more strictly, and this guy was notoriously poorly organized, so I'm not sure whether the backups have the most up-to-date (or even reasonably up-to-date) contents.

First thing I did was to produce images using ddrescue. The drive that has the partition table copied without errors, and the other drive lost ~150 KiB to errors. The images were mounted read-only to /dev/loop1 and /dev/loop2 using losetup. fdisk -l shows the following:

Disk /dev/loop1: 465.8 GiB, 500107862016 bytes, 976773168 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 /dev/loop2: 465.8 GiB, 500107862016 bytes, 976773168 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
Disklabel type: dos
Disk identifier: 0x87afa6ad

Device       Boot      Start        End    Sectors   Size Id Type
/dev/loop2p1            2048   31459327   31457280    15G 27 Hidden NTFS WinRE
/dev/loop2p2 *      31459328   31664127     204800   100M 27 Hidden NTFS WinRE
/dev/loop2p3        31664128 1191071167 1159407040 552.9G  7 HPFS/NTFS/exFAT
/dev/loop2p4      1191071168 1953533951  762462784 363.6G  7 HPFS/NTFS/exFAT

The partition sizes seemed to suggest that this was a RAID array or Windows logical drive, and a quick check with blkid showed that the drive types were isw_raid_member. Attempting to assemble the array with mdadm -v --assemble /dev/md0 /dev/loop2 /dev/loop1 produced the following output:

mdadm: looking for devices for /dev/md0
mdadm: Cannot assemble mbr metadata on /dev/loop2
mdadm: /dev/loop2 has no superblock - assembly aborted

Other things I tried either to mount the drives or get more information were:

  • mount /dev/loop2 <mount point>: Failed with unknown filesystem type 'isw_raid_member'
  • mount -t with NTFS and exFAT: Unable to find file system
  • mount /dev/loop2p[1234]: Special device <dev> does not exist
  • mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/loop[21]: States that /dev/loop2 appears to be part of a raid 0 array with no devices and a creation date of 00:00:00 Jan 1 1970
  • mdadm -E /dev/loop[12]: States that no md superblock was detected on /dev/loop1 and prints out the partitions and MBR magic number of aa55 for /dev/loop2
  • file -s /dev/loop1: prints /dev/loop1: data
  • file -s /dev/loop2: spits out a block of text basically saying it's a DOS/MBR boot sector and the gives raw numbers for partition offsets/sizes.

  • mount -t ntfs -o ro,offset=$((512*2048)) /dev/loop2 /mnt/partition1:

    NTFS signature is missing
Failed to mount '/dev/loop3': Invalid argument
The device '/dev/loop3' doesn't seem to have a valid NTFS

    No, I didn't mistype that 3. No clue where it came from.

  • dmsetup create mydisk, followed by 0 1953546336 striped 2 <num> /dev/loop2 0 /dev/loop1 0, followed by <enter> and ^D:

    • If <num> >= 32, command fails with

      device-mapper: reload ioctl on mydisk failed: Invalid argument
Command failed

    • If <num> == 1, the command succeeds, and fdisk -l shows the following:

      Disk /dev/mapper/mydisk: 931.5 GiB, 1000215724032 bytes, 1953546336 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1024 bytes
Disklabel type: dos
Disk identifier: 0x87afa6ad

Device                   Boot      Start        End    Sectors   Size Id Type
/dev/mapper/mydisk-part1            2048   31459327   31457280    15G 27 Hidden HTFS WinRE
/dev/mapper/mydisk-part2 *      31459328   31664127     204800   100M 27 Hidden HTFS WinRE
/dev/mapper/mydisk-part3        31664128 1191091167 1159407040 552.9G HPFS/NTFS/exFAT
/dev/mapper/mydisk-part4      1191071168 1953533951  762462784 363.6G  7 HPFS/NTFS/exFAT

      mount /dev/mapper/mydisk <dir> fails with

      mount: wrong fs type, bad option, bad superblock on /dev/mapper/mydisk,
       missing codepage or helper program, or other error

      Trying partprobe results in three lines of the following message:

      Warning: Error fsyncing/closing /dev/mapper/mydisk: Input/output error

      fdisk -l then shows the following new devices:

      Disk /dev/mapper/mydisk1: 15 GiB, 16106127360 bytes, 31457280  sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1024 bytes
Disklabel type: dos
Disk identifier: 0x6e697373

Device
/dev/mapper/mydisk1-part1      1936269394 3772285809 1836016416 875.5G 4f QNX4.x 3rd part
/dev/mapper/mydisk1-part2      1917848077 2462285169  544437093 259.6G 73 unknown
/dev/mapper/mydisk1-part3      1818575915 2362751050  544175136 259.5G 2b unknown
/dev/mapper/mydisk1-part4      2844524554 2844579527      54974  26.9M 61 SpeedStor

Partition table entries are not in disk order

Disk /dev/mapper/mydisk2: 100 MiB, 104857600 bytes, 204800  sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1024 bytes
Disklabel type: dos
Disk identifier: 0x6e697373

Device
/dev/mapper/mydisk2-part1      1936269394 3772285809 1836016416 875.5G 4f QNX4.x 3rd part
/dev/mapper/mydisk2-part2      1917848077 2462285169  544437093 259.6G 73 unknown
/dev/mapper/mydisk2-part3      1818575915 2362751050  544175136 259.5G 2b unknown
/dev/mapper/mydisk2-part4      2844524554 2844579527      54974  26.9M 61 SpeedStor

Partition table entries are not in disk order

Disk /dev/mapper/mydisk3: 552.9 GiB, 593616404480 bytes, 1159407040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1024 bytes
Disklabel type: dos
Disk identifier: 0x6e697373

Device
/dev/mapper/mydisk3-part1      1936269394 3772285809 1836016416 875.5G 4f QNX4.x 3rd part
/dev/mapper/mydisk3-part2      1917848077 2462285169  544437093 259.6G 73 unknown
/dev/mapper/mydisk3-part3      1818575915 2362751050  544175136 259.5G 2b unknown
/dev/mapper/mydisk3-part4      2844524554 2844579527      54974  26.9M 61 SpeedStor

Partition table entries are not in disk order

Disk /dev/mapper/mydisk4: 363.6 GiB, 390380945408 bytes, 762462784 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1024 bytes

      Trying to mount one of these new devices, with or without an offset=<num> argument, results in the following:

      mount: wrong fs type, bad option, bad superblock on /dev/mapper/mydisk2,
       missing codepage or helper program, or other error

    • If <num> == 8, almost everything is the same. The only differences are that mount /dev/mapper/mydisk <dir> fails with this message:

      mount: unknown filesystem type 'isw_raid_member'

      fdisk -l has the following lines above Partition table entries are not in disk order:

      Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.
Partition 4 does not start on physical sector boundary.

      And trying to mount one of /dev/mapper/mydisk[1-4] spits out the following:

      ntfs_mst_post_read_fixup_warn: magic: 0x000014b9  size: 1024   usa_ofs: 26112  usa_count: 1975: Invalid argument
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0 usa_count: 65535: Invalid argument
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0 usa_count: 65535: Invalid argument
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0 usa_count: 65535: Invalid argument
$MFTMirr does not match $MFR (record 0).
Failed to sync device /dev/mapper/mydisk1: Input/output error
Failed to mount 'dev/mapper/mydisk1': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chksdk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

      All powers of two between 1 and 16 inclusive resulted in one of the two variations of errors messages shown above.

I also looked at Recovering a failed software RAID, but that seems to be for already working Linux arrays being recovered on Linux (not to mention quite a bit goes over my head).

Is there anything I can do to get these images mounted safely?

linux
hard-drive
raid
data-recovery
logical-drive
asked on Super User Aug 19, 2016 by awksp • edited Aug 21, 2016 by awksp

1 Answer

▲
2
▼

Note: I'm writing this answer after the OP got help via comments, trials and errors. Having other users in mind, I'm making the answer broader and little more generic.

If these two disks worked together, they might be

  1. mirrored, RAID1-style;
  2. or concatenated, JBOD-style;
  3. or striped, RAID0-style.

The cases are ordered starting from the easiest to deal with. I will instruct you how to tell them apart and how to deal with them to mount the partitions eventually.

Mounting should be done with -o ro first, until you're sure you got it right. In some cases mount may succeed and give you access to mangled directory structure and/or scrambled files. Insane data and/or metadata indicate you didn't get it right. Mounting read-only ensures you won't harm the image(s).

1. mirrored, RAID1-style

In this case both disks should contain the same data, if healthy; they both should contain the same valid partition table. Only the image you have as /dev/loop2 reports a partition table. This may be because

  • they were not mirrored in the first place,
  • or these errors you mentioned on the other disks occurred where the partition table is (in case of DOS partition table it's MBR, i.e. at the very beginning, sector number 0).

There is however one big clue that makes RAID1 hardly probable in your case: fdisk says there are exactly 976773168 sectors on a single disk, but the last sector of the fourth partition is 1953533951. This is almost twice as much, it suggests the partition layout spawns on two non-mirrored disks.

But let's say your disks were twice as big and the above clue didn't apply. If you believe you may deal with mirrored disks then work with the image obtained without errors, leave the other image alone. Try to mount the partitions like this:

mount -o ro,offset=$((512*2048)) /dev/loop2 /mnt/partition1
mount -o ro,offset=$((512*31459328)) /dev/loop2 /mnt/partition2
mount -o ro,offset=$((512*31664128)) /dev/loop2 /mnt/partition3

etc. You may even not use losetup to get /dev/loop2 but provide the file path directly, mount should create a loop device on its own and handle this just fine:

mount -o ro,offset=$((512*2048)) /path/to/the/image2.raw /mnt/partition1

2. concatenated, JBOD-style

If disks building JBOD use MBR to store the partition table, fdisk will find it only on the very first disk. Other disk(s) may report nothing or some insane partition table(s); the probability of getting a partition table that looks sane from not-the-first disk is very low, but even then this partition table means nothing.

If disks building JBOD use GPT to store the partition table, tools like gdisk will find the primary table on the very first disk, the secondary (backup) table on the very last one.

You have two images, one of them reports a DOS partition table (i.e. a partition table in MBR), the other reports no partition table. Should they create JBOD, you know the one corresponding to /dev/loop2 goes first.

In your case the partitions 1 and 2 are small enough to entirely fit into the first disk of JBOD. You can try to mount them with appropriate offset from the sole /dev/loop2. If this gives you access to sane filesystems then you will know JBOD is probably the right setup. To access all the partitions you need to concatenate images.

This answer of mine provides a way to concatenate images without writing the result to disk. In your case the procedure may be:

  1. dmsetup create mydisk
  2. type 0 976773168 linear /path/to/the/image2.raw 0 Enter
  3. type 976773168 976773168 linear /path/to/the/image1.raw 0 Enter
  4. hit Ctrl+D

The resulting device should be /dev/mapper/mydisk. Try to mount any partition from it with appropriate offset=….

To destroy the device invoke dmsetup remove mydisk.

3. striped, RAID0-style

Similarly to JBOD, if disks building RAID0 use MBR to store the partition table, fdisk will find it only on the very first disk. Other disk(s) may report nothing or some insane partition table(s); the probability of getting a partition table that looks sane from not-the-first disk is very low, but even then this partition table means nothing.

If disks building RAID0 use GPT to store the partition table, the situation gets complicated. Depending on how big the stripe size is, you may or may not get the primary partition table from the very first disk, you may or may not get the secondary (backup) partition table from the very last disk. You should get a legacy MBR from the very first disk (unless a read error occurs).

You have two images, one of them reports a DOS partition table (i.e. a partition table in MBR), the other reports no partition table. Should they create RAID0, you know the one corresponding to /dev/loop2 goes first. What you don't know is the stripe size. In general there is no firm way to know it, you should try common values and analyze the results.

The procedure to interleave your images and to create a virtual device is as follows:

  1. dmsetup create mydisk
  2. type 0 1953546336 striped 2 256 /dev/loop2 0 /dev/loop1 0 Enter
  3. hit Ctrl+D

The resulting device should be /dev/mapper/mydisk. The number 256 means the stripe size of 128 KiB and it must be guessed right. In general, regardless of possible troubles with GPT before dmsetup, now gdisk -l /dev/mapper/mydisk should return a valid partition table if you guess the stripe size right. If you guess it wrong, the partition table may or may not be valid. If it looks valid, try to mount all the partitions from it with appropriate offset=… values.

In your case the partition table will certainly be the one you got from /dev/loop2.

Beware that even with a wrong guess you may be able to mount but the files will be scrambled. In this case umount, invoke dmsetup remove mydisk and repeat dmsetup create… with another value instead of 256. Numbers to try: 8, 16, 32, 64, 128, 256, maybe other powers of 2. If possible, read files with verifiable content (media like MP3, do they play without jitter?) or formal structure (like PDFs, do they open without errors?) to tell if your guess is right. Files smaller than the right stripe size may not show that your guess is wrong, so you should rather use an avi of 700 MB, not just a text file of few KB.

To destroy the device invoke dmsetup remove mydisk.

answered on Super User Jul 17, 2018 by Kamil Maciorowski

User contributions licensed under CC BY-SA 3.0