When you format a disk and install Big Sur on it, making it a startup or boot volume, it has a standard structure, something that has changed greatly over the last few years. This article summarises all you need to know about the layout of APFS boot disks and volumes in Big Sur, whether running on an Intel or Apple Silicon Mac. Detailed information for Catalina and earlier is here.
Disk layout
Big Sur goes further than Catalina in that its System volume is now the mounted snapshot of a sealed volume known as the Sealed System Volume (SSV). Its boot container thus consists of:
- the SSV, a mounted snapshot of the unmounted read-only System volume named Macintosh HD, which forms the root of the boot file system. The snapshot is named com.apple.os-update- followed by its UUID, and the volume (hence its snapshot) is typically about 15 GB in size;
- the writable Data volume, by default on the internal disk named Macintosh HD – Data, which is normally hidden from view at /System/Volumes and accessed via firmlinks. On Intel Macs, this is given its full name, but on M1s it’s named simply Data;
- Preboot, a small volume of around 350 MB;
- Recovery, the Recovery Volume, of around 600-950 MB;
- VM, containing virtual memory caches, which is upwards of 20 KB depending on use.
Note that, at least in macOS 11.1, the seal on the unmounted read-only System volume is normally broken, but it’s the snapshot which is the important one: that should be sealed, unless you have broken its seal intentionally.
Internal disks of M1 Macs are unusual in that they don’t contain a top-level EFI partition. Instead, they have two additional partitions, named Apple_APFS_ISC and Apple_APFS_Recovery, of about 520 MB and 5 GB size respectively. Neither of those is present on external bootable disks for the M1, where the traditional EFI partition is present instead.
The contents of those two new partitions are also mounted alongside the Data and other standard volumes in /System/Volumes. Those include:
- BaseSystem, an empty folder
- FieldService, an empty folder
- FieldServiceDiagnostic, an empty folder
- FieldServiceRepair, an empty folder
- Hardware, shown as a volume or folder, containing files and folders
- iSCPreboot, shown as a volume or folder, containing files and folders
- Recovery, shown as a folder not a volume
- Update, shown as a volume, containing files and folders
- xART or xarts, shown as a volume or folder, which may contain files and folders or appear empty.
Of course the user isn’t supposed to use any of those system-level folders and volumes, and Apple may in a future update hide them away.
A fuller history of boot disk structure is here, and a current account of the containers and volumes for M1 models is in this more detailed article.
Non-boot Volume Groups
If you have a disk containing a non-boot Volume Group, such as a bootable external disk, that has separate entries for its System and Data volumes. Using [System] to represent the name of the System volume (commonly Macintosh HD), and [Data] the name of the Data volume (Macintosh HD – Data), you should see
- /Volumes/[System] for the boot Volume Group, integrated by its firmlinks
- /Volumes/[System] for the non-boot System volume
- /Volumes/[Data] for the non-boot Data volume.
Catalina behaves the same, unless the non-boot Volume Group has Big Sur installed, in which case it can’t mount that System volume properly.
When browsing 10.15 and 11 Volume Groups from Big Sur, or 10.15 from Catalina, there’s one discrepancy in paths which alters depending on whether that Volume Group is that used for the current boot, or is non-boot. On a boot Volume Group, the Finder path [System] > System > Volumes > [System] is the current Data volume, equivalent to Terminal’s /System/Volumes/Data. However, trying to follow a similar path on a non-boot Volume Group causes a problem: [System] > System > Volumes > Data is an empty folder, and Terminal gives the equivalent path as /Volumes/[System]/System/Volumes/Data.
Folder layout
Big Sur (and Catalina before it) divides the major folders between its System and Data volumes. The System volume forms the root /, from which there are multiple firmlinks which join the two volumes into what appears to be a single volume both in the Finder and Terminal. A simplified integrated view of the resulting boot Volume Group is shown below.
and in this PDF for you to tear out and keep: BigSurIntSimple
In that diagram, folders which are on the SSV are shown in blue, and those on the Data volume in yellow. Those in red are firmlinked from the System volume to that folder on the Data volume. This creates the illusion of a single, integrated volume which is actually composed of the two melded together.
There are several important folders which merit special consideration.
The top-level Applications folder is actually a firmlink to user apps on the Data volume. The Finder melds that with read-only apps installed in macOS at /System/Applications, making bundled and user apps appear to be in a single folder, which they actually aren’t. Try to trash one of the bundled apps like Calculator, or inspect its real path in the Get Info dialog, and that will be apparent.
Mutable system files can’t be installed on the SSV, so are normally firmlinked to folders on the Data volume. Among the most important of these are the several folders in /private, and /usr/local in which you can install your own command tools and the like.
The Data volume itself is accessible through its mountpoint at /System/Volumes/Data, and contains the contents of the top-level Users folder, with Home folders and more.
The only significant changes in Big Sur’s SSV from Catalina’s System volume is the absence of .fseventsd and .DS_Store. On the Data volume, at least on M1 models, the PrelinkedKernels folder in /Library/Apple/System/Library is no longer present, although it may remain on Intel Macs. Also missing from that folder are the FeatureFlags and Frameworks folders previously used by Safari.
Firmlinks
Firmlinks are similar in some respects to traditional symbolic links, but are only made between folders, work in both directions, and with a little added magic effectively merge the contents of two linked folders. For example, the /Users directory on the SSV contains some directories in /Shared. As /Users is a firmlink, the directories there are merged with those in the /Users/Shared directory on the writable (Data) volume. Further details about volume groups and the file system magic in Catalina is in this Carbon Copy Cloner KB article.
The current list of system firmlinks taken from /usr/share/firmlinks is:
/Applications <-> Applications
/Library <-> Library
/System/Library/Caches <-> System/Library/Caches
/System/Library/Assets <-> System/Library/Assets
/System/Library/PreinstalledAssets <-> System/Library/PreinstalledAssets
/System/Library/AssetsV2 <-> System/Library/AssetsV2
/System/Library/PreinstalledAssetsV2 <-> System/Library/PreinstalledAssetsV2
/System/Library/CoreServices/CoreTypes.bundle/Contents/Library <-> System/Library/CoreServices/CoreTypes.bundle/Contents/Library
/System/Library/Speech <-> System/Library/Speech
/Users <-> Users
/Volumes <-> Volumes
/cores <-> cores
/opt <-> opt
/private <-> private
/usr/local <-> usr/local
/usr/libexec/cups <-> usr/libexec/cups
/usr/share/snmp <-> usr/share/snmp
/AppleInternal <-> AppleInternal (on Apple engineering systems only)
in each case shown as the system volume path and the Data volume path which are firmlinked. These haven’t changed since Catalina.
You can also create your own synthetic firmlinks, which appear at root volume level and link to folders or symbolic links on the Data volume. These are stored in an /etc/synthetic.conf file, which is documented in man synthetic.conf. Rich Trouton has published an excellent tutorial on how to do this. Users who previously had their own custom folders at the root level of the boot volume can use this to create the same effect in Catalina and Big Sur.
Paths
The standard system firmlinks mean that, for most users and most purposes, you shouldn’t have to look anywhere different, or change the paths you use in Terminal. However, if you access anything for which there isn’t a convenient firmlink, you may find that its effective path has now changed – hence these new roadmaps, to help you see where things can now be found.
In Terminal, when you want to run a command tool which you installed in the /usr/local/bin directory, you might call it using the command /usr/local/bin/mytool. In Big Sur, the firmlink between the /usr/local folder on the System volume takes that path through to the correct folder on the Data volume, so you don’t have to change the path to /System/Volumes/Data/usr/local/bin/mytool.
One valuable trick for always using the right path in Terminal is to locate the folder or file in a Finder window, and drag and drop that into the command line. macOS then magically performs any path conversions for you. You may also find my utility Precize useful, as it gives paths, inode numbers, and a great deal more.
Principal folders appear identical across both Intel and Apple Silicon Macs, although the latter have one significant introduction in /Library/Catacomb (Data volume), which contains one or more folders named using UUIDs referring to user information. When Time Machine is used to back up to an APFS volume, in addition to the backup volume being listed in /Volumes, a hidden folder named .timemachine is also added to that folder.
Inodes
Volume IDs in the volfs path and FileReference URL are the same for items on both members of a boot Volume Group. One empirical way to detect whether an item on the boot Volume Group is on the System or Data volume is to look at the value of its inode: those on the System volume are very large numbers, and those on the Data volume are far smaller. This changes when the Volume Group isn’t used for booting: while the inodes themselves inevitably remain the same, the volume IDs in the volfs path and FileReference URL are then different for the System and Data volumes, even though the Volume Group remains linked.
Inodes in the SSV appear identical across different Big Sur installations, although there can be small differences in the volume IDs.
Reference layouts
These are full layouts for Big Sur.
The System volume:
available here as a PDF: BigSurSysR
The Data volume:
available here as a PDF: BigSurDataR
Integrated:
available here as a PDF: BigSurIntegrated
Further reading
Inside the file system: 1 Disks and partitions
Inside the file system: 2 HFS+ volumes
Inside the file system: 3 APFS containers and volumes
Inside the file system: 4 Summary and references
M1 Macs radically change boot and recovery
The Eclectic Light Company 