It’s exactly six months since I last looked at the many problems plaguing Monterey’s Disk Utility. That was in macOS 12.0.1. Earlier this week, we updated to 12.4, which is getting close to the end of this cycle. This article considers where Disk Utility has got in those six months, and whether it’s less frustrating and more useful, less than a month before Apple announces macOS 13.

First Aid for backups

The most serious problem with Disk Utility remains its manifest inability to run First Aid on some volumes and containers, in particular Time Machine backup stores. This problem persists, although currently it now seems confined to APFS backup volumes.

In the past, a variety of errors have been blamed for this failure, but it has also been possible to work around it by manually ejecting the volume or container you want to check. macOS 12.4 now blocks all attempts to run First Aid on any volume or container on a disk containing an APFS backup volume, and the command tool fsck_apfs also refuses to oblige. Ironically, the only exceptions to this are HFS+ volumes, which can still be checked fully when on a disk containing an APFS backup volume.

Each time, the error message reports that the container holding the backup volume remains mounted, even though all volumes have been successfully unmounted, and Disk Utility also considers the container to be unmounted.

If you need to run First Aid on an APFS Time Machine backup disk, the only methods available are to use Disk Utility or apfs_fsck in Recovery Mode. This is a serious failure, particularly as the message given to users is to “back up the data on this volume”, which is wholly inappropriate for a backup volume, and gives the false impression that failure is imminent.

As I noted six months ago, these problems with unmounting containers and volumes for First Aid have persisted for over four years. Since that article, my suggested workaround of unmounting volumes manually and using fsck_apfs has ceased working, as that command now fails to open the volume, reporting that the operation is not permitted. Yet nowhere does Apple warn that First Aid on APFS backup volumes is only available in Recovery.

The good news is that such failures don’t seem to occur any more on external disks which don’t contain a Time Machine backup volume.

Container confusion

Less serious, but more confusing, is a sporadic bug which displays bizarre results after a disk has been erased, or partitioned into two or more containers.

This 2 TB external disk has just been successfully erased to provide a single APFS volume. Instead of showing a single container of 2 TB size, it shows two, with identical names and sizes, totalling 4 TB on the 2 TB disk.

This is also shown in the partition map. Previously, this bizarre behaviour occurred frequently, and it seems to have become less common in macOS 12.4. In recent days I’ve been doing a lot of erasing and partitioning, and guesstimate it now occurs about 10% of the time.

When using more complex partitioning schemes, the results can be even more puzzling. This 2 TB disk was successfully repartitioned into three containers, two of 100 GB and the third of 1.8 TB. At the end of that, Disk Utility insisted that there were three partitions of 100 GB and one of 1.8 TB, which makes a total of 2.1 TB. Note that the superfluous, greyed out volume is shown as an empty container.

In all cases, quitting Disk Utility and opening it again rectifies the problem, and brings the displayed structure and size of the disk back into kilter.

Summary of remaining bugs demonstrated

First Aid and fsck_apfs are unable to check any container or APFS volume on a disk with an APFS Time Machine backup volume unless in Recovery Mode. This is a serious bug, and the only workaround is to run the check in Recovery Mode.

Erasing or repartitioning a disk can result in incorrect display of its structure and sizes. This doesn’t occur consistently, but in about 10% of cases. The workaround is to quit Disk Utility and open it again, when the error should be corrected.