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:

1. In Disk Utility (or Terminal) obtain the device name of the APFS container or volume you want to check. In this case, I’ll use disk7s2, which is the sort of volume name you’re looking for, or disk7 for a container.
2. In Disk Utility (or Terminal) unmount the container or volume, by selecting it and clicking on the Unmount tool. When you’re checking a container, it’s best to unmount each of its volumes before unmounting the container itself.
3. Open Terminal and type the chosen command with the correct device name. Then enter your admin user’s password at the prompt.
4. Watch as the volume or container is checked.
5. Once that has completed, consider whether the container or volume needs any repair using fsck_apfs.
6. In Disk Utility (or Terminal) mount the container or volume again, by selecting it and clicking on the Mount tool.

The command to use depends on whether you just want to check the item, or repair it as well. For the former, use the -n option, and for the latter the -y option will perform all repairs automatically. I advise you to include all snapshots, which are important, but if you want to exclude them all, use the -S option.

If the volume is encrypted, you could keep it mounted and use the -l option to check the live file system, or you can use a command like
diskutil apfs unlockVolume /dev/disk7s2 -nomount
to unlock the volume without mounting it (thanks to kapitainsky for suggesting that).

For example, choose between the commands:

• sudo fsck_apfs -n /dev/disk7s2 just to check the volume disk7s2 but not repair it, and include snapshots.
• sudo fsck_apfs -y /dev/disk7s2 to check and repair all errors automatically, and include snapshots.
• sudo fsck_apfs -n -S /dev/disk7s2 to check but not repair, but excluding all snapshots.
• sudo fsck_apfs -n -S /dev/disk7 to check but not repair the container disk7, excluding all snapshots.

You can find details of all available options in man fsck_apfs.

Apple recommends that you first check and repair volumes within a container, then the container itself, and finally the disk (which you can do completely within Disk Utility). That is oddly the exact opposite order previously recommended by many, and duplicates checks on volumes which are normally repeated when you check their container.

The disk which I have such problems with is a little unusual in that it’s partitioned into two: a small HFS+ volume, and a much larger APFS container. The irony is that Disk Utility’s advice to back up the affect volume is being offered for my Time Machine backup, which is not only a backup volume itself, but can’t be backed up because its backup snapshots can’t be copied to another disk.

It will be so good when Apple finally sorts these problems we’ve suffered for the last four years.