StarDrive on macOS: When Gatekeeper and TCC Team Up Against You

Hey, so yesterday I went down a small rabbit hole with StarDrive (app) from NimbusApps, and I figured I’d write it up before I forget the details. This wasn’t a big dramatic failure, just one of those quiet macOS security moments where the system smiles politely and refuses to cooperate.

I just wanted a clean file management tool. Something lightweight to reorganize a few external SSDs and archive some project folders. StarDrive looked straightforward enough. Downloaded the DMG, dragged it into Applications, launched it.

And macOS immediately hit me with:
“StarDrive can’t be opened because Apple cannot check it for malicious software.”

Classic Gatekeeper.

At first I did what I always do out of habit: double-click again. Same message. Then I right-clicked → Open, which usually triggers the override dialog. It did — I confirmed “Open” — and the app actually launched… for a split second. Then it quit. No crash dialog, nothing in the Dock. Just gone.

That’s when I realized this wasn’t just the usual first-launch block. It was either notarization-related or something about how the binary was signed.

I skimmed Apple’s explanation of Gatekeeper again just to make sure I wasn’t missing anything obvious:
https://support.apple.com/en-us/HT202491

Nothing surprising there. Sonoma (I’m on macOS 14.4, M2 Pro) is stricter than older versions, especially with downloaded apps that aren’t properly notarized.

My first mistake was assuming the override from System Settings would be enough. I went to System Settings → Privacy & Security, scrolled down, hit “Open Anyway.” It acknowledged the override. I launched again.

Same behavior. Quick flash, then silent exit.

So now I’m thinking either quarantine attributes are still attached, or the app is trying to access protected folders and failing before it even draws the main window.

I opened Terminal and checked the extended attributes:

xattr -l /Applications/StarDrive.app

Sure enough, com.apple.quarantine was present.

So I removed it:

xattr -dr com.apple.quarantine /Applications/StarDrive.app

Launched again.

This time it actually stayed open. Progress.

But here’s the twist: it couldn’t see half my drives. My external SSD mounted under /Volumes was visible, but my synced iCloud Drive folders weren’t. And dragging files from Desktop triggered a weird “Operation not permitted” error inside the app.

That’s when it clicked. It wasn’t crashing anymore — it simply didn’t have proper file access permissions.

Since Catalina, macOS treats Documents, Desktop, Downloads, iCloud Drive, and external volumes as protected locations. Apps need explicit user approval. Apple’s documentation on this is buried in developer material, but this page explains the model pretty clearly:
https://developer.apple.com/documentation/security/app_sandbox

Even if the tool isn’t sandboxed, TCC (Transparency, Consent, and Control) still enforces access prompts.

The problem? StarDrive never triggered the permission dialog. No popup asking for access to Desktop or Documents. It just failed silently.

That was my second wrong assumption — that macOS would prompt automatically.

What actually worked was this: I went to
System Settings → Privacy & Security → Files and Folders

StarDrive wasn’t listed. Which means it had never successfully requested access.

So I reset its TCC permissions manually using:

tccutil reset All com.nimbusapps.stardrive

(You can find the bundle identifier with mdls or by checking the Info.plist.)

Then I launched the app from Terminal instead of Finder:

/Applications/StarDrive.app/Contents/MacOS/StarDrive

This time, macOS immediately prompted for Desktop access. I granted it. Then Documents. Granted again.

After that, everything worked. Drag-and-drop fine. External volumes visible. iCloud folders accessible.

I found this page useful while double-checking some macOS file system behavior around third-party utilities:
https://carwallpaper.xyz/file-management/96939-stardrive.html

It reminded me that file managers often bump into privacy restrictions in subtle ways.

For reference, if someone prefers App Store builds (less friction with notarization), you can usually check for official listings here:
https://apps.apple.com/us/search?term=StarDrive

App Store versions tend to behave more predictably with permissions because they’re sandboxed and properly signed from the start.

Anyway, what I initially thought was “broken app” turned out to be a layered security interaction:

1. Gatekeeper blocked it.
2. Quarantine attribute prevented stable launch.
3. TCC permissions blocked file access silently.

Once those were handled in the right order, the tool behaved exactly as expected.

If I were setting it up fresh, here’s the short checklist I’d follow:

• After download, remove quarantine if necessary (xattr -dr).
• Launch once from Terminal to surface permission prompts.
• Check Privacy & Security → Files and Folders immediately.
• Confirm architecture matches your Mac (especially on Apple Silicon).

That’s it. No voodoo.

The funny part is the actual file reorganization took maybe fifteen minutes. The security dance took an hour. But to be fair, macOS is doing its job. It’s just not very chatty about it.

NimbusApps didn’t do anything outrageous here; this is just the reality of distributing outside the App Store in 2024–2025. If an app isn’t fully notarized and tested against the latest macOS privacy model, users hit friction.

Now that it’s set up, StarDrive is stable and quick. Transfers are smooth, indexing is fast, no weird background CPU spikes. It’s exactly what I wanted from the start — just needed the right sequence to get there.

Anyway, if you run into the same “can’t be opened” + silent file access issue, it’s almost certainly Gatekeeper + TCC stacking together. Once you clear both layers properly, it behaves.

Hope that saves you an hour.