My work MacBook Air was somehow completely out of space. System Settings → General → Storage wasn't much help: no single category explained it. No giant Photos library, no bloated Mail archive, nothing that screamed "here's your problem." Just a laptop that was mysteriously full. In fact, I don't sync any of my personal iCloud stuff to my Mac, and I've since switched from an iPhone to an Android phone.

Here's how I actually found it, and why it turned out to have nothing to do with anything I was actively using.

The Usual Suspects (All Wrong)

First stop was ~/Library/Caches, the classic "delete me, I'll rebuild" folder:

bash

du -sh ~/Library/Caches/* | sort -rh | head -30

Total damage: about 5 GB, mostly Chrome's cache. Worth clearing, but not remotely the problem.

Next I checked Steam. Game libraries are a classic space hog, and I had a couple of old installs I'd never fully cleaned out:

bash

du -sh ~/Library/Application\ Support/Steam

1.1 GB. A red herring, but a reasonable one, and worth ruling out early.

Widening the Net

Time to stop guessing folder by folder and ask the filesystem directly what's actually big:

bash

sudo du -sh ~/* 2>/dev/null | sort -rh | head -20

379 GB in ~/Library. Everything else in my home folder combined didn't crack 2 GB. The entire problem was hiding inside one folder tree that Finder doesn't even show by default.

One level deeper:

bash

sudo du -sh ~/Library/*/ 2>/dev/null | sort -rh | head -20

And there it was:

349G    /Users/<you>/Library/Logs/
 20G    /Users/<you>/Library/Application Support/
5.0G    /Users/<you>/Library/Caches/

Not caches. Not app data. Logs.

The Actual Culprit

One more level down:

bash

sudo du -sh ~/Library/Logs/*/ 2>/dev/null | sort -rh | head -20
348G    /Users/<you>/Library/Logs/Genuity/
684M    /Users/<you>/Library/Logs/CreativeCloud/
163M    /Users/<you>/Library/Logs/Adobe/

Genuity is a device management/agent tool I had tested and was considering using until they increased pricing. I hadn't used it in a long time, but it had left behind a single log file that had grown to 348 GB. Not a folder full of files. One file.

I deleted it before thinking to check its contents, so I can't say for certain what was actually being logged. But the shape of the problem, one continuously-growing file with no rotation or size cap, fits a familiar pattern: something failing repeatedly and logging every attempt with nothing to cap it. I don't know if this is a known issue with Genuity's agent, specific to how it was left installed on my machine, or something else entirely.

The pattern itself is well documented elsewhere. Apple Mail's IMAP sync log has done the same thing to people (one Apple Community thread describes a 342 GB Mail log from the same failure-loop behavior), and Adobe Audition has a known bug where a repeating error fills a log past 100 GB. Different vendors, same root cause: something keeps failing, and nothing caps how much it's allowed to complain about it.

Cleaning It Up

Since I don't use Genuity anymore, this wasn't a "fix the logging" situation. It was "remove the whole thing."

1. Delete the log. This is the step where I lost the evidence, and it freed nearly all the space:

bash

rm -rf ~/Library/Logs/Genuity
If the space doesn't come back after deleting a huge file, a running process probably still has it open. sudo lsof +L1 lists deleted-but-still-open files and the process holding each one. Quit or kill that process and the space is released.

2. Find what was launching it. A leftover agent can keep running (and keep re-logging) even after you clear its logs:

bash

ls ~/Library/LaunchAgents/ /Library/LaunchAgents/ /Library/LaunchDaemons/ | grep -i genuity

That turned up /Library/LaunchAgents/com.genuity.MacAgent.plist, a LaunchAgent installed for all users. LaunchAgents run in your login session, not the system domain, so check without sudo:

bash

launchctl list | grep -i genuity
pgrep -il genuity

Both came back empty. Nothing was running, so there was nothing to stop, just the plist to remove:

bash

sudo rm /Library/LaunchAgents/com.genuity.MacAgent.plist

(If it had been loaded, run launchctl bootout gui/$(id -u) /Library/LaunchAgents/com.genuity.MacAgent.plist first.)

3. Sweep for leftovers. This is slow because it walks the whole disk, and it needs sudo to see into protected folders:

bash

sudo find / -iname "*genuity*" 2>/dev/null

That turned up preferences, cached data, and an HTTP storage folder, all safe to remove:

bash

rm -rf ~/Library/Preferences/com.genuity.MacAgent.plist
rm -rf ~/Library/HTTPStorages/com.genuity.MacAgent
rm -rf ~/Library/Caches/com.genuity.MacAgent
rm -rf "$(getconf DARWIN_USER_CACHE_DIR)com.genuity.MacAgent"

That last one lives under /private/var/folders/xx/<random>/C/, which is different on every Mac. getconf DARWIN_USER_CACHE_DIR gives you yours.

4. Forget the package receipt (optional). The receipt is only a few KB, but you can clear it cleanly:

bash

pkgutil --pkgs | grep -i genuity
sudo pkgutil --forget <package-id-from-above>

5. Confirm.

bash

df -h /
/dev/disk3s1s1   460Gi   10Gi   345Gi   3%

The number that matters is Avail: 345 GB free out of 460 GB. (Don't read too much into "Used" and "3%" here. On modern macOS, / is the read-only system volume, so those columns don't include your data. df -h /System/Volumes/Data shows the Data volume, which holds your files.)

Problem solved.

The Takeaway

If your Mac is mysteriously out of space, and Storage Management, caches, and the obvious folders (Downloads, Photos, Movies) don't explain it, don't stop there. A bloated ~/Library often just shows up as a huge gray "System Data" bar. Run this and actually look at Logs, not just Application Support or Caches:

bash

sudo du -sh ~/Library/*/ 2>/dev/null | sort -rh | head -20

