APFS Recovery, Volume inaccessible, potential metadata/catalog corruption after crash

[Roberto Gandini]

Hi everyone,

I am seeking advice on a data recovery attempt for an APFS volume that became inaccessible after a system crash.

System Specs

• Hardware: MacBook Air 13 [2025 / Apple Silicon]

• OS: macOS [Tahoe]

• Current State: The specific APFS volume (Data) is not mounting or showing correct file system indices.

[System Specs]

The system crashed while saving a Word document. Since reboot, the file system index appears lost.

[Actions Taken]

• Performed R-Studio and Disk Drill scans.
• Result: The software identifies many files as "raw/extra", but the original file system metadata/Catalog B-TREE structure Is not reconstructed.
• The partition is visible via 'diskutil list' as follows:

The output the diskutil is: APFS Volume Data (disk3s5)


[Question]
Is there a known method to force a rebuild of the APFS catalog B-tree or restore the file system indices for a volume in this state? Or, given the current metadata corruption, is raw carving the only viable path forward?

Any technical guidance or recommended workflow is a
ppreciated. Thanks in advance.

 

[eldho]

Have you tried using the disk utility app (in the utilities folder)? I am not sure if that is possible if it is not mounted though.

 

[kitKAC]

Have you tried using the disk utility app (in the utilities folder)? I am not sure if that is possible if it is not mounted though.

Seeing as all user data is stored on the Data volume, if the machine is logged in, then Data is mounted. The OP's post doesn't make much sense to me.

 

[mfram]

OP: Are you trying to run First Aid (in the Disk Utility) on the Data volume of a running system? Or did you reboot into Recovery mode and are trying to fix the Data volume while in Recovery mode?

You can't run First Aid on the Data volume of a running system because the filesystem is mounted. We need more details on the steps you are taking.

 

[Sciuriware]

Have you tried using the disk utility app (in the utilities folder)? I am not sure if that is possible if it is not mounted though.

Disk utility repairs a disk when it is UNMOUNTED, it even tries to umount it first.
Disk utility can repair a running system, it just freezes the OS.
But, it can refuse to repair when the administration is badly damaged.
Then you got to contact a repair centre or buy a new disk.
Success!
;JOOP!

 

[benholt]

Before you commit to raw carving, two things worth trying. First, if the parent container still mounts, run `diskutil apfs listSnapshots /dev/disk3s5` from Terminal — any pre-crash snapshot can be mounted read-only via `mount_apfs -s <name> /dev/disk3s5 /Volumes/recover` without touching the live volume, and you'd be surprised how often a Time Machine local snapshot exists on a Data volume even when nobody explicitly enabled it. Second, from Recovery Terminal (or single-user), try `sudo fsck_apfs -y -x /dev/rdisk3s5` — note the 'r' for the raw device node. First Aid wraps fsck but doesn't expose the -x aggressive-check flag. There's no catalog-rebuild operation on APFS the way there was on HFS+, so if fsck bails on the B-tree, carving really is the path. In my experience DMDE tends to outperform R-Studio and Disk Drill on APFS catalog damage specifically because it understands the object map — worth a shot before you commit tens of hours to carving output.

 

[bzgnyc2]

Hi everyone,

I am seeking advice on a data recovery attempt for an APFS volume that became inaccessible after a system crash.

System Specs

• Hardware: MacBook Air 13 [2025 / Apple Silicon]

• OS: macOS [Tahoe]

• Current State: The specific APFS volume (Data) is not mounting or showing correct file system indices.

[System Specs]

The system crashed while saving a Word document. Since reboot, the file system index appears lost.

[Actions Taken]

• Performed R-Studio and Disk Drill scans.
• Result: The software identifies many files as "raw/extra", but the original file system metadata/Catalog B-TREE structure Is not reconstructed.
• The partition is visible via 'diskutil list' as follows:

The output the diskutil is: APFS Volume Data (disk3s5)


[Question]
Is there a known method to force a rebuild of the APFS catalog B-tree or restore the file system indices for a volume in this state? Or, given the current metadata corruption, is raw carving the only viable path forward?

Any technical guidance or recommended workflow is a
ppreciated. Thanks in advance.

Is this the internal drive or an external drive or are you using an external drive to boot?

Also if you are going to post the output of commands, best to include all the output with minimal editing (ideally just what's necessary for security/confidentiality/privacy/etc).

Can you post the output of Apple's First Aid (or fsck_apfs if you are running things from Terminal)?

 

[Fishrrman]

OP wrote:
"The system crashed while saving a Word document."

Hmmmm
I can see where MS Word itself might crash, but the entire computer (OS)?
Is not the OS itself "protected against" such catastrophic crashes?

Does the Mac boot now?
Do you have any kind of backup?

Could you possibly:
1. boot to recovery
2. install a new copy of the OS onto an EXTERNAL SSD.
3. boot from that SSD and then "get into" the user container/partition on the interal drive?