the 556 GB ghost in my SSD

Not a GamaHaus update — but this is the machine I’m building it on, so it counts. Logs aren’t always green checkmarks; sometimes they’re “spent a day digging out of my own past mistakes.”

Sat down to work at 6 AM and the laptop refused to boot to desktop. Disk at 100%, zero bytes free of 717 GB. GDM, MySQL, VirtualBox — all dead. Linux can’t start services without scratch space.

Dropped into a maintenance shell and walked du -h -d 1 / down the tree until I hit /var/snap/docker/. 556 GB hostage: 510 GB of unrotated container logs, 41 GB of image layers, 5 GB of old volumes. From a snap-Docker install I’d forgotten about — I actually use apt-Docker. Must have one-clicked snap-Docker from Ubuntu Software Center when I was new to this, then migrated to apt-Docker later without uninstalling the old one. Snap kept its data growing in the dark for a year.

Killed the logs, snap remove --purge docker, booted back to 24% used. Dev DB was fine — apt-Docker’s data was never touched.

Worth saying: the scariest disk-full crashes come from software you stopped using. Active processes get attention; idle ones rot and run up the bill. Setting up Netdata to alert me at 80% so I never fix this from a recovery shell again. And: if your distro offers a snap version of dev tooling, don’t.

A morning planned for GamaHaus, spent on infrastructure hygiene. Done by 8 — two hours from broken machine to working one, with Claude on the side walking me through du, the snap-Docker quirk, and the cleanup. Coming from outside IT, that pairing is the leverage. Counts as progress — just the boring kind.