Have you ever wondered whether someone else has changed your Mac’s storage? Or which version of macOS formatted each of its volumes? As all good forensic investigators know, APFS keeps detailed records of the formatting and modification of each volume. This article explains how you can read and interpret them. As in the tale of Goldilocks and the Three Bears, you may be able to tell who has been eating your APFS porridge.

Information available

Each APFS volume stores details of its history in the volume superblock apfs_superblock_t. Those include information on how that volume was created in apfs_formatted_by, and up to the last 8 times the volume has been modified, in apfs_modified_by.

Although you’ll need a forensic disk analysis tool to get full details, some of that data is easy to access. Select a volume in the Finder, and Get Info will give a time and date that volume was last formatted.

Run First Aid in Disk Utility on that volume’s container, and there’s even more information given about each volume within the container, including those you can’t see. If you’d rather not run a full check and repair, then you should see the same information in Terminal by using
diskutil verifyVolume disk10
where disk10 is the device name for the container. If you prefer you can use fsck_apfs directly, but verifyVolume should use that command’s options most efficiently.

One lingering problem you may encounter in Disk Utility is that it still fails frequently because it can’t unmount volumes for checking. If you encounter that error when trying to run First Aid on a container, try manually unmounting each volume within that container. If all else fails, diskutil verifyVolume appears to be better at handling the problem.

Workthrough

As shown above, when run on one of my external SSDs, information about two APFS volumes was returned, itself something of a surprise. The volume I expected gave
The volume ThunderBay3 was formatted by diskmanagementd (1412.81.1) and last modified by apfs_kext (2313.1.2).
and the surprise, which isn’t mounted, thus effectively hidden, gave
The volume Update was formatted by com.apple.Mobile (1677.50.1) and last modified by apfs_kext (1677.141.2).
The Finder’s Get Info dialog for ThunderBay3 gave a volume creation date of 11 February 2020, and last modification of 20 December 2020.

Taking the visible volume ThunderBay3 first, APFS says that it was formatted by its own formatting tool, diskmanagementd, in APFS version 1412.81.1, which came in macOS 10.15 Catalina (see the Appendix below). A look through details of versions released pins that down to 10.15.3, released on 28 January 2020, which tallies with the creation date from the Finder. Its last modification was performed by a general APFS function, in APFS version 2313.1.2, which is that current for macOS 15.0 and 15.0.1.

The hidden Update volume has had quite a different history, as it was created in APFS version 1677.50.1 in Big Sur, to be more precise in macOS 11.0.1 released on 12 November 2021. That wasn’t a conventional volume creation either, and was performed by com.apple.Mobile, part of the Big Sur installer. It was last modified using APFS version 1677.141.2, which came in macOS 11.6 on 13 September 2021. Since then it appears to have been left unmounted and unused.

The history of that container therefore reads:

• ThunderBay3 created by the user on 11 February 2020 in macOS 10.15.3
• Update created by a macOS installer after 12 November 2021 in macOS 11.0.1
• Update last mounted after 13 September 2021 in macOS 11.6
• ThunderBay3 currently in use.

Conclusions

The hidden Update volume contains a restore log apparently left behind after the 11.5.2 update, together with some empty folders. These demonstrate that it was a temporary volume created by Big Sur’s new macOS installer, but never cleaned up afterwards, and left abandoned for the last three years. As Big Sur was the first version of macOS to use Apple’s new installer that created a Signed System Volume, this is likely to be present on other external disks that were mounted when any version of Big Sur was installed. Although it takes little space, it’s a surprising omission that no subsequent installer has seen fit to clean this up by deleting the volume.

Otherwise, information about the visible and mounted volume appears consistent, and confirms what I recall of its history. No one has been eating this bear’s APFS porridge.

Appendix: APFS and macOS version details

APFS major version numbers change with major version of macOS:

• APFS version 0.3 or 249.x.x in macOS 10.12
• 748.x.x in 10.13
• 945.x.x in 10.14
• 1412.x.x in 10.15
• 1677.x.x in macOS 11
• 1933.x.x in 12.0-12.2.1
• 1934.x.x 12.3 and later
• 2142.x.x in 13
• 2235.x.x in 14.0-14.3.1
• 2236.x.x in 14.4 and later
• 2313.x.x in 15.

Minor version numbers increment according to the minor version of macOS, and patch numbers wander without pattern. Those can be checked by looking at the changes given for each macOS update listed on this page.