Creating and Managing APFS Containers and Volumes with diskutil
Understanding the container/volume distinction that makes APFS fundamentally different from older partition schemes, and using diskutil directly to add, resize, and manage volumes without wasting disk space on fixed partitions.
APFS’s container/volume model is structurally different from the fixed-size partition schemes it replaced, and understanding that difference directly is necessary for using diskutil correctly to manage APFS storage — the mental model of “each partition has a fixed size carved out of the disk” simply doesn’t apply the way it did with older filesystems.
The container/volume distinction
An APFS container occupies physical disk space (analogous to a traditional partition), but volumes within that container share the container’s total free space dynamically rather than each being allocated a fixed size upfront. This means adding a new volume to an existing container doesn’t require shrinking another volume to make room for it the way adding a new traditional partition would — every volume in the container simply draws from the same shared free-space pool as needed.
Viewing current container and volume layout
diskutil listThis shows the physical disk, its container(s), and every volume within each container — noticeably different output from a traditional partition table, since volume sizes shown here reflect currently used space rather than a fixed allocated size, given that free space is shared across the container rather than pre-divided.
Creating a new volume within an existing container
diskutil apfs addVolume disk1 APFS "New Volume Name"This adds a new, empty volume to the specified container, immediately able to draw from the container’s shared free space — no resizing of existing volumes required, which is the single biggest practical advantage over traditional partitioning for anyone who wants to separate data into multiple logical volumes without pre-committing to fixed size splits upfront.
Why you’d want multiple volumes in one container at all
Common reasons: keeping a separate volume for a specific purpose (a dedicated volume for virtual machine disk images, kept logically separate for organizational or backup-inclusion reasons, without the rigidity of a fixed-size partition), or creating a volume with different specific settings (a case-sensitive APFS volume for development work requiring case sensitivity, alongside the default case-insensitive system volume, both sharing the same underlying free space).
Setting a size quota on a specific volume
While volumes share free space by default, you can still cap a specific volume’s maximum usage to prevent it from growing unbounded and starving other volumes in the same container of space:
diskutil apfs updateVolume disk1s3 -limit 100g -reserve 0-limit sets the maximum size this volume can grow to; -reserve sets a minimum guaranteed amount reserved for this volume even under container-wide space pressure from other volumes. This is meaningfully different from traditional partition sizing — the reservation/limit here is a policy applied within shared free space, not a hard, physically separate allocation the way a traditional partition boundary would be.
Deleting a volume
diskutil apfs deleteVolume disk1s3The freed space immediately returns to the container’s shared free-space pool, available to every other volume in that same container — again, a direct consequence of the shared-space model, distinct from deleting a traditional partition, which would leave unallocated space that still needs to be explicitly assigned somewhere before anything else can use it.
Creating snapshots directly via diskutil
Beyond volumes themselves, diskutil can trigger APFS snapshots directly:
diskutil apfs snapshot disk1s1This creates a point-in-time, space-efficient snapshot of the specified volume — the same underlying mechanism Time Machine itself relies on for local snapshots, directly accessible for your own manual use cases outside of Time Machine’s own automatic scheduling.
Converting an existing container to encrypted
diskutil apfs encryptVolume disk1s1 -user diskThis enables encryption on an existing, already-populated volume in place, without requiring a separate reformat-and-restore cycle — a genuine advantage of APFS’s design over older filesystems, where enabling full-disk encryption on already-populated storage typically required backing up, reformatting, and restoring data rather than converting in place.
Why understanding this model matters beyond just the commands
Treating APFS volumes as if they were traditional fixed-size partitions — assuming you need to “shrink” one volume to make room for another, for instance — leads to unnecessary, overly cautious disk management decisions that the shared free-space model was specifically designed to eliminate. Understanding the container/volume distinction directly changes how you’d actually approach a multi-volume layout, favoring flexible, dynamically-shared volumes over the rigid, pre-allocated partition sizing that made sense under older filesystem designs but no longer reflects how APFS actually manages space.