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

_{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.