Hi. This is my first post on this forum. I have an external hard drive (Western Digital 1 TB WD10EADS). It failed over the weekend. I connected it to another computer but it doesn't map a drive in Windows. It is detected in Disk Management in Windows and in the BIOS. I would like to try to pull some files off of it if possible. I booted up a machine in Knoppix 7.2. It sees the hard drive but says "Disk /dev/sdb doesn't contain a valid partition table." I've tried mounting the disk but it says moint point /mnt/sdb does not exist.

I'm wondering if anyone has seen this before and can offer some assistance. I would really appreciate any help you could give. Thanks.

Jeff

Is there no partition /dev/sdb1 (or any number)?
If not, the partition table is indeed corrupted.
You could try to write a new partition table with fdisk for Linux - if you dare.
I have done this before, fdisk only changes the partition table and nothing else. All other partition programs I've seen changes a lot more, effectively destroying data.
Of course, I can't guarantee it only tell what I've done.
If the disk only had one partition then simply create a new with fdisk, spanning the whole disk.
Make sure to set the right filesystem.
Then try to mount it.

Thanks for your reply. That makes sense. Excuse my ignorance but what is the command to create a new partition table? I'm just afraid I'll try something wrong and damage the data.

This is the sequence:

You don't think this will overwrite my data? This was an NTFS partition initially.

Well, I've tested this before and no data was overwritten. But it's you that have to take the risk.
Here's one test I did:
A disk with 3 primary partitions, one system (/) partition for some Linux and 2 data partitions. Linux booted fine.
I printed out the partition table, then zeroed out the first 512 bytes of the disk. This left the disk with no partition table, and of course unbootable.
Then I booted a live-cd, used fdisk to recreate the partitions.
Reboot, voila! all 3 partitions were back and the system booted up fine.
The thing is, fdisk does not change any superblock or whatever, it only writes into the partition table residing at the beginning of the disk. Thus no data is touched.
But mind you, this works with primary partitions only, logical volumes are not defined in the partition table.
And again, this is what I would do - but it's your disk, you have to decide. Don't blame me if it doesn't work or you mess it up doing something wrong.
If you can, get some other disk and test with - you're obviously not familiar with fdisk so I would definitely recommend you to test it first!

Now it says that the NTFS signature is missing. When I open up PCMan, it shows up but is empty. I tried to manually mount it but got the error message. Grrr.

Got lots of links googling on "NTFS signature", try that.
But again, I strongly suggest you test this first, especially if you're not very familiar with these things. Doing something wrong might destroy your chances to get your data back.

Do NOT write anything to the bad HDD, doing so can overwrite data that you want to recover.

As the partition will not mount and the drive is gonna fail soon, I think your only chance now is to use 'ddrescue' to image the HDD to another larger disk. After doing this you can use testdisk/photorec and foremost to get your data off.

If you can mount the HDD internally then it might be a good idea, to exclude possible failure of the SATA/USB conversion hardware part of the enclosure.

Please do not recommend this again. It is very likely to destroy data. I'm assuming you made a mistake and mistakenly shared it with others.

Nope, it will not destroy data if done right.
I realize it sounds like a bad idea, but I have tested this so many times and it works fine. Read the test I did, I have done that over and over again.
The thing is, fdisk does not alter anything but the partition table. Try it out!
Use an old disk and experiment, you'll see that you can easily recreate all primary partitions without any data loss!

Why wouldn't you use testdisk instead, which can recover damaged partitions ? You would risk getting something slightly wrong and overwriting your data ?

As Spock might say, that is logically inconsistent. You are yelling at people to not write to the disk, but recommending testdisk ?. This is the same as fdisk writing (primary) partition entries.

Generally testdisk is the (best) answer, but can be complex for new users. Generally using fdisk is a last resort for those who know what they are doing - however, if you define a partition across the entire device, the first filesystem will usually be mountable. Regardless of size.
Any other filesystem(s) will be safe unless the initial filesystem is enlarged.

Looks like a corrupted disk - maybe unplugged while still writing.

It's pure logic, I did recommend NOT to write to the disk. The second post, where I ask a question, it is NOT making a recommendation. If you want a purely logical and pedantic statement it would be: If I would decide to write to the disk, then I would use testdisk and not fdisk, except as a last resort. They both write to the disk, but testdisk is designed to recover partitions, whereas fdisk is designed to write and overwrite partitions, among other things. Please let the pedantism end here, it doesn't help anyone, it's just a rather menial method of criticism.

Either way, it didn't work in this case, and luckily it didn't cause any harm.

Also note that I'm NOT saying that fdisk WILL cause damage, or that you are wrong in your personal experience with fdisk. I am saying that using fdisk is wrong here, except as a very last resort, because it can cause damage and it is not designed for this purpose. I also understand that you (pingu) are defending your position, but I ask you to reconsider the issue and whether it is the right program to use. Likely, what I said will have absolutely no effect on anything, but I leave it here for others to read and consider anyway.

In this thread my next response will be only to directly address the OP's next post.

Writing the partition table is writing the partition table, regardless of what tool does it. In the hands of someone not familiar with it, testdisk is by far the more dangerous tool, for several reasons:

• It can try to "recover" what it might see as logical partitions within a missing extended partition, and doing that can easily overwrite data,
• testdisk is capable of doing a lot more than just recovering a partition table, and some of those actions should never be taken on your only copy of the data on that disk,
• testdisk has a fairly awkward and unclear user interface, which can easily lead an unfamiliar user to do the wrong thing.

fdisk is a much safer tool to use. You would have to deliberately alter an extended partition or the logical partitions within to get it to write anywhere other than the last 66 bytes of the MBR.