Why you shouldn’t delete one of a Volume Group in macOS 11 or later

Just as some people climb mountains “because they’re there”, others do things to macOS because they’re possible. Ever since Catalina divided the startup volume into two in a special Volume Group, we’ve been using Disk Utility and its command line equivalent diskutil to delete one of those two grouped volumes but not the other. This article explains why that isn’t wise in Big Sur or Monterey.

To know what to expect when you delete one volume in a Volume Group we need to understand what makes that group.

Each of the two volumes within a Volume Group is designated as being a group member with its specific role and UUID. They’re also glued together by the firmlinks which make the two volumes work with one another. Not only that, but macOS has many essential files which are stored not on the System volume, but on the Data volume instead, where they can be written to. These most notably include Safari and several of the writable hidden top-level directories. Those are firmlinked into place and the whole Data volume mounted inside the System volume.

Deleting either of the two volumes alone thus breaks all those firmlinks. In Big Sur and later the mounted system is a snapshot whose contents can’t be modified to remake broken firmlinks. The only way to remake firmlinks would be to create a complete replacement sealed snapshot – something that only a macOS installer can do when performing an installation of macOS.

In deleting just one of a Volume Group, you therefore leave the remaining volume of the group with its firmlinks dangling to nowhere, with a missing mountpoint, and an orphaned UUID for a volume which no longer exists. On M1 Macs in particular, it also creates havoc with ownership which you could really do without.

Why delete the System volume alone?


In every case, deleting the System volume alone serves no purpose: instead, install the new version of macOS in its place. If you want a truly clean install or reinstall, you need to delete the Data volume too, so you should choose to delete the whole Volume Group. If you simply want to reinstall the system, then it’s just as good to do that without deleting either volume.

If you want to preserve the contents of an existing Data volume as an ungrouped volume, you’re better off making a copy of that Data volume using Carbon Copy Cloner or SuperDuper!, which then doesn’t have any firmlinks at all, and can be used as a source for migration into a new Volume Group created by the macOS installer.

Why delete the Data volume alone?


The only reason that you might want to be rid of the Data volume would be to perform a clean install of the system, so your Mac starts off with a fresh Data volume. In that case, you should delete the Volume Group rather than just the Data volume.

If you want to migrate the contents of a copy of an existing Data volume, the best approach is to install macOS and use your copy as the source for migration.

Why do Disk Utility and diskutil offer to delete grouped volumes singly?

That’s a very good question, and the best answer is because it’s possible. Future versions of Disk Utility may not be as generous, and require you to delete Volume Groups instead of just one of the group.

The fundamental problem is there’s no tool or utility to unmake firmlinks, and even if there were, those which are frozen into the snapshot which Big Sur and later boot from couldn’t be changed. This is very different from the situation in Catalina, where the System volume isn’t a snapshot but a read-only volume, whose firmlinks could perhaps be changed once the System volume was made writable.

In Catalina, there was perhaps a case for enhancing a tool like diskutil so that it could be used to create and maintain firmlinks, if that were possible in APFS. In Big Sur and later, because one end of the firmlink is always locked into a snapshot, they can only ever be created or maintained during macOS installation, before the sealed snapshot is created, and not something the user could ever become involved with. The upside of this is that nothing malicious or badly broken can change firmlinks either, ensuring that you can put absolute trust in their integrity.