Sweepfor Mac

Free up storage

The macOS Sonoma Storage Bug: What It Was, What It Is Now

Sonoma's early System Data storage-reporting bug, what Apple fixed in 14.4.1, and what to do if your Sonoma Mac still shows wildly inflated storage.

7 min read

When Sonoma launched in late 2023, a measurable percentage of users saw their System Data category balloon overnight. Macs that had 50GB free showed 5GB free a day later, with no obvious change in usage. The Storage breakdown in System Settings showed System Data at 200GB+, sometimes more.

That was a real bug. Apple fixed the reporting issue in 14.4.1. But the underlying caches that fed it were still on disk. Sonoma users who upgraded early and never did a manual cleanup may still be carrying that weight.

Here’s the actual story and what to do now.

What the bug actually was

Two things were happening simultaneously:

  1. APFS snapshot accounting — Sonoma was reporting Time Machine local snapshots and other APFS snapshot space as part of System Data, even when those snapshots were being held for legitimate reasons. The bar showed a number that was technically accurate but practically misleading: the space couldn’t be reclaimed without affecting Time Machine’s ability to roll back.

  2. Mail attachment cache double-counting — Mail was caching attachments in two locations during the Sonoma upgrade migration, and storage reporting was counting both. This was a true accounting bug.

  3. Apple File System Daemon (apfsd) failing to release deleted file space — on some configurations, deleted files weren’t immediately freed. The space sat in System Data until a restart triggered cleanup.

Apple’s 14.4.1 release fixed the reporting and the Mail double-counting. The APFS snapshot issue was largely fixed in 14.5. By 14.7, the bug class was resolved.

How to know if you’re still affected

If you upgraded to Sonoma between October 2023 and April 2024 and never did a manual storage cleanup, you might still have residual cache files from that period.

Indicators:

  • System Data over 80GB on a Mac with normal usage
  • Storage doesn’t update after deleting large files (you delete 5GB, free space goes up by 200MB)
  • Mail attachments folder unusually large — 20GB+
  • Time Machine local snapshots that haven’t been pruned

Run through the storage check below to find out.

Step 1: Update to the latest 14.x

System Settings → General → Software Update.

If you’re on 14.0–14.3, update at minimum to 14.4.1. Ideally, update to the latest 14.7.x. The post-14.4.1 releases include better cache management that prevents the original bug from recurring.

After updating, restart and let the Mac sit idle for ten minutes. macOS runs internal cleanup during idle time.

Step 2: Check for orphaned snapshots

The original bug left a lot of users with Time Machine local snapshots that weren’t being pruned automatically.

Terminal:

tmutil listlocalsnapshots /

Each line is a snapshot. If you see more than 5–6 lines, something’s not pruning. Delete the oldest:

tmutil deletelocalsnapshots <date-from-list>

Or all of them:

for snap in $(tmutil listlocalsnapshots / | awk -F. '{print $4}'); do tmutil deletelocalsnapshots $snap; done

Restart after. macOS creates fresh snapshots on its own schedule.

This step alone often recovers 30–50GB on Macs hit by the original bug.

Skip the manual huntSweep finds every cache, log, and forgotten file in seconds. Download Sweep free →

Step 3: Check Mail attachments

The Mail double-counting bug left some Macs with literal duplicate attachment caches.

Quit Mail. In Finder, navigate to:

~/Library/Mail/V10/MailData/

For each account folder inside, look for Attachments/. The size will tell you whether Mail is hoarding. If it’s 5GB+ and you’re an IMAP user, you can delete the contents of that Attachments folder safely — Mail re-downloads on demand from the server.

To prevent future growth:

Mail → Settings → Accounts → select account → Account Information → Download Attachments → set to Recent (only newest, ~30 days) or None.

Step 4: Run a manual cache pass

The standard Sonoma cache offenders, regardless of the bug:

  • Xcode DerivedData: ~/Library/Developer/Xcode/DerivedData/ (10–50GB)
  • Chrome cache: ~/Library/Caches/Google/Chrome/Default/Cache/
  • Slack cache: ~/Library/Application Support/Slack/Cache/
  • Spotify cache: ~/Library/Caches/com.spotify.client/Data/
  • Old iOS backups: ~/Library/Application Support/MobileSync/Backup/

Quit each app first, then move the cache to Trash.

Tip: The iOS backup folder isn't auto-pruned by macOS or Finder. If you've used this Mac to back up phones since Big Sur, you likely have multiple gigs of stale backups. Sort by date, keep the newest backup of each device, delete the rest.

Step 5: Restart and recheck

A lot of Sonoma’s storage-reconciliation work happens during boot. Restart after the cleanup steps and recheck System Settings → General → Storage. Wait a full minute for the bars to populate.

If System Data dropped meaningfully, you were carrying residual files from the original bug period. If it didn’t drop, you weren’t affected.

There’s a faster waySweep does the same hunt in seconds. Try Sweep free →

What if System Data is still huge?

If you’ve done all of the above and System Data is still 80GB+, the issue isn’t the original bug. It’s accumulated cruft. Common candidates:

  • Photos library — large libraries often appear in System Data when iCloud Photos is mid-sync.
  • Apple Intelligence model files — wait, that’s Sequoia. Not relevant on Sonoma.
  • Final Cut / Motion render caches~/Library/Containers/com.apple.FinalCut/Data/Library/Caches/
  • Adobe Premiere / After Effects caches/Users/Shared/Adobe/Common/Media Cache Files/
  • Music Apple Lossless cache — if you’ve enabled lossless in Music, it caches a lot locally.

Check each app’s settings for cache management before deleting their cache folders blindly.

How to tell legitimate System Data from bug residue

A few rules of thumb:

  • Normal System Data on Sonoma: 15–35GB
  • Borderline: 35–60GB (worth investigating)
  • Definitely bloated: 60GB+ (something is wrong)

The clean Sonoma install footprint is around 15GB of OS plus 8–12GB of normal cache and log activity. Anything beyond that is reclaimable.

Was it ever as bad as people said?

Some viral posts claimed Sonoma’s bug consumed entire SSDs. That was rare. More commonly:

  • Average affected user: 30–60GB extra in System Data
  • Heavy users (large Mail, lots of Time Machine snapshots): 80–150GB
  • The viral cases (300GB+): real but unusual, often involving migration assistant from another Mac

If you’re seeing 30–60GB beyond normal, you were a typical case. If you’re seeing 150GB+, you may have migrated from another Mac during the bug period and copied its bug residue too.

What to do going forward

After the cleanup:

  1. Set Mail to “Recent” or “None” for attachments. Prevents recurrence of attachment hoarding.
  2. Trim Time Machine local snapshots monthly if you’re not consistently on a backup drive.
  3. Empty Downloads and Trash regularly.
  4. Restart at least weekly. macOS does maintenance at boot that catches small accounting issues before they snowball.

Sonoma in 2026 is stable. The storage bug is a closed chapter for new installs. If yours is acting weird, the fix is the cleanup above plus making sure you’re current on point releases.

← Back to all guides