In this case, I’ll use disk7s2, which is the sort of volume name you’re looking for, or disk7 for a container.

In Disk Utility (or Terminal) obtain the device name of the APFS container or volume you want to check.

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.

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. 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. If you’re intending to check and repair the boot volume group (System and/or Data) then this is the preferred way. 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. Oddly, though, it doesn’t seem to affect HFS+ volumes. It can also happen every time with an APFS container. This may happen persistently when you try to check and repair an APFS volume. 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. That some day clearly hasn’t come in Monterey 12.0.1. 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.” In Catalina and Big Sur, the error reported was confusing, and the recommendation to “back up the data on this volume” inappropriate. 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.

I suspect that privacy isn’t sinister, merely allowing communication between the tool and app using XPC.īest 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. The y option simply agrees to make all the repairs suggested by the tool, but the x option is private. This article suggests ways around this, while we wait for Apple to fix this bug.įor 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. 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. One of its most persistent and pervasive problems has been complete failure because Disk Utility has been unable to unmount volumes or containers.

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.

Macbook pro disk utility error code 8