# Mounting HD without partitions

## R4miu5

Hi,

i recently deleted some important files on my Western Digital Netcenter Network harddrive.

In order to recover them i connected the HD to my linux box but found out, it had no partition table on it. The WD support told me, they couldn't tell me something about the partition table but the filesystem used is reiser. So i tried a few things.

Restoring the Partition table is not possible, not with testdisk not with gpart.

I suppose it has no partitions and the files are on the hd itself /dev/hdc

But trying to mount it failed.

In a former thread i was adviced to use

```
mount -o loop,ro,offset=32256 -t <your_fs> /dev/sda /mnt/some/mountpoint
```

I also tried a script that tried to mount the hd with offsets ranging from 1 to 600.000 with unfortunately no success.

So, how do i mount this disk? And how do i get the offset?

could i possibly use hexdump to find out where the reiser fs begins? And how does the beginning of a reiserfs look like??

thanks in advance a lot for any advice

P.S. I had another thread about this problem, but i marked it as given up, because the problem i encounter now, is another than i had there. That's why I opened another topic.

----------

## NeddySeagoon

R4miu5,

Different architectures have different partition table schemes. We have been assuming that the disk uses MS DOS Partiton table format but there are many others. Look in the kernel config tool of your choice for a list.

If you NAS is not IA32 based (very likely), its likely the partition table is intact but foriegn to your PC.

What CPU does your Netcenter use ?

----------

## R4miu5

Thank you NeddySeagoon. Your Signatue is just too right. Funnily the Netcenter was my backup -.-...

I wrote to WD and am currently waiting for an answer.

I don't think the netcenter has an Ithanium. It was too cheap for that (200).

Something i could imagine would be that they use some kind of LVM. Could that be possible? Could you use LVM without having partitions on your HD?

I suppose, I'll read some things about LVM...

bye

----------

## NeddySeagoon

R4miu5,

I would not be surprised to learn that it uses an ARM CPU of some sort. They are low cost and available as a 'part' to go into an FPGA or and ASIC, which reduces the cost of the finished product, since all the I/O you need can be swept up into the same FPGA/ASIC. You can end up with everything in one chip, almost.

If you want to prepare your kernel, look under File systems -> Partition Types -> Advanced partition selection.

If you are like most PC users, only  PC BIOS (MSDOS partition tables) support will be on now, you probably need another one to read your drive.

----------

## R4miu5

Well, I decided to just give it up  :Sad: 

I compiled all other partition types into my kernel, but still i find none on the harddrive...

I guess my data is lost...

Thanks for your help anyway.

P.S. The WD support wasn't helpful either...

----------

## NeddySeagoon

R4miu5,

Maybe not .... it depends on the data now. If your data contains text (the directory entries must do) you may still be able to recover the data.

Proceed carefully as follows. 

```
emerge hexedit
```

This program is a binary (hex) editor. Its not the most user friendly program in the world but it comes with a lot of useful commands. It can search files or whole disks for hex sequences, which you may enter as a string.

Find the /dev/ entry for the disk in question and chmod it so its world readable. It will be something like 

```
brw-rw---- 1 root disk 3, 0 Nov 24 16:16 /dev/hda
```

and chmod it so it becomes world readable. That would be 

```
chmod 664 /dev/hda
```

in this example.

*NEVER* use hexedit as root. You can trash your system very easily since it does not use kernel filesystem calls and does not respect filesystems in any way. However, as you have may the disk to be investigated world readable, the only danger is to areas your normal user has write access to. With that caution in mind run

```
hexedit /dev/hda
```

This opens the whole disk in hexedit read only, enforced by the permissions you set above.

Now it gets long tedious and boring. Enter a search string. When you get a hit, look at it. If its interesting, you can mark the start and end of a block and write it to a file in your normal users /home/<user>/. Rinse and repeat.

Its safe to look at files and your whole PC disk in this way, so you have something to compare with. Be warned that makeing a disk world readable is a security hole. Any user can then read the entire drive, so don't forget to fix the permissions at the end of your session.

Oh, and *never* use hexedit as root. 

Another hint ... the filesystem may be byte swapped compared to IA32, so searching for R4miu5 may fail but 4Rim5u may get a hit.

Good luck.

----------

## R4miu5

Hey, that quite works,

just a few questions:

If i find a file (lets say, it's called blablabla.jpg) How do I acutally recover it? I can see the files but I don't really know, how to actually find out, where the file starts and where it ends...

And could it be possible, to recover whole directories that way? One directory of what i deleted was for example my photo collection which contained several hundred files...

Thank you for your help though...  :Smile:  I'm getting quite optimitic, that i might at least get something back...

----------

## NeddySeagoon

R4miu5,

So far so good ...

Now you need some calibration data, which you can get from your PC.  JPEG files contain a header, I doint know exactly what but the file format description will be on the web. Some of it will be constant, some will describe the file content, if you  are really lucky, it will include the file length.

You can use the constant part as a search string, e.g. if jpeg appears at the 8th byte of all jpeg files you know you have found the start of something interesting when hexedit shows jpeg 8 bytes from the start of a 512 byte (0x200) boundary. If the header also contains the lenght, you can work on the assumption that all the bytes are seqental on the disk, which will be mostly true.

You need from the start of the block to the end of the block length bytes away. Don't worry about getting it exactly right, excess at the end of of a rescued file will be ignored. Growing extra fingers to count in hex will be very useful at the point. A lot of calculators have a hex mode too.

Having established the begining and end of a file of interest, you can mark them in hexedit any save the marked bit to a file in your /home/<usr>. Look at the file with gimp to see what you have got. All the data on the drive is still there but all the metadata (data about the data) has been destroyed by the delete operation, so its one image at a time.

For practice and its worth doing this, open a known jpeg file (not whole disk) in hexedit from your PC to see what it looks like. You can practice the marking and copying too.

Should the header not contain length information but you know you saved a lot of jpegs at the same time, the chances are that they are all in sequential bytes. so saving the blocks between two headers may recover something useful.

Oh, as you may have guessed, I aquired this knowledge because I needed to, much like you do now. 

If you have some quick questions, you can often find me in IRC at irc.freenode.net in #gentoo-uk

----------

