Disk Utility error "Couldn't mount disk (-69842)".

Morning (in Brazil) news: I am beyond pleased and proud to tell you all that the issue has finally been solved!

After our last round of replies, I decided to do a deep dive into all I could find about APFS, the reasons behind this stubborn error message and the most likely solutions. I will summarize what I found out and what was the definitive solution that freed me and my MacBook from the chains of that annoying error.

Previously on this thread: Apple Diagnostics shows no HW error, Disk Utility showed error code -69874 until I formatted the partition in standalone (aka recovery) mode. It then became error code -69842 which seemed easier to fix (could not unmount disk) but proved to be as tough as the first one.

It took me about a week to find the time and online resources to gather a whole bunch of information (it is summarized in a pdf document that I am not sure I can upload here). I learned that Disk Utility is a great tool but is somewhat limited and that Terminal commands are way more powerful (insidious, one might say) than what you can do in Disk Utility.

First thing I did was to prove my theory that there's a partition map that resists formatting, it is simply updated and not wiped/recreated when one just erases a disk with no other changes. So I went into recovery mode, booting from the external HDD and decided to shrink the only partition and force the creation of a second, smaller one that could allow me to delete the offending, original partition.

Unfortunately, that did not solve the problem as I still could not delete the original partition by clicking the "-" (minus) sign in Disk Utility.

I went back to my notes and started Terminal; it was time to either eliminate the error or die trying. Even if it meant actually wiping everything. Of course, at this moment, I had to have (and had) faith in my 3 (up one from last time) external backups.

In Terminal, I did:

diskutil list

diskutil eraseDisk APFS "Macintosh HD" /dev/disk0

diskutil apfs deleteContainer diskXsY

And the message (-69842) was still there! Stubborn little devil, isn't it?

The next option was what I had been looking for all along:

gpt destroy /dev/disk0

diskutil eraseDisk APFS "Macintosh HD" /dev/disk0

The result was more than satisfying!

However, I didn't want to stop there and went on to the next step: ERASE MAC. Side note: this would have done the same thing the previous commands did plus a lot of extra wiping.

From the menu: Recovery Assistant → Erase Mac

It took sometime as it went online to, I guess, download MacOS Sequoia. Finished without issue and rebooted into the Transfer Data sequence.

Took much less time than his time (about 3 hours) and loaded everything back.

The only visible consequence is that the message has disappeared which makes me believe that, at least for now, the error is gone and there's no indication I was at risk of losing everything. Final diagnose: APFS corruption either in Object Map or fsroot (the B-Tree from where all the structures/branches stem).

Thank you very much for all the help you provided and I do hope this thread will someday help somebody else.

-Fernando

Morning (in Brazil) news: I am beyond pleased and proud to tell you all that the issue has finally been solved!

After our last round of replies, I decided to do a deep dive into all I could find about APFS, the reasons behind this stubborn error message and the most likely solutions. I will summarize what I found out and what was the definitive solution that freed me and my MacBook from the chains of that annoying error.

Previously on this thread: Apple Diagnostics shows no HW error, Disk Utility showed error code -69874 until I formatted the partition in standalone (aka recovery) mode. It then became error code -69842 which seemed easier to fix (could not unmount disk) but proved to be as tough as the first one.

It took me about a week to find the time and online resources to gather a whole bunch of information (it is summarized in a pdf document that I am not sure I can upload here). I learned that Disk Utility is a great tool but is somewhat limited and that Terminal commands are way more powerful (insidious, one might say) than what you can do in Disk Utility.

First thing I did was to prove my theory that there's a partition map that resists formatting, it is simply updated and not wiped/recreated when one just erases a disk with no other changes. So I went into recovery mode, booting from the external HDD and decided to shrink the only partition and force the creation of a second, smaller one that could allow me to delete the offending, original partition.

Unfortunately, that did not solve the problem as I still could not delete the original partition by clicking the "-" (minus) sign in Disk Utility.

I went back to my notes and started Terminal; it was time to either eliminate the error or die trying. Even if it meant actually wiping everything. Of course, at this moment, I had to have (and had) faith in my 3 (up one from last time) external backups.

In Terminal, I did:

diskutil list

diskutil eraseDisk APFS "Macintosh HD" /dev/disk0

diskutil apfs deleteContainer diskXsY

And the message (-69842) was still there! Stubborn little devil, isn't it?

The next step was what I had been looking for all along:

gpt destroy /dev/disk0

diskutil eraseDisk APFS "Macintosh HD" /dev/disk0

The result was more than satisfying!

However, I didn't want to stop there and went on to the next step: ERASE MAC. Side note: this would have done the same thing the previous commands did plus a lot of extra wiping.

