Mac maintenance
What Are 'Other Volumes' on a Mac and Why Do They Matter?
Other Volumes on Mac shows up in Disk Utility and Storage but baffles most users. Here's what's actually mounted, why APFS makes it confusing, and what to leave alone.
Open Disk Utility, click your internal SSD, and you’ll see something that looks like a Russian nesting doll: a physical disk, an APFS container inside it, and four or five volumes inside that. The one labeled “Macintosh HD” is obvious. The ones called “Preboot,” “Recovery,” “VM,” and “Update” — those are the “Other Volumes” that confuse everybody.
Apple’s APFS file system completely rethought how Macs lay out their boot drive. The result is more reliable, more flexible, and significantly more confusing if you grew up with a single “Macintosh HD” volume that contained everything. Let’s untangle what each of those volumes does, why some of them are huge, and what (if anything) you can do about it.
The APFS Container Model
Before APFS, your Mac had one or maybe two volumes on its drive: the boot volume and possibly a recovery partition. Each volume had a fixed size you’d carved out at format time. If you needed to move space between them, you reformatted.
APFS replaced that with a container — a single allocation pool that multiple volumes share. Each volume sees the same total free space, and they grow and shrink dynamically as needed. The container is what physically owns the disk’s bytes; the volumes inside are logical groupings.
When you look in Disk Utility and see “Container disk3” with five volumes underneath, that’s the model. The volumes don’t have fixed sizes — they all share the container’s free space.
The Five Volumes on a Modern Mac
A standard macOS Sonoma or Sequoia install creates these volumes:
- Macintosh HD — The signed system volume (read-only, holds the OS)
- Macintosh HD - Data — Your data volume (apps, user folders, settings)
- Preboot — Files needed to boot the system before the main volume mounts
- Recovery — The Recovery partition for booting into Recovery mode
- VM — Virtual memory swap files
You may also see:
- Update — Used during macOS updates as a staging area
- xART — Hardware-related, on Apple Silicon Macs
- iSCPreboot — Internal system content preboot
Each of these has a job. Some are tiny (Preboot is usually under 2 GB). Some can balloon (VM grows with how much swap your Mac is using).
Why You See Two “Macintosh HD” Volumes
This trips people up constantly. Since macOS 10.15 Catalina, Apple split the boot volume into two: a sealed read-only system volume and a writable data volume. They’re presented to you as a single space (you see one “Macintosh HD” in Finder), but Disk Utility shows both.
The system volume holds the OS itself and is cryptographically signed. Even with admin privileges, you can’t write to it during normal operation — System Integrity Protection enforces that. The data volume holds everything else: /Users, /Applications (for non-Apple apps), /Library (most of it), /private/var, and so on.
The two are joined via “firmlinks” so that paths like /Users/yourname work transparently even though they live on the data volume. To see the firmlink mapping:
cat /usr/share/firmlinks
You’ll see entries like /Applications mapped to /System/Volumes/Data/Applications. The OS resolves these at every access.
What Each “Other” Volume Does
Let’s go one by one, because they’re each genuinely different.
Preboot
Holds the kernel collections and other artifacts the bootloader needs to load before the main system volume is decrypted and mounted. On Apple Silicon Macs, this is where the Local Policy and signed boot manifest live. Size: usually 1–2 GB. Not user-touchable.
Recovery
The Recovery OS that runs when you hold Cmd+R at boot (Intel) or hold the power button to enter Startup Options (Apple Silicon). It’s a stripped-down macOS with Disk Utility, Terminal, the macOS installer, and Safari. Size: 600 MB to 1.5 GB.
VM
This is where macOS stores swap files for virtual memory paging. When your Mac runs out of physical RAM, the kernel writes least-recently-used pages to /private/var/vm/swapfile0, swapfile1, and so on. The VM volume can range from a few hundred MB on a Mac with plenty of RAM to 20+ GB on a heavily loaded 8 GB Mac. To see the current swap usage:
sysctl vm.swapusage
You’ll get something like total = 4096.00M used = 2034.50M free = 2061.50M.
Update
Used during system updates to stage the new OS before it’s switched in. After a successful update, this volume should empty out. If it’s still huge weeks after an update, the update didn’t finish cleaning up.
xART (Apple Silicon only)
Stands for “extended Authenticated Restorable Token.” It holds replay-protected secure tokens used by the Secure Enclave. Tiny. Not user-touchable.
Why You Can’t Just Delete Them
Disk Utility lets you click the minus button on most volumes, but it’ll refuse on the system-required ones. Even if you could delete Preboot or Recovery, your Mac would refuse to boot or you’d lose the ability to enter Recovery mode.
The only “Other” volume that’s effectively user-managed is VM, and even that you don’t manage directly — you just give your Mac more free RAM (or more free disk space, since swap needs disk room).
When They Cause Problems
Most of the time, these volumes are background noise. But three scenarios where they actively cause issues:
1. Out-of-space errors despite “having” space. If your data volume reports 5 GB free but the container is at 99% (because VM, snapshots, or Update have grown), apps will fail to save with confusing errors. Check container-level free space:
diskutil apfs list
Look at the “Capacity Used” line for the container itself, not just for Macintosh HD - Data.
2. Update volume stuck. A failed macOS update can leave the Update volume holding 10+ GB. If a subsequent update tries again and fails, it can pile up. The fix is usually to download a fresh installer from the App Store and rerun the update.
3. Recovery volume corruption. If Cmd+R or Startup Options doesn’t work, your Recovery volume may be damaged. Internet Recovery (Cmd+Option+R on Intel) bypasses the local Recovery volume. On Apple Silicon, the Recovery system is part of the boot chain, and serious corruption requires Apple Configurator and another Mac to restore.
Time Machine Snapshots and the Container
Local Time Machine snapshots aren’t exactly “Other Volumes” — they’re hidden within the data volume — but they show up in disk usage analysis as something separate. List them:
tmutil listlocalsnapshots /
These can hold tens of gigabytes hostage. They’re not visible in Disk Utility’s volume list, but they consume container free space exactly as if they were.
To remove them aggressively:
sudo tmutil thinlocalsnapshots / 10000000000 4
That’s “remove snapshots to free at least 10 GB at urgency 4.”
What “Other Volumes in Container” Means in Disk Utility
This is the specific phrase that drives people nuts: at the top of Disk Utility’s storage bar, you’ll see your container, and underneath it’ll say something like “Other Volumes in Container: 8.3 GB.” That number is the combined size of every volume in the container except the one currently selected.
So if Macintosh HD - Data is selected, “Other Volumes in Container” includes Macintosh HD (the system, ~10 GB), Preboot, Recovery, VM, and Update. It looks alarming the first time you see it — “what’s eating 25 GB?” — but it’s just the standard system volumes.
The number gets actually concerning when:
- It’s higher than 30 GB on a system that hasn’t been updated recently (something’s stuck)
- It changes wildly over short timeframes (snapshots accumulating, swap thrashing)
- A volume named something unfamiliar (like a leftover from a third-party VM or a partition you forgot you made) shows up
Cloning, Migration, and “Other Volumes”
When you migrate to a new Mac with Migration Assistant, the new Mac creates its own fresh set of system/Preboot/Recovery/VM volumes. You don’t bring those over — they’re regenerated from the OS install on the new machine. Only the Data volume content gets migrated.
This is why a Migration Assistant transfer of “200 GB” might show as 215 GB on the new machine: the new machine’s own Other volumes add their own footprint that wasn’t included in the source measurement.
What Actually Matters
For most users, the answer is “ignore Other Volumes — they’re system housekeeping.” For users running tight on space, the practical actions are:
- Keep an eye on VM size, which is a proxy for memory pressure
- Watch for Update that didn’t clean up after itself
- Use
tmutilto thin local snapshots when free space gets tight - Check container-level free space, not just data volume free space
Everything else in this list is structurally required for macOS to boot, decrypt your drive, and recover from problems. The right mental model is “container with multiple specialized rooms,” not “one big disk that’s been sliced up wrong.”