Why macOS says you have free space while your disk is full
Finder says 40 GB available. Your build says no space left on device. Both are right — here is the mechanism, and how to get the space back.
Updated 2026-08-13
The contradiction
Finder shows 42 GB available. Xcode refuses to build. Docker says no space left on device. df -h agrees with Finder, du disagrees with everyone. Nothing here is broken, and nothing is lying to you — three different tools are answering three different questions.
The short version: macOS counts space that it could free as available, without freeing it. Most of that space is held by local APFS snapshots. Until they expire or you delete them, that space belongs to the snapshot, not to you — and a program asking the kernel for a block gets told no.
See it for yourself
Two commands, thirty seconds. Run them both and compare.
$ df -h /System/Volumes/DataThe kernel's own answer. This is the number your compiler gets. Look at Avail, not Capacity.
$ diskutil apfs list | grep -A2 SnapshotLists the local APFS snapshots on the volume, if any exist.
$ tmutil listlocalsnapshots /The same thing, more readable. Each line is a point in time Time Machine kept locally.
Why 'purgeable' is not free
Finder's 'available' figure is really 'free blocks plus purgeable blocks'. Purgeable means macOS believes it can reclaim it if something asks loudly enough — snapshot data past its retention, cached iCloud files, and a few other categories.
The catch is that reclamation is not instant and not guaranteed. The kernel frees purgeable space under memory and disk pressure, on its own schedule. A build system that requests 8 GB in one allocation does not trigger that machinery gracefully — it just fails. So you get a full disk and a Finder window that insists everything is fine.
| What you run | What it counts | Typical answer |
|---|---|---|
| Finder → About This Mac | Free + purgeable | Optimistic |
| df -h | Free blocks, as the kernel sees them | What your compiler gets |
| du -sh ~/dev | Apparent size of files, double-counting clones | Wildly pessimistic |
| tmutil listlocalsnapshots / | The snapshots holding the difference | The actual answer |
Get the space back
In order. Stop at the first one that gives you enough — there is no reason to go further than you need.
1. Thin the local snapshots. This is the one that usually does it.
$ tmutil thinlocalsnapshots / 100000000000 4Asks macOS to free up to ~100 GB by removing local snapshots, at urgency level 4 (the most aggressive). This deletes local restore points only — your Time Machine backups on external or network drives are untouched.
2. If you want to remove them individually rather than in bulk:
$ tmutil deletelocalsnapshots 2026-08-01-120000Removes one snapshot by its exact date, as printed by listlocalsnapshots.
3. Then the usual developer sinkholes, which are what filled the snapshots in the first place:
$ rm -rf ~/Library/Developer/Xcode/DerivedData/*Xcode build intermediates. Rebuilds itself. Commonly 10–60 GB.
$ xcrun simctl delete unavailableiOS simulators for runtimes you no longer have installed.
$ docker system prune -a --volumesDocker images, containers and volumes. Read this one twice: --volumes deletes database contents.
$ brew cleanup --prune=allOld Homebrew downloads and versions.
Why du lies too, in the opposite direction
du -sh node_modules might say 800 MB when deleting it frees almost nothing. On APFS, pnpm and Bun populate node_modules by cloning from a shared store rather than copying. The blocks are shared with the store; the inodes differ, link counts are 1 on both sides, and each side reports the full size.
No system call reports this at a cost compatible with walking millions of directory entries. That is why any honest tool gives you a range rather than a number — a floor it can promise, and a ceiling it would reach if nothing were shared.
Will thinning snapshots delete my Time Machine backups?
No. Local snapshots are temporary restore points kept on the internal disk between backups. Your backups on an external or network drive are separate and are not affected.
Why did the space not come back immediately?
Snapshot deletion is asynchronous and the volume's free-space accounting can lag by a few seconds. Re-run `df -h` after a moment. If it still has not moved, another snapshot is holding the same blocks.
Can I stop macOS from taking local snapshots?
You can disable Time Machine entirely, which stops them — but that also removes your automatic backups, which is a bad trade for a disk space problem. Thinning periodically is the better answer.
I freed 30 GB and df still shows the same. Why?
Almost always a snapshot taken after the files existed but before you deleted them. Thin the snapshots and check again.
The automated version
Everything above works, costs nothing, and will keep working. Loupe does the same across every project on your disk at once, and shows what each deletion will cost to rebuild before you agree to it.
Related guides