An uninstalled tool doesn't always clean up after itself. If it left a background agent with no UI and no Dock icon, you'd never know it was still there, quietly filling your disk, until you went looking.

For Fleet Admins: A Quick Spot-Check Script

If you manage Macs and have ever deployed (and later moved away from) an agent-based tool, check the whole fleet instead of a few machines. This script runs as root through any MDM or RMM tool (Mosyle custom commands, Jamf, Kandji, Atera, and so on). It reports:

  • any item in any user's ~/Library/Logs larger than 5 GB
  • any leftover LaunchAgent or LaunchDaemon matching a vendor name you choose

It exits 1 when it finds something, so your RMM can flag the device.

bash

#!/bin/bash
# Spot-check for runaway logs and leftover agents.
# Run as root via MDM/RMM. Exit 0 = clean, 1 = findings.

THRESHOLD_GB=5
VENDOR="genuity"        # change to any retired agent's name

shopt -s nullglob nocaseglob
found=0

# 1. Oversized items in each user's ~/Library/Logs
for home in /Users/*; do
  [ -d "$home/Library/Logs" ] || continue
  while IFS=$'\t' read -r kb path; do
    gb=$(( kb / 1024 / 1024 ))
    if [ "$gb" -ge "$THRESHOLD_GB" ]; then
      echo "LARGE LOG: ${gb} GB  $path"
      found=1
    fi
  done < <(du -sk "$home"/Library/Logs/* 2>/dev/null)
done

# 2. Leftover launch items for the vendor
for p in /Library/LaunchAgents/*"$VENDOR"* \
         /Library/LaunchDaemons/*"$VENDOR"* \
         /Users/*/Library/LaunchAgents/*"$VENDOR"*; do
  echo "LEFTOVER LAUNCH ITEM: $p"
  found=1
done

# 3. Running processes for the vendor
if pgrep -il "$VENDOR" >/dev/null; then
  echo "RUNNING PROCESS: $(pgrep -il "$VENDOR" | tr '\n' ' ')"
  found=1
fi

[ "$found" -eq 0 ] && echo "OK: no logs over ${THRESHOLD_GB} GB, no ${VENDOR} leftovers"
exit $found

This bug doesn't announce itself until someone's laptop hits zero free space. Five minutes of scripting now beats a help desk ticket later.