ABORT: get_fs_records: Need to descend to node with Virtual OID 0x3096b, but the volume object map lists no objects with this Virtual OID.

[lsylx]

I have a external hard drive and I got some problems while mounting it.
I tried fsck -y /dev/disk5s1 and got a failed result

root@liushanyindembp ~ # fsck_apfs -y /dev/disk5s1                                                
** Checking the container superblock.
   Checking the checkpoint with transaction ID 93949.
** Checking the space manager.
** Checking the space manager free queue trees.
** Checking the object map.
** Checking volume /dev/rdisk6s1.
** Checking the APFS volume superblock.
   The volume lsy was formatted by diskmanagementd (1677.100.114) and last modified by apfs_kext (1933.0.84.151.1).
** Checking the object map.
error: btn: oid (3456675), xid (84037), type (0x40000003), subtype (0xb), flags (0x4) level (1)
error: btn: invalid key order (0) oid 3456675 / oxid 0
	previous key: 59 09 03 00 00 00 00 00 63 1e 00 00 00 00 00 00
	current key:  c2 29 08 00 00 00 00 00 b0 f4 00 00 00 00 00 00
	next key:     a8 2a 08 00 00 00 00 00 c4 f4 00 00 00 00 00 00
   Object map is invalid.
** The container /dev/disk5s1 could not be verified completely.

Then I tried drat and got results like this.

root@liushanyindembp ~ # ./drat-0.1.2-darwin-amd64  list /dev/disk5s1 0 /
Opening file at `/dev/disk5s1` 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 284 blocks.
- It is contiguous.
- The address of its first block is 0x292a2.
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 273 within the checkpoint descriptor area.
- The corresponding checkpoint starts at index 272 within the checkpoint descriptor area, and spans 2 blocks.

Loading the corresponding checkpoint ... OK.
- There are 51 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 0x327afd.
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 4 APFS volumes, whose superblocks have the following Virtual OIDs:
- 0x41f
- 0xd1b0d
- 0x439
- 0xe9514

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

 Volume list
================
 0: lsy
 1: Encrypted
 2: Backup
 3: maco
The volume object map has Physical OID 0x34d85c.
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 0x420.
Looking up this Virtual OID in the volume object map ... corresponding block address is 0x36c8d9.
Reading ... validating ... OK.

ABORT: get_fs_records: Need to descend to node with Virtual OID 0x3096b, but the volume object map lists no objects with this Virtual OID.

Could anyone help to solve this problem, the content inside of it is quite important for me.

[jivanpal]

** Checking the object map.
error: btn: oid (3456675), xid (84037), type (0x40000003), subtype (0xb), flags (0x4) level (1)
error: btn: invalid key order (0) oid 3456675 / oxid 0
	previous key: 59 09 03 00 00 00 00 00 63 1e 00 00 00 00 00 00
	current key:  c2 29 08 00 00 00 00 00 b0 f4 00 00 00 00 00 00
	next key:     a8 2a 08 00 00 00 00 00 c4 f4 00 00 00 00 00 00
   Object map is invalid.

These keys appear to be in order (Virtual OIDs 0x30959, 0x829c2, 0x82aa8), so I'm not sure why fsck_apfs is complaining here. This might be a bug worth reporting to Apple.

ABORT: get_fs_records: Need to descend to node with Virtual OID 0x3096b, but the volume object map lists no objects with this Virtual OID.

This means exactly what it says. Unfortunately, your "lsy" volume's omap tree is corrupt/malformed, so its root directory / cannot be found. We don't yet have an easy way to search for blocks without modifying the source code, and what searching functionality is there is not efficient. This is something I will be working on within the next few weeks, so if you are willing to wait a month or so, we will probably have an easy way for you to recover your data by then. In the meantime, I would advise creating a backup of the corrupt disk if possible, and trying out the free version of Disk Drill to see if it can at least discover your files by scanning the entire disk (which is what drat search will eventually be able to do).

[lsylx]

Thanks for helping. I’m now backing up my disk now and waiting for your software improvements.