macOS Storage Cleanup: Which Commands Actually Free Space

This page used to hand out a copy-paste cleanup script and tell readers to run it periodically. Several commands in that script never freed a single byte. They did not error. They exited 0, printed nothing unusual, and left the reader believing a few gigabytes had been reclaimed. Others freed very little while wrecking directories that running processes depend on.

That failure mode — a command that reports success and does nothing — is the part worth writing about, because it is the one thing a man page cannot warn you about. Man pages document what a command does when you call it correctly. They have nothing to say about the command you copied off a blog with a wrong path baked into it. Below is what was wrong here, checked against macOS 26.5.2 (build 25F84).

The snapshot loop that deletes nothing

The old text offered this as “delete all local snapshots”:

for d in $(tmutil listlocalsnapshots / | grep -v "Snapshots" | grep -v "com.apple"); do sudo tmutil deletelocalsnapshots $d; done

Every local snapshot name begins with com.apple.. man tmutil spells out the naming format:

     local snapshot (or snapshot)
             An APFS snapshot of an APFS source volume included in the backup.
             E.g.,

             com.apple.TimeMachine.2011-07-03-123456.local

So the second filter in that pipeline, grep -v "com.apple", throws away every snapshot it was meant to collect. Running the filter against the documented example name and counting what survives:

$ printf 'Snapshots for disk /:\ncom.apple.TimeMachine.2011-07-03-123456.local\n' | grep -v "Snapshots" | grep -v "com.apple" | wc -l
       0

Zero lines. The for loop iterates zero times, sudo tmutil deletelocalsnapshots is never reached, the shell exits 0 and prints nothing. You get a clean prompt back and conclude the snapshots are gone.

The loop is broken twice over. Even with the grep repaired, $d would carry a full snapshot name, and man tmutil does not accept one:

     deletelocalsnapshots {mount_point | date}
	     If a date is specified, delete all local Time Machine snapshots
	     on all mounted disks for the specified date (formatted YYYY-MM-
	     DD-HHMMSS).  If a disk is specified, delete all local Time
	     Machine snapshots on the specified disk

A mount point or a date. Not com.apple.TimeMachine.2011-07-03-123456.local.

Two of the three browser cache paths do not exist

The old text listed these three together:

