Title: Security-scoped folder bookmarks after rename or Trash: APFS vs exFAT/FAT32

Question

Created 17h

Replies 3

Boosts 0

Participants 2

I’m developing a sandboxed macOS app that needs persistent, read-only access to a user-selected folder. We are observing different behaviour between APFS and FAT32/exFAT after renaming the folder or moving it to Trash.

The main problem is that the app can still track the folder while running, but cannot reliably restore the connection or identify its location after relaunch.

Environment

macOS 27.0.1 (26A434)
Xcode 27.1 (27A9269)
App Sandbox and user-selected file access enabled
Folder selection through SwiftUI fileImporter
Bookmark creation: .withSecurityScope and .securityScopeAllowOnlyReadAccess
Bookmark resolution: .withSecurityScope

The selected items are ordinary folders, not volume roots.

Filesystem comparison

APFS: the tested workflows appear to work as expected, including restoration after relaunch.
exFAT: we have reproduced both bookmark renewal failure after a rename and loss of the “in Trash” classification after relaunch.
FAT32: we have observed automatic bookmark renewal failures after a rename. The detailed debugger trace and Trash reproduction below were collected specifically on exFAT.

Rename reproduction

Select a folder through the system picker.
Create and persist a read-only security-scoped bookmark.
Resolve the bookmark and start accessing the resolved URL.
Retain that URL and keep its security scope active throughout monitoring.
Rename the folder in Finder while the app remains running.
Attempt to create an updated bookmark for the same folder.

The monitor retains an O_EVTONLY directory descriptor. After the rename, F_GETPATH returns the correct new pathname, and runtime identity checks still match the monitored folder.

However, creating a bookmark using a URL reconstructed from that new pathname fails. Calling startAccessingSecurityScopedResource() on the reconstructed URL returns false, while the original resolved URL’s scope remains active.

The bookmark creation call uses:

url.bookmarkData(options: [.withSecurityScope, .securityScopeAllowOnlyReadAccess], includingResourceValuesForKeys: nil, relativeTo: nil)

Exact failure measured on exFAT

LLDB shows that Foundation’s internal open():

Receives the correct new pathname.
Uses flags 0, meaning O_RDONLY.
Immediately returns -1.
Sets errno to 1, EPERM, read immediately on the same thread.

The correlated Foundation error reports:

NSCocoaErrorDomain
Code 256
Could not open() the item: [1: Operation not permitted]

This is a failed read-only open during bookmark creation. We have not established which policy causes the EPERM.

A log stream filtered for com.apple.sandbox.reporting / violation produced no report during reproduction. We understand that this does not exclude sandbox involvement.

We also tested a native CFURL file reference retained from before the rename. It continued to follow the folder and match its identity, but security-scoped bookmark creation from that reference also failed.

Reselection works, but requires user intervention

Selecting the same renamed folder again through fileImporter allows creation of a new bookmark. That bookmark resolves, is not stale, and restores access after relaunch.

Without reselection before quitting, the previously saved bookmark does not restore access to the renamed folder on the next launch. The app reports it as unavailable.

Separate Trash reproduction on exFAT

Move the monitored folder to Trash using Finder while the app is running.
The app correctly identifies the folder as being in Trash.
Quit the app, leaving the folder in Trash.
Relaunch: the app reports the folder as unavailable.

The folder remains in Trash on the same exFAT volume. It has not been restored or permanently deleted.

We also encountered failures when inspecting the Trash relationship using FileManager.getRelationship(_:of:in:toItemAt:) with .trashDirectory. We have not established whether these observations share the cause of the rename failure.

Questions

What is the supported public-API approach to preserve security-scoped folder access across an external rename on exFAT/FAT32, including after relaunch?
What should bookmark resolution return for a folder moved to Trash, and how should a sandboxed app distinguish that condition from an unavailable resource after relaunch?
Are these expected filesystem limitations, problems in our API usage, or behaviours that should be reported as macOS bugs? What additional diagnostics would help distinguish them?

Ideally, the solution would preserve the original folder authorization without requiring repeated reselection or access to the parent directory or entire volume.

I have read Accessing files from the macOS App Sandbox. I also found this discussion of bookmark failures involving exFAT, but it concerns volume roots and an earlier macOS release, so I’m not assuming it explains our case.

