My Mac Froze Every Time I Tried to Upload a File. Here's What Fixed It.

Posted by Michael S. on March 23, 2026

Tonight I finally spent some time chasing down a problem that's been driving me crazy for the past few months, nay, years: every time I hit "Upload" or "Attach" in any app on my MacBook Pro, the whole thing would lock up. Sometimes five seconds, sometimes five minutes. Clicking the upload button and staring at a frozen screen while nothing happens is one of the most maddening things a computer can do to you. Especially when you're on a deadline or in an interview/meeting.

I dug into this with Gemini and we figured out it was actually two separate problems stacked on top of each other. The first culprit was my Seagate Backup Plus Drive. Mechanical hard drives spin down their platters when they're not actively being used to save power. That's fine, except macOS has a fun behavior: when you open any file picker dialog (the upload window, Save As, Open, etc.), it sends a wake-up signal to every connected drive to read its status.

So the 5+ second freeze every time I tried to upload something? That was macOS literally waiting for the physical platters inside my external drive to spin back up to speed before it would let me interact with the upload window. The system just sits there until every mounted volume responds.

Ejecting the drive made the long freezes stop. But then something else appeared.

Part 2: The Corrupt Launch Services Database

After ejecting the drive, the issue changed. Pressing Cmd+S or Cmd+O in Chrome did absolutely nothing. Clicking "Files from Computer" in Dropbox just timed out without ever showing Finder. The upload dialog wasn't slow anymore. It simply refused to open.

I pulled up the logs and found that openAndSavePanelService, the background process macOS uses to draw file picker dialogs, was in a complete death loop. It was spitting out this error multiple times per second:

Error: Unexpected bundle class 16 declaring type com.serverauditor.ppk

com.serverauditor.ppk is a file association for PuTTY Private Key files (.ppk), registered by an SSH client app called ServerAuditor (now rebranded as Termius). macOS maintains a database called the Launch Services database that maps file types to the apps that can open them. When you hit "Upload," macOS queries this database to figure out what file types to show in the dialog. It hit a severely corrupted entry for this .ppk file type and completely choked.

The Fix

Flush and rebuild the entire Launch Services database from scratch:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user

Then restart Finder:

killall Finder

This helped a lot. The upload dialog came back in Firefox, and it was noticeably faster. But it wasn't perfect yet.

Part 3: A Ghost Favorite in the Sidebar

Even after the Launch Services rebuild, the dialog was still sluggish. Digging through the logs again, I found the file picker was throwing NSCocoaErrorDomain Code=4 (File Not Found) errors every time it tried to draw the sidebar. A folder called "HandL" was pinned in the Finder sidebar, pointing to /Volumes/10TB_1/HandL/, a location on a disconnected drive. Every time the upload dialog opened, it tried to resolve that path, waited for the connection to time out, and only then continued.

Removing the broken favorite from the Finder sidebar helped. Things got a bit faster, but there was still something dragging.

Part 4: Cloud Drive Sync Conflicts

The last piece. The system had active File Provider extensions for iCloud, Google Drive, and OneDrive. When the dialog launched, it asked each of these cloud services for their status to populate the sidebar. iCloud's extension was reporting errors and getting stuck in a retry loop, creating a traffic jam that blocked the dialog from loading.

Closing OneDrive (which has a known history of hanging macOS File Provider operations) helped clear this bottleneck. The dialog was opening much faster after that, at least in Firefox.

Where It Stands Now

Firefox is fully fixed. Upload dialogs open immediately. But Chrome is still broken: clicking "Upload" or pressing Cmd+S does nothing. No freeze, no error, just... nothing happens. It's like Chrome's connection to the file picker got permanently severed and the Launch Services rebuild didn't bring it back.

I'll probably just live with it. Firefox handles uploads fine, and I'm not spending another night chasing down Chrome-specific file picker bugs. Sometimes the right move is to accept a 90% fix and move on.

If You're Hitting This

If your Mac freezes or hangs when you try to upload files, save files, or open files in any app:

  1. Check for external drives. Eject any mechanical (HDD) drives and see if the freeze goes away. If it does, that's your answer: the drive's spin-up time is blocking the file picker.
  2. Check the logs. Open Console.app, filter for openAndSavePanelService, and look for error messages. If you see something about "Unexpected bundle class" and a specific file type, your Launch Services database is corrupt.
  3. Rebuild Launch Services. Run the lsregister command above, restart Finder, and test again. This won't delete any files or settings. It just forces macOS to re-scan every app and rebuild its file-type-to-app mapping from scratch.
  4. Check your Finder sidebar. Look for any favorites pointing to disconnected drives or nonexistent paths. The file picker draws the sidebar every time it opens, and broken favorites force it to wait for a timeout on each one.
  5. Quit cloud sync apps. If you're running OneDrive, Google Drive, or iCloud Drive, try quitting them. Their File Provider extensions populate the sidebar, and if any of them are in an error state, they can block the dialog from loading.
  6. Fix System Settings if it looks empty. One side effect of wiping the Launch Services database while the system is running: System Settings may appear empty, with most preference panes (Wi-Fi, Bluetooth, Privacy & Security, etc.) missing. On modern macOS (Ventura and later), those panes are implemented as App Extensions (.appex) that System Settings discovers through Launch Services. If the database is gone, it can't find them. You don't need to restart the whole computer. Re-run lsregister with -kill -seed to wipe and immediately reseed the database: 
    /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -seed -r -f -domain local -domain system -domain user
killall "System Settings"
open -a "System Settings"
    This should bring back the missing preference panes without a full reboot. If it doesn't, a restart should do it.

Enjoyed this post?

Get notified when I publish something new. No spam, unsubscribe anytime.

← Screen and Webcam Recording I Never Have to Think About Building BannerSweep →