1

I have run into trouble with APFS. I have an external hard drive (spinning plates) with two partitions. Some time ago one of these partitions stopped being mounted. Neither Disk Utility nor running fsck could repair it. Disk Utility in recovery mode could not repair it. The partition is not encrypted. All of this is happening on macOS 10.14.6.

I created an image from the entire external drive in hope that I would be able to access the data on the partition from there. This image, when mounted, correctly shows the uncorrupted partition, but the other partition is not mounted and greyed out in Disk Utility.

My investigation showed that the issue is the object map, which has come up a few times in my googling, but with no solutions.

sudo fsck_apfs -l -n -S /dev/disk4s3

** Checking the container superblock.
warning: checkpoint<->superblock disagree for xp 88
** Checking the EFI jumpstart record.
** Checking the space manager.
warning: spaceman chunk 916 free count 4294943744 > block count 32768
warning: spaceman main free count 351394375 does not match sum of free counts 351417927
** Checking the space manager free queue trees.
** Checking the object map.
** Checking volume.
** Checking the APFS volume superblock.
** The volume Extras was formatted by newfs_apfs (748.57.19) and last modified by apfs_kext (945.220.38).
** Checking the object map.
error: (oid 0x231dea) om: btn: invalid o_type (0x40000002)
   Object map is invalid.
** The volume /dev/disk4s3 could not be verified completely.

I believe the data on the drive is fine, but the few blocks of corrupted APFS make the whole drive unusable.

I know of boysoft data recovery software, but I am not interested in individual files or images etc. from this drive, I want the entire partition (I do wonder however, how is this software able to access files on unmountable drive). I know that had this been HFS system, DiskWarrior could probably rebuild the whole partition, but due to not-fully-documented nature of APFS (WTF Apple?), DiskWarrior people can't help...

I would like to know if there is any way of accessing the data on the unmountable APFS Volume? Or maybe fixing the object map so that the drive can be mounted and browsed?

Any tips would be greatly appreciated...

1

Welcome to Ask Different. Maybe you can mount the APFS volume by using the 3rd party app Mountain. Others have had good luck using this app. The app is not free but has a free trial. It's easy to download and give it a shot. I'm not associated in any way to Mountain. I'm just a happy user. The app requires macOS 10.8 or later.

|improve this answer|||||
  • Hi, thanks for the suggestion but this software is only a GUI add-on onto the system mount, so it doesn't make a difference... – yotiao Sep 22 '19 at 15:56
  • I realize that but for some reason, it has worked for me and others. – jmh Sep 22 '19 at 16:10
1

Hopefully, you still have the disk image to work with!

Whilst I cannot provide a complete solution immediately, I can at least provide some guidance. The output from fsck suggests that a node within the B-tree that represents the object map for your affected APFS volume is partially corrupted. Assuming that 0x40000002 in the line error: (oid 0x231dea) om: btn: invalid o_type (0x40000002) is the incorrect o_type value that appears in the affected block on disk, then this may be a relatively simple issue to fix; the value ought to be 0x40000003.* Of course, after fixing this, you may run into subsequent issues.

If 0x40000002 refers to the value that should appear on disk, then this means that the root node of your APFS volume's object map B-tree has become corrupted somehow, and further investigation is necessary.

I recently developed a toolset for inspecting such issues. If possible, compile apfs-inspect and share the output of apfs-inspect disk.img, where disk.img is the disk image you made of the APFS container partition. Please use a PasteBin link or similar, as the output will be very long. I'll then be more than happy to provide further guidance.


*The APFS spec published in February 2019 (PDF) explains that the o_type value of an APFS block represents the "storage type" and "object type" itself of the object that that block's data represents. The first 4 nibbles, i.e. 0x4000 are the storage type, and the last 4 nibbles, i.e. 0x0002, are the object type itself. Here, 0x4000 means that the object uses the "Physical" storage type, and 0x0002 means that the object is the root node of a B-tree; the value 0x0003 instead of 0x0002 means that the object is a non-root node of a B-tree.

|improve this answer|||||
  • I have the same problem with my drive. I was able to list files from the broken volume with ./apfs-list command, but how can I recover them? Can you help me mount this volume? – myexec Dec 29 '19 at 19:58
  • @myexec I should add a tool sometime soon that automates recovery of all recoverable files, but for now, see the discussion of apfs-recover here. Attempting to mount the APFS container natively will likely be problematic. Depending on the specific issue you have, you might also have some luck with apfs-fuse. – Jivan Pal Dec 29 '19 at 23:31
  • I run the apfs-inspect command and everything looks good to me. Can you take a look here please: pastebin.com/hCwmmer8 The problematic volume is the first named "Mileto - Data". I perform first aid on the container disk and I get this error: (oid 0x9a977) om: btn: found zeroed-out block. – myexec Dec 30 '19 at 22:41
  • @myexec So your situation is basically the same as mine was, which I detailed in the link in my previous comment (this link). Try out apfs-fuse and see what you can get a hold of. – Jivan Pal Dec 31 '19 at 18:20
  • 1
    Well I ended up using data recovery software. Although apfs-fuse was able to mount the volume and I recovered some files, was not stable and at some point was returning "disconnected transport protocol" error. A lot of files gave input output error and could not be recovered. – myexec Jan 2 at 20:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .