Checking and repairing disks is one of the more important tasks performed by Disk Utility, but ever since the introduction of APFS, it has been more fraught than it should have been. One of its most persistent and pervasive problems has been complete failure because Disk Utility has been unable to unmount volumes or containers. To my shock, in Monterey 12.0.1 this problem appears worse than ever, and I now have one disk which Disk Utility is completely unable to check or repair. This article suggests ways around this, while we wait for Apple to fix this bug.
For much of this period, the First Aid tool in Disk Utility has relied on the command tool fsck_apfs to do the work, calling it using two options, y and x . The y option simply agrees to make all the repairs suggested by the tool, but the x option is private. I suspect that privacy isn’t sinister, merely allowing communication between the tool and app using XPC.
Best practice for performing disk checks and repairs like this isn’t with a live file system, and those options won’t work when the item being checked is still mounted. So to prepare for the call to fsck_apfs , Disk Utility has to unmount the volume or container, and that’s the step which appears to go awry.
In Catalina and Big Sur, the error reported was confusing, and the recommendation to “back up the data on this volume” inappropriate. It would have been far better if Disk Utility had told us honestly that “this is a known bug, and some day we might get round to fixing it.”
That some day clearly hasn’t come in Monterey 12.0.1. When I was researching yesterday’s article about how to check Time Machine backup volumes, it hit me again and again, so I went back and had a closer look at what now goes wrong, and what to do about it.
This may happen persistently when you try to check and repair an APFS volume.
It can also happen every time with an APFS container.
Oddly, though, it doesn’t seem to affect HFS+ volumes.
One way around this is to cave in, start up in Recovery, and use Disk Utility there, where there’s no excuse for problems unmounting anything. If you’re intending to check and repair the boot volume group (System and/or Data) then this is the preferred way. macOS does now provide a good means of ‘freezing’ file system access if you do try that when running in normal user mode, but Recovery is always better.
The best news of all is that you can still use the command tool fsck_apfs directly, and work around this bug in Disk Utility. The bizarre twist is that you can use Disk Utility’s Unmount tool to unmount volumes and containers which the app itself appears unable to unmount successfully. Here’s a summary of the process:
... continue reading