From the menu: Recovery Assistant → Erase Mac

It took sometime as it went online to, I guess, download MacOS Sequoia. Finished without issue and rebooted into the Transfer Data sequence.

Took much less time than his time (about 3 hours) and loaded everything back.

The only visible consequence is that the message has disappeared which makes me believe that, at least for now, the error is gone and there's no indication I was at risk of losing everything. Final diagnose: APFS corruption either in Object Map or fsroot (the B-Tree from where all the structures/branches stem).

Thank you very much for all the help you provided and I do hope this thread will someday help somebody else.

-Fernando

Well, for what it's worth I have now performed an attempt at that theory - no success yet. I'll stand down for now while I consider if it's time I purchased my next MacBook Pro - which will be an M4 Pro (not Max, for budget reasons). When I was in the middle of that action, one issue came back to my mind: the sequence in which First Aid should be executed when examing a disk. I then asked ChatGPT and, you guessed it, James Brickley was correct: scan from the inside out. Here's the reasoning:

When using First Aid in Disk Utility on macOS Sequoia to check an external USB HDD that contains a partition, a container, and one volume, the correct order to run First Aid is:

1. Volume
2. Container (APFS Container)
3. Partition (Physical Disk)

✅ Why this order (from innermost to outermost)?

• The Volume is the logical layer where your files and folders live (what you see in Finder). Issues at the volume level are often self-contained and can be fixed without affecting deeper structures.
• The APFS Container manages one or more volumes and handles the dynamic allocation of free space between them. If there’s corruption here, it can affect all volumes inside the container.
• The Partition (Physical Disk) represents the lowest level—the physical layout and partition map on the drive. Problems here are more severe but also depend on the integrity of the container and volume structures.

If you start First Aid at the physical disk level without first checking the container and volume, the process can sometimes fail or be ineffective because it skips necessary checks in the layers above.

🔧 Quick Summary:

Always run First Aid in this order:

1️⃣ Volume

2️⃣ Container

3️⃣ Physical Disk

This approach fixes issues from the simplest to the most fundamental, ensuring that lower-level checks don’t miss problems at higher levels.

Hope this helps!

-Fernando

Sunday News (UPDATE)

Shut down the Mac early today, powered it back up and ran the networked Apple Diagnostics. No issues, at least no hardware issues. Same as Drive DX reported: nothing wrong.

Upon reboot, Command+R, Recovery Mode and ran Disk Utility in standalone mode. Same error, which now I definitely blame software for. Somehow,MacOS got confused. At least I don't have to turn the Mac in for repair (out of warranty).

Next (and final) step, to be scheduled: boot from my external HDD and attempt a Disk Utility run to fix the Macintosh HD drive File Access Tables (yes, I know, MacOS uses a different name but that's what it is) from "outside". If it doesn't work, brace for impact, backup two or three times and format the SSD.

Thanks for your responses!

-Fernando

James and all, here's the latest and surprising update! So, I took all my precautions (such as 3 backups to 3 different external HDDs) and proceeded to boot from the external SSD which was uneventful. With my heart pounding, I clicked on Disk Utility (standalone aka recovery mode) and (a) erased all volumes (b) erased container and (c) repartitioned Macintosh HD by changing it to MacOS Extended then back to APFS and clicking "Partition"). At this point, no more data was present on the disk and I then entered Disk Utility again and ran First Aid on the EMPTY partition. Surprise! THE SAME ERROR WAS STILL THERE! See attached screenshots, in sequence: deleted everything, the error message, re-reformatted, entered transfer mode and... first attempt FAILED after 5 hours; repeated the process, re-enterer transfer mode with backup #2 and... second attempt FAILED after 2 hours. Clearly these problems were on the external disks. That's when any atheist starts praying and so did I. Repeated the process, entered transfer mode with backup #3 and it finally completed. After letting the system stabilize for about an hour I rebooted into recovery mode and ran Disk Utility on more time. Sure enough, First Aid on Partition still shows the same error. Since I'd have to reboot anyway, I shut the MBP down and entered Diagnostics. After several minutes, message was ADP000. Passed with flying colors. SO: it's not hardware, MacOS Sequoia can't figure out what is nor fix it.

Please, any other ideas? Just as a bonus: replacing the logic board and the touch id interface will cost about $2500 (yes, you read it right) in Brazil due to (our) import taxes. And this MBP should become "vintage" next year, which is to say should anoher issue pop up, no guarantee that sare parts will be available.

A new, equivalent MBP (M4) costs around (take a deep breath) $10000.

I have been using the system for the last couple of days without issues though.

Thanks for keeping up!

-Fernando

[Edited by Moderator]