LocalResizeImg (app) on macOS: when a simple utility won’t touch your files
I installed LocalResizeImg (app) on a Mac mini M1 running macOS Sonoma 14.4 because I needed something lightweight to batch-resize a few hundred product photos. Nothing fancy. Just drag a folder in, scale everything down to 1600px width, keep metadata intact, export.
NimbusApps had mentioned it as a clean, no-cloud image resizer. Sounded perfect.
Install was straightforward. I grabbed it from the Mac App Store search page:
https://apps.apple.com/us/search?term=LocalResizeImg
Launched fine. Clean interface. Drag-and-drop zone in the center.
And then it refused to process anything outside my Downloads folder.
What I wanted to do
All my images were stored in an external SSD under /Volumes/Media/ClientA/RawExports. I dragged that folder into the window.
The app showed the folder name. I hit “Start.”
Instant error:
“Cannot access selected directory.”
No crash. No beachball. Just a polite refusal.
At first I assumed I’d misread something — maybe it only works on local storage, maybe external drives are restricted. But that would be odd for a resizing tool.
First wrong assumption: it’s a bug
My initial reaction was to blame the utility. I force-quit it, relaunched, tried again. Same message.
Then I copied a handful of images to Desktop and tested those.
Worked perfectly.
So it wasn’t the resizing engine. It was file access.
Modern macOS is strict about sandboxing, especially for App Store apps. Apple’s own explanation of how file and folder permissions work is here:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchld5a35146/mac
The system doesn’t automatically grant recursive access to arbitrary volumes unless the app requests it properly.
LocalResizeImg had asked for access the first time I dragged a folder from Downloads. I clicked “Allow.” But it never asked when I dragged the external drive folder. Which meant it probably didn’t have permission at the sandbox level.
Second attempt: Full Disk Access (overkill)
I went to System Settings → Privacy & Security → Full Disk Access and added the tool manually.
Relaunched.
Tried again.
Same error.
This is where I realized Full Disk Access doesn’t always override sandbox-scoped bookmarks. If the app relies on security-scoped bookmarks created through user interaction, simply toggling Full Disk Access may not solve anything.
So I removed it from Full Disk Access again. That wasn’t the right layer.
The actual issue: volume-level permission
The external SSD was formatted APFS but mounted with a custom name and, importantly, had been previously used on another Mac. Ownership was ignored on the volume.
I checked with:
Get Info → Sharing & Permissions
My user had read/write access, but the “Ignore ownership on this volume” box was enabled.
That can confuse sandboxed apps. They rely on consistent POSIX permissions combined with user-scoped access tokens.
I disabled “Ignore ownership on this volume,” applied changes, then ejected and remounted the drive.
After that, I dragged the folder into the app again.
This time macOS prompted properly:
“LocalResizeImg would like to access files on ‘Media’.”
I clicked Allow.
And it worked. Instantly started processing 312 images without complaints.
Midway through debugging I saved this page because it framed similar macOS behavior around file access for creative utilities:
https://carwallpaper.xyz/graphics-and-design/66305-localresizeimg.html
It nudged me away from blaming the resizing logic and toward checking volume permissions on macOS systems instead.
Why this happens
App Store apps operate inside a sandbox. They don’t automatically get free roam over every mounted volume. Access is granted through user action (like dragging a folder) and stored as a security-scoped bookmark.
If the underlying volume permissions are inconsistent — especially with ownership ignored — the sandbox token doesn’t bind correctly. The app thinks it has access. The OS says it doesn’t.
Apple’s developer documentation on App Sandbox explains this architecture in detail:
https://developer.apple.com/documentation/security/app_sandbox
It’s not glamorous reading, but it clarifies why the behavior looks inconsistent from the outside.
What actually fixed it
The working sequence ended up being:
- Disable “Ignore ownership on this volume.”
- Ensure my macOS user has proper read/write rights.
- Remount the external SSD.
- Drag the folder into the app again to regenerate the access token.
After that, batch resizing ran smoothly. CPU hovered around 35–45% during processing. Memory stayed under 200 MB. No crashes. Metadata preserved correctly.
What I would do differently
If I had known from the start that this was a sandbox + volume permission issue, I wouldn’t have wasted time toggling Full Disk Access.
On modern macOS, when a tool can read files from one location but not another, it’s almost never the core functionality. It’s permissions — either privacy panel, volume ownership, or sandbox scope.
LocalResizeImg itself is stable. The resizing engine is fine. The failure point was the interaction between macOS security layers and an externally mounted drive.
Once I aligned the filesystem permissions with what the sandbox expected, everything behaved predictably.
Lesson learned: before blaming the utility, check how macOS sees the volume. On Apple Silicon machines especially, Sonoma enforces these boundaries very cleanly. And once you understand that pattern, troubleshooting becomes less about guessing and more about reading what the system is actually protecting.
Top comments (0)