search

jivanpal / drat

Utility for performing data recovery and analysis of APFS partitions/containers.
GNU General Public License v3.0
163 stars 21 forks source link

No container superblock with an XID that doesn't exceed 0xffffffffffffffff #37

Closed kilojarek closed 2 years ago

kilojarek commented 2 years ago

Hi, I am trying to recover a partition from a drive /dev/disk8. The partition is at /dev/disk9s3 but when I run

drat recover /dev/disk9s3 0 ~/recovered_stuff

I get:

Opening file at `/dev/disk9s3` in read-only mode ... OK.
Simulating a mount of the APFS container.
FAILED: read_blocks: An unknown error occurred whilst reading from the stream.
ABORT: Failed to successfully read block 0x0.

When I do

drat inspect /dev/disk9s3

I get ABORT:

Simulating a mount of the APFS container.
Reading container superblock at address 0x0, assuming default block size of 4096 bytes ... FAILED: read_blocks: An unknown error occurred whilst reading from the stream.
ABORT: Failed to successfully read block 0x0.

(BTW the online documentation is not up to date, as the command syntax is different)

So then I go directly for the entire drive /dev/disk8:

drat recover /dev/disk8 2 ~/recovered_stuff

And I get this:

Opening file at `/dev/disk8` in read-only mode ... OK.
Simulating a mount of the APFS container.
Validating checksum of block 0x0 ... FAILED.
!! APFS ERROR !! Checksum of block 0x0 should validate, but it doesn't. Proceeding as if it does.
OK.

ABORT: Block 0x0 isn't a container superblock.

!! APFS ERROR !! Container superblock at 0x0 doesn't have the correct magic number. Proceeding as if it does.
Locating the checkpoint descriptor area:
- Its length is 0 blocks.
- It is contiguous.
- The address of its first block is 0x0.
Loading the checkpoint descriptor area into memory ... OK.
Locating the most recent well-formed container superblock in the checkpoint descriptor area:
No container superblock with an XID that doesn't exceed 0xffffffffffffffff exists in the checkpoint descriptor area.

Is there no hope for me? Or is there something with the software?

I should also add that I am really after a specific folder on the drive, but I don't remember its path and explore-fs-tree asks for block addresses. Is there a way to provide block addresses to display everything on the partition for me to figure out the path to recover a specific folder? Or does the above error suggest that it's impossible to even view the contents of the drive?

Thanks!

jivanpal commented 2 years ago

Hi, if you are using v0.1.3, please see the help text that the commands output for the syntax. The online documentation is a draft that covers the current development version.

It looks like you are specifying the wrong device node. You must specify the APFS partition, which it sounds like is disk8sX, rather than any APFS volume, which it sounds like disk9sX are. You can identify the device node from the output of diskutil list or diskutil apfs list, in which it is called the "physical store".

kilojarek commented 2 years ago

Hi, thanks a lot for the reply and sorry for the delay - I missed the notification from GitHub. And yes, I am using v0.1.3.

So... you were right. When I specify the "physical store" partition, I no longer get these errors. However, I still cannot recover the partition I need. Here is the output of drat recover /dev/disk2s2 0 ~/recovered_stuff

Opening file at `/dev/disk2s2` in read-only mode ... OK.
Simulating a mount of the APFS container.
Validating checksum of block 0x0 ... OK.
Locating the checkpoint descriptor area:
- Its length is 280 blocks.
- It is contiguous.
- The address of its first block is 0x30025.
Loading the checkpoint descriptor area into memory ... OK.
Locating the most recent well-formed container superblock in the checkpoint descriptor area:
- It lies at index 250 within the checkpoint descriptor area.
- The corresponding checkpoint starts at index 249 within the checkpoint descriptor area, and spans 2 blocks.

Loading the corresponding checkpoint ... OK.
- There are 26 checkpoint-mappings in this checkpoint.

Reading the Ephemeral objects used by this checkpoint ... OK.
Validating the Ephemeral objects ... OK.
The container superblock states that the container object map has Physical OID 0x275d28.
Loading the container object map ... OK.
Validating the container object map ... OK.
Reading the root node of the container object map B-tree ... OK.
Validating the root node of the container object map B-tree ... OK.
The container superblock lists 1 APFS volumes, whose superblocks have the following Virtual OIDs:
- 0x47bb15

Reading the APFS volume superblocks ... OK.
Validating the APFS volume superblocks ... OK.

 Volume list
================
 0: Vol1
The volume object map has Physical OID 0x27630c.
Reading the volume object map ... OK.
Validating the volume object map ... OK.
Reading the root node of the volume object map B-tree ... OK.
Validating the root node of the volume object map B-tree ... OK.
The file-system tree root for this volume has Virtual OID 0x47bb16.
Looking up this Virtual OID in the volume object map ... corresponding block address is 0x28493a.
Reading ... validating ... OK.
Could not find a dentry for that path. Exiting.

Everything looks fine but it only sees a single partition on that volume. I have two there and the one I need to recover is the other one. According to diskutil list, the physical store is disk2s2 and the partition I'd like to recover is disk9s3. The Vol1 partition that is seen above is at disk9s1.

drat inspect /dev/disk2s2 does its thing, but only for the Vol1, it also doesn't see any other partitions there.

I have a feeling there are some unknown unknowns here for me... Why can't the other partition be accessed by drat if it's seen by diskutil?

Any help will be greatly appreciated :-)

jivanpal commented 2 years ago

Hello, again please see the help output for drat recover. It does not currently recover entire directory trees (support for this planned), only individual files. Please see #30 for guidance on how to recover an entire directory.