The internal SSD in an Apple silicon Mac normally contains at least a dozen volumes, carefully arranged into three partitions or containers. If you think that’s confusing, you’re not alone. This bug demonstrates how the Finder can’t cope either, and when it should be unmounting just one of those, it tries to get rid of the lot. This goes back to Ventura at least, and I suspect has been present since 2019, when Catalina brought this complex boot disk structure.

The reason that it’s seldom encountered is that it depends on adding another volume to those on the internal SSD. That has been unusual until recently, when it’s been shown to be a good way to store large files such as Virtual Machines without resulting in huge snapshots.

Trigger the bug

The key requirement to reproduce this bug is an extra APFS volume added to the internal SSD, as detailed here:

1. Open Disk Utility, and in the list of volumes on the left, select the Data volume in the internal SSD.
2. Click the + tool in the toolbar to add a new volume, and set its format to either APFS or APFS (Encrypted). Disk Utility should then add that new volume, and the Finder display it in the sidebar of its windows.
3. Control-click on that new volume’s name in the sidebar of a Finder window to open the contextual menu, and select the Eject command there.
4. As that volume is unmounted, you’ll be confronted with about six Force Eject dialogs, covering other hidden volumes in the internal SSD that you can’t eject.
5. Cancel each of those dialogs.

Repeat this using Unmount in Disk Utility and you shouldn’t see any such dialogs. I mentioned this bug in passing in that article nine months ago, and have reproduced it in all versions of macOS going back to Ventura, and strongly suspect the bug has been present since the boot disk was first divided into multiple volumes and containers, back in Catalina.

Boot disk structure

The diagram above shows the internal boot disk structure of an Apple silicon Mac running Sequoia; Tahoe appears identical. From the entries in the log and those dialogs, it appears that the Finder is attempting to unmount all other mounted volumes in all three containers, with the exception of the Data volume and the SSV. The Finder makes no attempt to unmount volumes that aren’t mounted during normal running, like the System and Recovery volumes.

Log

Once the eject action has been sent, a series of log entries records the start of the unmounting process for the new volume, here disk4s7:
00.953511 com.apple.AppKit Donating invocation type Mouse for menu item [TContextMenuItem: 0xc67b48cc0, action: cmdEject:, action image: eject]
00.972317 com.apple.Authorization Succeeded authorizing right 'system.volume.internal.unmount' by client '/System/Library/CoreServices/Finder.app' [594] for authorization created by '/System/Library/CoreServices/Finder.app' [594] (13,0) (engine 218)
00.974593 com.apple.DiskArbitration.diskarbitrationd Finder [594]:81831 queued solicitation, id = 0000000000000001:0000000000000001, kind = disk unmount, disk = /dev/disk4s7, options = 0x00000000.

That’s followed by a long sequence of callbacks to processes such as fseventsd to request approval of the unmounting. In other circumstances, such as when Disk Utility is trying to perform First Aid, one or more of those is likely to delay or block unmounting, as they’re still using the volume. Amusingly, the standard response from the Photos backend reads “Unmount of this disk is not interesting”, which is disarmingly honest.

Once all interested processes have approved the unmounting, APFS does its job:
01.034038 apfs_log_op_with_proc:3297: disk4s7 unmounting volume ExtraData1, requested by: diskarbitrationd (pid 352); parent: launchd (pid 1)
01.034051 apfs_vfsop_unmount:3239: disk4s7 waiting for purgatory cleaner to finish
01.039813 nx_volume_group_update:706: disk4s7 Volume ExtraData1 role 0x0 is not a System or Data volume
01.039920 apfs_vfsop_unmount:3583: disk4 nx_num_vols_mounted is 5
01.039924 apfs: total mem allocated: 262929315 (250 mb);
01.039925 apfs_vfsop_unmount:3596: all done. going home. (numMountedAPFSVolumes 9)
Note how APFS keeps a running total of mounted APFS volumes both within the main container (5 in disk4) and in total (9).

Having done the right thing, the Finder isn’t content and starts the same process on the container disk4, which fails. Next comes disk2s3, Hardware, which the kernel refuses on the basis of System Policy. This is repeated for disk2s2 xART, disk4s4 Update, disk4s2 Preboot, disk2s1 iSCPreboot, disk4s6 VM, and then cycles through the whole series a second time, as if the Finder won’t take no for an answer. On the second asking, a Force Eject dialog is created for each of them, as displayed to the user.

The same happens every time the additional volume is ejected using the Finder’s contextual menu.

Workarounds

As this extra volume is in the internal SSD, which can’t itself be ejected and removed, the simplest solution is not to unmount the volume, but to leave it mounted at all times. If that isn’t possible, for example with an encrypted volume containing sensitive data that should only be mounted for access, you can simply cancel all the dialogs, or unmount in Disk Utility instead of the Finder.

However, there’s a neater trick that’s almost as good as Apple fixing this bug: adding another APFS volume to the same container. As long as at least one of the additional volumes remains mounted, the Finder doesn’t suffer from premature ejection, and seems content to mount and unmount just the one volume. That suggests the Finder isn’t keeping an accurate tally on the number of volumes mounted in the internal SSD, and is forgetting about all those required by macOS.

Oddly, the Finder seems to do better with multiple volumes on external storage, where you’ll be invited to choose between unmounting the single volume, or the whole container. If Finder can get it right there, why not for the internal SSD?