Until Apple introduced APFS, the normal structure of our Mac’s disks and volumes was relatively simple. What we saw in the Finder and in Disk Utility was reasonably close to what we needed to use, and wasn’t too far from what you’d find using the diskutil command in Terminal.

Then came High Sierra and Mojave with APFS, which complicated that with features like containers, and the simple illusion offered in the Finder didn’t bear much resemblance to what Disk Utility shows, and is further removed from Terminal’s shell. Now with Catalina and its strange paired System and Data volumes, it just seems a bewildering mess. This article aims to unravel that so that you can better understand the Finder, Disk Utility, and the command line across each recent version of macOS.

There are three different ways of looking at the disks and volumes on your Mac, which don’t always precisely match:

• The Finder shows you a simplified view which you need for everyday handling of documents, apps, etc. You can always make it a bit more literal by pressing Command-Shift-. (period or full stop) to show hidden items, but that is at best a temporary measure, and still doesn’t reveal full detail.
• Disk Utility shows what you need to use when creating and working with storage volumes on different disks. It doesn’t give full details, or even show all available volumes, though.
• The diskutil command in Terminal gives you a wealth of detail, which you seldom need in day-to-day work, intended for when you need to refer to volumes using their Unix names, such as disk3s2. There are two invaluable commands which reveal disk and volume structures in their full detail: the older diskutil list, and a new supplementary diskutil apfs list which concerns itself with APFS volumes.

High Sierra and Mojave

Disks, internal or external, commonly come in two forms: those using the old HFS+ (Mac Extended) file system, which are still required for local Time Machine backups, and those using the new APFS. Each disk contains a hidden EFI partition, together with HFS+ volumes and APFS containers as created. Here’s one important difference between HFS+ and APFS: APFS doesn’t put its volumes at the top level within the storage structure, but inside a container. This is because containers behave like HFS+ volumes, with fixed size and unable to share free disk space. However, APFS volumes within the same container grow and shrink in size as they need, as they all share space within that container.

A simple external disk used for storage and in APFS format therefore has one APFS container, within which there is a single APFS volume. This is shown in the second example, disk2, in the diagram above, and disk4 is its equivalent in HFS+.

Bootable APFS disks, as shown in disk0 at the top, have the same top level structure, but within their APFS container are four volumes, of which we’re normally only shown disk1s1, commonly named Macintosh HD. The other three volumes – one containing code to be loaded early when starting up, another storing ‘virtual memory’ working files, and the Recovery volume – are either unmounted during normal running or hidden. Of all the volumes and containers, the Finder normally only shows those coloured blue, even when you reveal hidden items.

Disk Utility goes a little bit further, but still only lists the visible volumes at the left. Select a bootable container, though, and it reveals the VM volume, and the fact that two volumes aren’t mounted. Its total volume count for that container is 4.

Unix names for those volumes are a bit more complicated, as the APFS container is considered to be a ‘synthetic’ disk, so is labelled disk1, and the four volumes within that then become disk1s1 to disk1s4. This is quite different from HFS+, where the volume isn’t within a container, making the first HFS+ volume on disk4 the much simpler disk4s2, as disk4s1 is the EFI partition.

Catalina

The change made to this structure in Catalina might appear simple: in a bootable APFS container, there is a fifth volume. However, to preserve the illusion of simplicity in the Finder, and to link the new System and Data volumes together, requires more smoke and mirrors, making the structures quite different.

Viewed in the Finder, with hidden items revealed, there now appear to be two volumes both named Macintosh HD. The top-level volume contains essentially the same folders as you’ll find on an older single-volume layout, but drill down through the System folder to Volumes, and you’ll find another Macintosh HD which has a different set of folders. In fact, the top-level Macintosh HD is the new read-only System volume, and the lower-level one is what you otherwise see as Macintosh HD - Data, where all your writable files and folders are kept. Instead of macOS mounting that Data volume in the normal Volumes folder (as it would have in Mojave), it’s actually mounted in /System/Volumes instead.

The big difference in the actual volume layout is that disk1s1 and disk1s2 form a Volume Group, within the bootable container disk1 on your boot disk disk0. Otherwise the layout is the same, and this only applies to bootable APFS containers, not to non-bootable APFS containers on regular storage.

For consistency, Disk Utility shows both the System and Data volumes within the bootable container, but being read-only and protected by SIP, you’re really not going to do much with Macintosh HD here. The contents of the container are listed in full, with the two volumes forming its Volume Group, VM, and the two unmounted as before.

What this currently lacks is clear indication that Macintosh HD and Macintosh HD - Data form a Volume Group. Select either of them and they’re given custom icons to show their respective role, but there’s nothing to warn you that they work as a pair, are mounted together, and have firmlinks between them. Maybe those will come in a future version of Disk Utility.

Terminal’s old command diskutil list provides basic information about the volumes as you’d expect. It’s the new diskutil apfs list which reveals their true nature. disk1s1 has the System role, and is mounted at the root /, wherease disk1s2 has the Data role, and is mounted as /System/Volumes/Data. It’s in Terminal that paths become more complicated too, thanks to the firmlinks which ensure as much consistency as possible with previous disk directory trees. If you want to see these in detail, this article includes full roadmaps to the new trees.

One final note about Unix volume naming: these aren’t fixed. The names I have given above are those you should expect to see in macOS when volumes haven’t been deleted or recreated. If in the process of performing a clean re-install you delete the Data volume, then you should expect the different volumes within that container to end up with different Unix names from those shown. This shouldn’t make any difference, unless you or a script expects to find the Data volume at disk1s2. And that would be extremely bad practice.