I spent my Sunday afternoon in a battle of wits with Backup and Sync (app). If you’ve been on macOS for a while, you know the specific kind of dread that sets in when a status icon just spins indefinitely. No error message. No "crash to desktop." Just a quiet, polite refusal to actually do the one job it was designed for.
My goal was straightforward: I had about 40GB of project files—mostly high-res assets and documentation—that needed to be mirrored to the cloud. I’ve used this tool for years without much fuss, but after the latest Sequoia update, the relationship turned sour. I’d toggle the sync on, the little arrows would start chasing each other, and then... nothing. Three hours later, "Calculating..." was still the only feedback I had.
The Dead Ends
My first thought was that the database was just bloated. I did the usual dance: disconnected the account, cleared the local cache folders, and signed back in. It’s the "turn it off and on again" of the cloud storage world.
Result: The app spent another hour "Checking for changes" before settling back into its favorite "Preparing" state. Total waste of time.
Next, I went down the permissions rabbit hole. Apple has been tightening the screws on Full Disk Access with every OS iteration. I figured the tool was trying to read my files but was being silently ghosted by the system’s security layer. I went into System Settings > Privacy & Security > Full Disk Access and toggled everything off and on. I even checked the Official Apple Support page on Privacy Permissions to see if there was a new "feature" I missed.
Result: Still spinning. The app had the rights, but apparently not the will.
The Breakthrough
I started looking for logs—real ones, not the sanitized stuff in the UI. While digging through the Console app, I noticed a string of "FileSystemEvent" errors. It turned out the app was choking on a specific hidden folder created by a different dev tool. Basically, the sync engine was hitting a symbolic link it couldn't resolve and just... gave up without telling anyone why.
I found a mention of this specific interaction on a community board hosted by MacAppBox, which led me to a workaround involving the way macOS handles APFS snapshots. I bookmarked this resource on Backup and Sync for macOS because it explained that the sync stalls often happen when the local "helper" service loses its place in the file tree after a system migration.
What finally worked wasn't a setting in the app at all. It was a three-step manual reset:
I had to force-quit the cloudd and fileproviderd processes in Activity Monitor.
I moved the app to the Trash, but (and this is the key) I didn't just reinstall it from a DMG.
I grabbed the latest build directly from the official download source to ensure the binaries were properly notarized for the M-series architecture.
Once I relaunched the fresh build, it asked for permissions again. I granted them, pointed it to the folder, and within ninety seconds, the "Calculating" message vanished and the actual upload began. It seems the older installation had a "dirty" registration with the macOS File Provider framework.
Lessons Learned (The Hard Way)
If I had to do this again, I wouldn't bother with the internal "Disconnect Account" button. It’s too polite. When a sync engine hangs on a Mac, the problem is almost always at the intersection of the File Provider API and the system’s security attributes.
If you're stuck in a similar loop, check your Gatekeeper and Notarization status via the Terminal if you're comfortable with it. Sometimes the OS revokes the "trust" of a background helper after an update, and the app just sits there waiting for a permission prompt that never comes.
The tool is currently humming along, and my 40GB of data is finally safe. Now, if I can just find where I left my actual Sunday afternoon, I'll be all set.
Top comments (0)