Hey,
So yesterday I ended up tinkering with File Read Test (app) from OrchardKit, and it turned into one of those “this should take five minutes” situations that quietly eats half an evening. I only wanted to run a quick disk read benchmark on my MacBook Pro (M1 Pro, macOS Sonoma 14.4) — nothing fancy, just verify whether an external SSD was behaving normally. The tool looked perfect for that: small, simple, no installer drama. Or so I thought.
The weird part was that the app launched fine but couldn’t read anything outside its own folder. Every time I tried pointing it to the external drive or even to Documents, it threw a generic read error. No crash, no warning from macOS, just a quiet “failed to read file block” message. The interface stayed responsive, but the test never actually started.
At first I assumed it was the external drive. It’s a Samsung T7, and occasionally macOS mounts removable drives with odd permissions. So I disconnected it, remounted it, and even ran Disk Utility First Aid just to rule out filesystem weirdness. Everything came back clean. Finder could copy files without issues, and Terminal could read the same directories instantly.
So the drive clearly wasn’t the problem.
Next I assumed it was a bug in the app itself. Maybe File Read Test expected a specific directory structure or file size. I tried testing inside the Applications folder, then Downloads, then a random folder on the Desktop. Same result every time — the tool just refused to start a scan.
That’s when it started feeling suspiciously like a macOS permissions issue.
The odd thing was macOS never showed the usual permission dialog. Normally you get a prompt asking whether the app can access Documents or removable volumes. Nothing appeared. The app behaved like it already had permission, but the system clearly wasn’t letting it read.
I went into System Settings → Privacy & Security → Files and Folders, expecting to see File Read Test listed there.
It wasn’t.
That’s when I remembered how macOS sometimes handles sandboxed-style access even for unsigned apps. If the app fails before triggering the permission request, it never gets listed. So you end up stuck in a weird in-between state.
Apple actually explains the file access model pretty well here:
https://support.apple.com/guide/security/controlling-app-access-to-files-secddd1d86a6/web
That description matched exactly what I was seeing — silent denial instead of a clear prompt.
My next attempt was the obvious heavy-handed fix: I granted Full Disk Access to the app under Privacy & Security. Restarted it, pointed it to the external SSD, and hit Start.
Still failed.
That one annoyed me more than it should have. Full Disk Access usually bulldozes through permission issues, but here it didn’t make any difference.
At that point I started suspecting quarantine flags again. OrchardKit builds are often unsigned or minimally signed, and macOS treats them cautiously even after you approve the first launch. The app had opened normally, so Gatekeeper didn’t look like the issue — but I’ve learned not to trust first impressions with macOS security.
While digging around, I found this page useful while sorting out the macOS-specific behavior:
https://spaceinnonxt.com/file-management/61882-file-read-test.html
It mentioned that the tool sometimes fails to access removable volumes if the bundle still has quarantine metadata. That lined up suspiciously well with what I was seeing.
So I checked:
xattr -l /Applications/File\ Read\ Test.app
Sure enough, there it was:
com.apple.quarantine
So macOS was still treating the app as partially untrusted even though it launched.
The fix turned out to be simple:
xattr -dr com.apple.quarantine /Applications/File\ Read\ Test.app
After that, everything started working immediately.
Same external SSD, same folder, same files — but now the read test started instantly and throughput numbers appeared like they should have from the beginning.
No restart required, no extra permissions, nothing else.
Just remove quarantine and go.
Once it worked, performance looked exactly right. Sequential reads hovered around 920 MB/s, which is normal for that drive over USB-C. CPU usage stayed low, maybe 4–5%, and the interface updated smoothly. So the app itself was fine all along — macOS just kept it on a short leash.
If you want the official explanation for this kind of behavior, Apple’s Gatekeeper notes are actually relevant even when apps appear to launch normally:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac
I also checked whether there’s a signed release floating around somewhere:
Didn’t see anything official, which probably explains why quarantine comes into play.
If I were installing File Read Test again from scratch, I’d just do this immediately:
- Copy the app to Applications
- Remove quarantine with
xattr -dr com.apple.quarantine - Launch once and test a local folder
- Then test external drives
That would have saved me a solid hour.
Funny thing is nothing ever crashed, and the interface looked completely normal. The tool just quietly failed to read anything, which is the most misleading failure mode possible. You assume the software is broken when it’s really macOS security doing its thing behind the scenes.
Anyway, once you clear that hurdle, File Read Test behaves exactly how you'd expect. Lightweight, fast, and useful — classic OrchardKit style. It just needs a small nudge before macOS fully trusts it.