Answer 1

Etresoft OP

16h

Reselection works, but requires user intervention

This is the only part that matters and the correct resolution.

Any questions you have regarding API behaviour or support status are irrelevant, as are any answers. The operating system is under constant development and system behaviour with respect to these bleeding edge cases can change from day-to-day.

Security-scoped bookmarks should never be considered persistent or stable. There's literally a function for telling you when a valid security-scoped bookmark is stale. Pretty much all the other functions are useful for identifying when security-scoped bookmarks aren't valid.

Security-scoped bookmarks should be considered a user convenience. They save the user from having to re-select files and folders in many cases. As a 3rd party developer, you should save the persisted URL separately so you can assist the user in re-establishing access when, not if, the security-scoped bookmark resolution fails.

Answer 2

kain84 OP

16h

Thanks. We already implemented explicit reselection as a recovery path, and confirmed that it restores access after relaunch.

The concern is how frequently that recovery becomes necessary. In our tests, an ordinary external folder rename reproduces the problem on FAT32/exFAT, while the same workflow appears to work on APFS.

While the app remains running, its existing file descriptor still tracks the renamed folder. On exFAT, we traced creation of the replacement security-scoped bookmark to an open() failure with EPERM. Reselecting that same folder through the system picker allows bookmark creation and subsequent access after relaunch.

Saving the last known URL could help guide the user through recovery, but would not itself restore authorization or establish that a folder subsequently found at that path is the original resource.

We agree that bookmark failures need a recovery path. The remaining question is whether repeated reselection after ordinary renames is unavoidable under these constraints: a sandboxed app, public APIs, and authorization limited to the selected folder.

Have you encountered this specific FAT32/exFAT rename scenario, and do you know an approach that avoids repeated reselection?

Answer 3

Etresoft OP

14h

The concern is how frequently that recovery becomes necessary. In our tests, an ordinary external folder rename reproduces the problem on FAT32/exFAT, while the same workflow appears to work on APFS.

If it was me, then I wouldn't worry about it. Foreign file systems are always problematic.

While the app remains running, its existing file descriptor still tracks the renamed folder. On exFAT, we traced creation of the replacement security-scoped bookmark to an open() failure with EPERM. Reselecting that same folder through the system picker allows bookmark creation and subsequent access after relaunch.

Two questions:

What are you doing with this folder? It sounds like you're keeping a file descriptor open on it for a long time. That's risky.
Ideally, you're going to wrap each access in a file coordination block. In theory, that should guard against some level of external manipulation. Are you doing that?

(Note: my own file coordination experience is strictly theoretical. I've never seen it do anything really.)

At a fundamental level, if you're app is saving a folder URL and the user trashes, renames, or moves the folder, that's a user problem. Your app should have no expectation of recovery. I realize end users may have different expectations. They do tend towards cognitive dissonance.

Saving the last known URL could help guide the user through recovery, but would not itself restore authorization or establish that a folder subsequently found at that path is the original resource.

No. It wouldn't. It's more for developer and user convenience.

Also, it's important to note that you're specifically talking about folders here, correct? Folders aren't completely supported by security-scoped bookmarks, even on APFS. Perhaps you just haven't found the gaps yet. 😄

The remaining question is whether repeated reselection after ordinary renames is unavoidable under these constraints: a sandboxed app, public APIs, and authorization limited to the selected folder.

Have you encountered this specific FAT32/exFAT rename scenario, and do you know an approach that avoids repeated reselection?

Usually the best solution is an app design that steers the user towards manual selection as part of a normal app flow. Security-scoped bookmarks are fundamentally about accessing files outside of your sandbox. Avoid that at all costs.

There's another important plot point here with respect to "support", public APIs, and authorization. None of these are designed to facilitate access. They're specifically designed to block access. The barriers they introduce aren't side effects, they're design goals.

If you haven't already heard, Full Disk Access is next on the chopping block. Even if you don't use or access this feature, the changes that Apple is going to implement will likely require some coding changes. So my advice is not to put much effort into any feature that depends on security-scoped bookmarks as that it likely to be a source of user annoyance. Try to structure your app around documents and/or data in your sandbox.