Open Disk Utility on a modern Mac and you will see something that looks unfamiliar if you learned disk layout on an older system: several named volumes — Macintosh HD, Macintosh HD - Data, maybe others you created — nested under one entry representing the physical disk, none of them showing a fixed size that adds up to the drive's total capacity. That is APFS's container-and-volume model, and it deliberately replaces the old idea of a disk carved into fixed-size partitions. Understanding the difference between a container and a volume — and the fact that volumes share space rather than reserving it — explains why you can create a new volume in seconds without shrinking anything else, and why "how much space does this volume have" is a more fluid question on APFS than it used to be.

The container: the outer structure

An APFS container is the layer that actually owns a physical partition (or an entire disk, if there is only one partition). Structurally, the container is what shows up in older partitioning language as "a partition," but functionally it behaves more like a shared pool. Inside it, APFS keeps track of overall free space, manages the low-level allocation of blocks, and can hold more than one volume simultaneously, each drawing from that same underlying pool of free space as needed. A single physical drive is typically a single APFS container containing all of that drive's APFS volumes, though a disk can be partitioned into multiple containers if you deliberately want hard boundaries.

Volumes: logical divisions, not fixed slices

Inside a container, a volume is what actually holds a filesystem — the thing you mount, browse in Finder, and store files on. This is the crucial difference from older, partition-based systems: a volume in APFS does not claim a fixed slice of the disk up front the way a traditional partition did. All volumes in the same container draw from the container's single free space pool, growing and shrinking as their contents change, without anyone needing to resize a partition table. If your Mac has both "Macintosh HD" (the read-only system volume) and "Macintosh HD - Data" (where your actual files live) inside one container, both are pulling from the same underlying free space, and macOS's own storage reporting adds them together to give you one number for "how much space is left."

This is why creating a new APFS volume does not require you to decide in advance how big it should be, and does not shrink your existing volumes at the moment you create it. The new volume simply becomes another consumer of the same shared pool. Its practical size limit is whatever free space remains in the container as a whole, minus whatever the other volumes are currently using.

What each volume can set independently

Even though volumes in one container share free space, each volume is otherwise a largely independent unit with its own settings:

  • Snapshots — APFS's point-in-time, copy-on-write snapshots (the kind Time Machine takes locally, listable with tmutil listlocalsnapshots /) are taken per volume, not per container. A snapshot only captures the state of the specific volume it was taken on.
  • Encryption — one volume in a container can be encrypted with FileVault while another, in the same container, is not. Encryption is a per-volume property, not something the container imposes uniformly on everything inside it.
  • Mount behaviour and role — a volume can be marked as the boot volume, a data volume paired with a system volume, or an ordinary user-created volume, independently of how other volumes in the same container are configured.

That independence, combined with shared free space, is the actual point of the design: you get the isolation benefits of separate volumes — different encryption states, independent snapshot histories, separate mount points — without the old cost of committing a fixed amount of physical space to each one in advance.

Adding a volume

Creating a new APFS volume is a Disk Utility operation, not a repartitioning one. Selecting the container (rather than a specific volume inside it) in Disk Utility's sidebar reveals a + control for adding a new volume to that container. The new volume appears immediately, mountable and usable, without any of the existing volumes needing to be resized, unmounted for an extended operation, or backed up first the way a traditional partition resize historically demanded. This is genuinely useful for isolating a specific workload — a separate volume for a large Boot Camp-adjacent data set, a scratch volume for temporary large files, or a distinctly encrypted volume for sensitive material — while keeping the flexibility of a single shared pool of space behind the scenes.

Why this occasionally confuses storage tools and users alike

Because volumes do not have a fixed capacity of their own, a naive tool that reports "volume X has Y bytes free" is really reporting the container's free space at that instant, filtered through that volume's current usage — a number that can change the moment another volume in the same container writes or deletes data. df -h reflects this: multiple APFS volumes on the same physical disk will typically report the same, or very similar, "available" figures, because they are drawing from the same pool rather than each having a separately reserved allowance.

Conclusion

APFS containers and volumes trade the rigidity of fixed-size partitions for a shared pool that flexes as your actual usage changes, while still letting each volume keep its own snapshot history and encryption state — a genuinely better model for how people actually use a modern Mac, once you understand that a volume's "size" is really just its current claim on a bigger shared pot.

Because container and volume boundaries affect what a scan can even see — a tool generally has to be pointed at a specific volume to walk it — this is part of what we account for under the hood in VolumeLens, so the numbers you see reflect the actual volume you scanned rather than assumptions about a fixed partition that no longer exists on modern Macs.