rm -rf ~/Library/Caches/com.apple.Safari/*
rm -rf ~/Library/Caches/com.google.Chrome/*
rm -rf ~/Library/Caches/org.mozilla.firefox/*

On macOS 26.5.2, only the first one is a real path:

$ cd ~/Library/Caches && for p in com.apple.Safari com.google.Chrome org.mozilla.firefox Google/Chrome Firefox; do [ -e "$p" ] && echo "exists:  $p" || echo "missing: $p"; done
exists:  com.apple.Safari
missing: com.google.Chrome
missing: org.mozilla.firefox
exists:  Google/Chrome
exists:  Firefox

Chrome caches under Google/Chrome, Firefox under Firefox. The bundle-identifier versions were guesses that read as plausible because plenty of other Mac apps really do cache under their bundle ID. And rm -rf against a path that isn’t there is not an error — it is a no-op that exits 0. Two of the three lines above have been quietly doing nothing for as long as this article has been up.

/var/log is the wrong target, by about sixteen times

The old script ran sudo rm -rf /var/log/* under the label “Clear system logs”. The interesting problem isn’t that it’s destructive. It’s that it’s destructive and aimed at the wrong directory:

$ du -sh /var/log /var/db/diagnostics 2>/dev/null
118M	/var/log
1.9G	/var/db/diagnostics

That 2>/dev/null is doing something worth naming. Without it, du prints a Permission denied line for every file your account can’t read — it is loud about the gap — and then prints the total anyway, as if the number were complete. Under sudo the same directory comes back as 124 MB rather than 118 MB. The command isn’t lying to you here; it’s telling you, in a stream most people redirect away, that its own answer is short.

Either way the shape of the answer holds. The unified logging store in /var/db/diagnostics holds 1.9 GB — about sixteen times what /var/log does. Emptying /var/log takes out apache2, asl, cups and com.apple.xpc.launchd, directories that daemons expect to exist and write into, along with install.log, the 34 MB record of what your Mac has installed — in exchange for 118 MB. The bulk of the logs sits somewhere else entirely and goes untouched.

Your ratio will differ from mine — that’s not the point. The point is that “clear /var/log to reclaim log space” is repeated across most macOS cleanup posts on the web, this one included until now, and the ratio is what decides whether the advice is worth anything. Nobody prints the ratio.

/tmp is a symlink to files that are in use

Also in the old script: sudo rm -rf /tmp/*, labelled “Clear temporary files”.

$ ls -ld /tmp
lrwxr-xr-x@ 1 root  wheel  11 25 Jun 10:29 /tmp -> private/tmp

/tmp is a symlink to /private/tmp, which on this machine currently holds 494 entries and 297 MB. Those are not stale leftovers waiting to be swept. They are the scratch files of whatever is running right now, and macOS already clears the untouched ones on its own schedule. Deleting them out from under live processes is how you get an app to fail in a way you will not connect back to the command you ran three minutes earlier. The old text gave that line no warning of any kind.

mdutil -E has nothing to do with storage

Filed under “Storage not reflecting changes”, the old text gave:

sudo mdutil -i on /
sudo mdutil -E /

and called it “Force storage recalculation”. It is not that. From man mdutil:

NAME
     mdutil – manage the metadata stores used by Spotlight
...
     -E  This flag will cause each local store for the volumes indicated to be
	 erased.  The stores will be rebuilt if appropriate.

-E erases the Spotlight index. The volume then reindexes from scratch and Spotlight results are incomplete until it finishes. Whatever storage number you were unhappy with, this is not the command that changes it, and the reindex is a side effect the old text never mentioned.

The tool list had invented facts

• OmniDiskSweeper was listed as “Free download from Mac App Store”. The Omni Group distributes it from omnigroup.com/more as a direct download. It is not a Mac App Store product.
• Disk Inventory X was credited with “cross-platform compatibility”. Its own site, derlien.com, calls it “a disk usage utility for Mac OS X”, and labels the download “(macOS 10.13 – 10.15)” — so it is Mac-only, and that build predates every macOS this article claimed to cover.
• The section was headed “Best Open Source Disk Space Analyzer Tools” while listing OmniDiskSweeper, which is closed-source freeware.

GrandPerspective was the one entry described accurately. It and ncdu (via brew install ncdu) are both worth your time, and both are better documented by their own projects than by a listicle section here, which is why that section is gone rather than rewritten.

What is actually left to do

For snapshots, man tmutil documents a thinning subcommand, which is the mechanism macOS itself uses when a volume runs short:

     thinlocalsnapshots mount_point [purge_amount] [urgency]
	     Thin local Time Machine snapshots for the specified volume.

	     When purge_amount and urgency are specified, tmutil will attempt
	     (with urgency level 1-4) to reclaim purge_amount in bytes by
	     thinning snapshots.

Before reaching for it, look at what you have. On this machine there is nothing to thin:

$ tmutil listlocalsnapshots /
Snapshots for disk /:

A header and no rows. If yours lists snapshots, they already count as purgeable space, and macOS drops them under disk pressure without being asked.

Which is the honest summary, and it is narrower than what this page used to promise. Most of what swells “System Data” in System Settings is snapshots, caches that get rebuilt the moment you reopen the app, and the unified log store — and macOS reclaims all three on its own when the disk gets tight. Apple’s own starting point is Free up storage space on Mac, which routes you to the recommendations in System Settings > General > Storage rather than to a terminal.

The space you can safely free by hand is the space you put there yourself: media, downloads, disk images, VM images, build and container directories whose purpose you can name. ncdu ~ or GrandPerspective will point you at them in about a minute.

And if you look and there is genuinely nothing large in your home directory, then the disk isn’t full of junk — it is just full. That is the point to stop running cleanup commands and price an external drive, because no amount of rm -rf is going to substitute for one.