My Plextor NAS drive controller board broke down recently. It had two drives in RAID 1 configuration. The NAS drive runs linux. In trying to recover the data on the disks, I found http://www.linuxquestions.org/questi...1-disk-723225/ very helpful which described a very similar situation. However in following the same procedure I got the same results until just before the end.

"mdadm --assemble --scan --run" didn't work for me either, so I tried

mdadm --stop /dev/md0
mount /dev/sdb3 /mnt/old

mdadm stopped alright but in trying to mount the device, I still got the "mount: unknown filesystem type 'linux_raid_member" error.
So I still couldn't mount.

I can mount sdb2 on the same drive which is a small XFS partition
sdb1 is a Linux Swap

I'm a newbie to Linux, but because my situation was so similar and the responses to all the steps were equal, I don't know why I couldn't mount in the end.

Hope somebody can help me out.

BTW I also tried Disk Internals Linux Reader and it sees the partitions as EXT3 but still can't read them.

Boot from a live CD and use 'testdisk' software. http://www.cgsecurity.org/wiki/TestDisk
They have a live CD within it, you can download from that page.

testdisk is a small and smart TUI tool, that can discover and repair broken or lost partitions.

there is another TUI tool called 'photorec' that is useful to restore data (files) from damaged partitions or to restore deleted data.

LinuxSpiff, see if specifying the filesystems type helps.

That would be 'mount -t ext3 /dev/sdb3 /mnt/old'

The "mdadm --stop" should have removed the RAID metadata (at the end of the partition) that identifies it as being part of a software RAID array, but maybe it didn't and that's what mount is complaining about.

Or, if 'fdisk -l /dev/sdb' shows sdb3 is "fd Linux raid autodetect", maybe that is causing the problem. You can correct that by doing 'fdisk /dev/sdb', 't' (to change type), '3' (for your third partition), '83' (Linux partition), and 'w' (to write it back to disk). ('partprobe /dev/sdb' is sometimes required on some systems to get the kernel to re-read the modified partition table...)

If the other utility you used thinks it is ext3, then the filesystem is probably intact, it's just a matter of figuring out why mount doesn't like it.

(I'm assume that the drive is RAID1. None of the techniques that you find for accessing just one partition of a broken RAID array will work unless it's RAID1.)

tommylovell, thanks for the additional info.

However fdisk -l indicates that /dev/sdb3 is indeed ID=83, system 'Linux' so that is ok.
Still no mounting though.

I tried 'Testdisk' as MartinStrec proposed but was not able to have it successfully recover
the files.

But Testdisk said that there was something wrong with the size of the disk, indicating it
should be 1 Tb and not 500 Gb. So I got suspicious that maybe this disk hadn't been used
in Raid1 but Raid0. Then I found a file 'raidconf.info' on the second partition (this one mounts
alright) indicating : raid_enable=1, raid_mode=0 ...

So i guess that my suspicious is confirmed and all the instructions that you gave are not
applicable. Sorry for all your time. I learned a lot though !

The disks should normally be ok, so I will have to find somebody to lend me a Plextor NAS
where I can put both disks it and try to recover the files.

I just went through all the 'linux_raid_member' posts and didn't see my solution so I thought I would post it (here seems as good a place as any). I have a raid-1 pair of drives, and needed to be able to extract the data from one drive. The drive has 4 partitions, 3 ext4 and 1 swap. The first p1 needed to use the mdadm --stop method. The other 2 needed to use the add-it-to-mdadm.conf method and mdadm --assemble --scan --run. When I tried to mount p3 and p4 (p2=swap), with -t ext4, mount reported that it couldn't do it. e2fsck reported it couldn't recover anything and file -sL reported "data" (gasp!) as the filesystem. Adding p3 and p4 to mdadm.conf worked (whew!).