By Glenn Fleishman

March 25, 2024 4:46 PM PT

A disk so full, it couldn’t be restored

My younger child’s MacBook Pro was unsalvageably full. Only a complete wipe would suffice—and then Time Machine failed us.

I love my children, but they do sometimes forget what I do for a living: answer questions and write books about the most troubling problems people have with their Macs, iPhones, and iPads. But when something goes truly wrong, they suddenly remember, “Hey, Dad might know how to fix it!”

So it happened that my younger asked for my help when their M2 MacBook Pro’s storage filled up while they were downloading a (legitimate, purchased) game using Steam. No problem! I could just empty the trash. Nope, they tried that. Well, what about finding some caches and…nope. I could just go into the Terminal and…ok, that didn’t work either.

Turned out, my kid had managed a neat trick, though they were not alone: they had filled macOS’s startup volume storage so full that the operating system was incapable of deleting files in any fashion. Instead of halting the massive Steam download when the drive became disastrously full, macOS continued to write files until there was just 41K free on the drive.

I don’t know quite what happened. They didn’t realize their terabyte SSD was quite so filled, as they keep most of their useful files in the cloud. It was likely…er, perfectly legitimate video files. Yeah, I’m sure there was no problem with the copyright there. But they weren’t concerned about retaining them. They just wanted their computer to work again!

I have a theory about what happened. Due to our gigabit Internet connection and the size of the Steam file, macOS outstripped its ability to throttle filling storage because it was also making a local Time Machine snapshot. The Steam file appeared monolithic to me—one giant file—but clearly not to Time Machine. macOS keeps these snapshots to provide local backups for the last 24 hours even while it’s copying files to an external or networked Time Machine destination. I don’t think macOS tracks these snapshots well, and I suspect a collision of live files on disk with the specially created snapshots.

I went through a succession of file deletion attempts, relying on my own knowledge and searching for similar situations in online forums:

• Empty Trash: Emptying the Trash via the Finder a big “no” (File > Empty Trash). “The operation can’t be completed because the disk is full.” Yes, macOS, I’m already aware of this.
• Terminal: While Terminal would launch, using the standard Unix rm command resulted in a similar error: “No space left on device.” All rm alternatives, like using the find command to search for very large unneeded files and adding the -exec option to run the rm command, failed too. Terminal was a bust.
• Disk Utility: Disk Utility shows Time Machine snapshots on APFS startup volumes, and you can typically select and delete these snapshots, which occupy only the amount of storage space required to contain the differences from the previous snapshot. That failed with a “no space left” error as well.

It was time to restart to see if it would clear caches. Unfortunately, restarting left the Mac unable to start up at all. No matter what I tried, it would reach about halfway through the progress bar before failing.

I shifted to recoveryOS, Apple’s somewhat new name for the special disk partition in macOS that lets you run operations on the main startup volume while it’s not mounted, including Disk Utility repairs and reinstallation. From there, I hit the wall as well, as Terminal commands continued to fail with the same error.

I restarted again to access the Apple silicon Share Disk option to mount my kid’s drive on one of my Macs, hoping that over Samba (the disk-sharing protocol), I’d be able to force a deletion. No dice.

At this point, I shifted to stronger medicine. I had a series of Time Machine backups of their drive, including one from the previous evening, and they weren’t terribly concerned about losing data, as they have most things they care about in some kind of cloud storage. Here’s where things went pear-shaped in an entirely different direction.

First, I erased the drive and used macOS Recovery to reinstall Ventura, the native system with which the MacBook Pro had shipped. I then used Migration Assistant at macOS startup to access the networked Time Machine backup. In choosing what files to restore, I unchecked a number to ensure there would be plenty of storage. My kid had a lot of things they could delete, too, they said, and I could give them the Time Machine backup as a mountable drive if they needed access to files that weren’t restored later.

Halfway through, Ventura stalled and wouldn’t resume. I decided to upgrade to Sonoma, the version of macOS that was running at the time the Mac filled its drive. That worked fine—but the upgrade took the Mac to version 14.4, and my kid had had 14.3.1 installed. When I attempted to restore directly at startup, I was told the version different wouldn’t allow it. Now what?

I completed a basic Sonoma user account setup and then ran Migration Assistant. It found the networked Mac on which I manage Time Machine backups and recognized it. However, it refused to mount my child’s backup volume. No matter what I did, “Mount failed” appeared. Digging around in forums, I found that Sonoma has broken the SMB/Samba-based networking mount procedure for Time Machine restores, and no one had found a solution. This appears to still be the case in 14.4.

Because my younger only needed their apps and certain files, we both gave up at that point. I copied their Time Machine backup onto an external 1 TB SSD through this straightforward method:

1. On my Mac, which handles networked backups, I double-clicked the disk image for their computer and then entered their Time Machine volume password. (I always set a networked password for Time Machine volumes.)
2. I found the disk icon with the latest timestamp and copied this to an empty 1 TB drive.
3. Ejecting it from my Mac, I connected it to their stub account on their MacBook Pro and copied over the necessary files, including the contents of most of their home directory folders, excluding some large downloads and unneeded (ahem) video files.

I gave them the drive so that they could restore anything else they needed if it were missing, and we’ll probably keep it on hand for a while to make sure nothing is missing.

This put them back in business, but I missed two tricks that I could have tried to make things easier:

• I could have unmounted the Time Machine backup drive from my computer I use for other computers on the network. (I have a separate drive I use for local Time Machine backups from that computer’s startup volume.) Then I could have connected that directly to my kid’s computer and it likely would have become available as a Migration Assistant starting point.
• Failing that, I could have copied the virtual disk from the Time Machine disk image I mounted on my Mac of their backup so that the external 1 TB drive I was transferring “looked” like a Mac source volume. I’m not sure if this would have worked, but I didn’t try it. Then, I could have potentially restored directly from it using Migration Assistant.

I’m sorry I didn’t try the above, but I had already invested a cumulative couple of hours of my time and over a day of effort while my kid was unconcerned about a perfect directory-to-directory recovery.

I hate to think what people without decades of Mac experience do when confronted with systemic, cascading failures like this when I felt helpless despite what I thought I knew and all the answers I searched for and found on forums.

[Glenn Fleishman is a Macworld contributor, Jeopardy champion, and serial Kickstarterer. He's currently working on the book How Comics Were Made.]

If you appreciate articles like this one, support us by becoming a Six Colors subscriber. Subscribers get access to an exclusive podcast, members-only stories, and a special community.