hoakley Macs, Technology

Where did all that free space go on my APFS disk?

APFS is a more complex and dynamic file system than HFS+, in that there often isn’t a simple answer to how much free space there is on any given disk or volume. This is because there’s more to it than just the file system’s directories and file data. This normally means that there are small discrepancies between different estimates of free and used space, but sometimes those seem huge. As a result, it may appear that an APFS volume or disk is full, and installers and apps may refuse to work despite there apparently being ample free space. This article explains what you can do when faced with that and similar problems.

diskspace1

Most of the time, the Finder’s Get Info dialog returns reasonably reliable figures for used and free space on APFS volumes. When it’s working correctly, the amount given as purgeable represents space which is currently used by snapshots and other dispensible data. But sometimes the figures given in the Finder don’t come close to those in Disk Utility or at the command line. When space is running short, macOS is supposed to start purging what’s reported as being purgeable, including old snapshots, but that doesn’t always happen when you’d expect it.

The next stop is a quick check in Disk Utility, for its estimate of what’s used and free, which tends to be more reliable than the Finder. This is also a good time to look at APFS containers and disk partitioning. Recall that, while APFS volumes share the same space within a container, containers don’t share space but occupy a fixed size.

diskspace2

Disk Utility isn’t so good at revealing hidden volumes which could be stealing space within a container. For this, the best measure is
diskutil list internal
or
diskutil list external
depending on which disk you want to look at. The standard layout for an internal boot volume should appear something like
/dev/disk4 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk4
1: EFI EFI 314.6 MB disk4s1
2: Apple_APFS Container disk5 1.0 TB disk4s2

/dev/disk5 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1.0 TB disk5
Physical Store disk4s2
1: APFS Volume Macintosh HD - Data 563.9 GB disk5s1
2: APFS Volume Preboot 81.5 MB disk5s2
3: APFS Volume Recovery 528.1 MB disk5s3
4: APFS Volume VM 2.1 GB disk5s4
5: APFS Volume Macintosh HD 11.1 GB disk5s5

By now you should be happy that any missing free space isn’t because of partitioning, or being stolen by a hidden volume within the same container. Now’s the time to see what’s using up the space within that volume. Your first suspicion should be old snapshots. The best tool for looking at these is Mike Bombich’s Carbon Copy Cloner (CCC), which provides a friendly graphical interface to snapshots.

diskspace3

To see space occupied by snapshots, select the disk and temporarily enable CCC Snapshots. After a few seconds, you should see a list of all snapshots on that volume and their sizes. You can then clean up older and larger snapshots as you wish, and much of that purgeable space should be freed fully. If you really won’t buy CCC, you can do similar things in Terminal’s command line.

tmutil listlocalsnapshots /
lists all snapshots on your boot volumes, or use the volume path instead of / for a different volume. To purge them, use a command like
tmutil thinlocalsnapshots /Volumes/ThunderBay1 10000000000000000 1;
which should get macOS to start removing them.

Another utility which you might find helpful is DaisyDisk. This can list ‘hidden space’ on a volume.

diskspace4

When you click on snapshots… it will then list all known snapshots on that volume, but the App Store version can’t delete any directly, instead providing you with the command to use in Terminal.

diskspace5

By now, you should have a reasonable idea as to where your free space went, and ample opportunities to reclaim at least some of it. This doesn’t always solve problems with installers and apps though. A few seem to want many more GB than they need. That may be because they use scratch space, for example to decompress and process their payload. A few just don’t seem able to get their estimates of free space right, in which case you’ll need to inform the developer and ask them for a workaround.