No, I don't see the same problem with a Apple-formatted external volume. If I re-format the same external drive as Mac OS Extended (HFS+) via Disk Utility the same operation involving the temporary file works without problems. If I re-format the external drive back to FAT32, the issue re-appears. I've also tried with different external drives and have various users reporting the issue. Thanks for your reply!

Thank you for the reply. It's really great that you're taking the time to also investigate such seemingly obscure issues and I found many of your post here really helpful! I've used the past couple of hours creating the an example project and filed a bug with all the details. I really hope that someone can make sense of it. I've filed it as FB9047017.

Thanks for your reply! I've tried both methods, unfortunately without success. The canonical path method did not resolve /System/Volumes/Data/Test/ to /Test/ and the string replacement results in error Domain=NSCocoaErrorDomain Code=260 "Scoped bookmarks can only be created for existing files or directories"

It's either from a URL that stems from an NSOpenPanel or the result of a drag and drop operation. var bookmarkData: Data? let openPanel = NSOpenPanel() openPanel.canChooseFiles = false openPanel.canChooseDirectories = true if openPanel.runModal() == NSApplication.ModalResponse.OK { guard let url = openPanel.urls.first else { return } do { bookmarkData = try url.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil) } catch { NSApplication.shared.presentError(error) } } Trying to resolve the successfully obtained bookmark via the aforementioned URL initializer fails: var isStale = false let url = try URL(resolvingBookmarkData: bookmarkData, options: .withSecurityScope, relativeTo: nil, bookmarkDataIsStale: &isStale) It's also possible to reproduce this issue with an example project I've created for a previously reported sandbox-related issue: https://github.com/fheidenreich/sandbox-fat32-rename Choose, e.g., /System/Volumes/Data/Test/ via the "Select..." button. Press "Create test file" to see the error occur. As some background: I've not randomly tried to break things, but got a report from a user of my app describing this issue. Apparently, migration assistant created a new folder /System/Volumes/Data/Data/ when moving to Monterey where all the files reside which he tries to edit using my app. It's of course possible to move the data to the User's folder, but I wanted to at least gather some understanding of the underlying issue and possibly prevent this from happening again. Thanks for your reply!

Yes, accessing the URL directly works — thanks for the workaround! I'd then need to add some extra machinery to store "per-session" security-scoped URLs that cannot be persisted using security-scoped bookmarks. FYI, NSDocumentController.noteNewRecentDocumentURL() also gives a sandbox error for the URL. Can you provide any details on the underlying reasons for this behavior? Is it also to be expected in other circumstances?

No. My earlier question wasn’t really intended as a workaround but rather as a diagnostic test. I’ve no idea what’s causing the underlying issue )-: OK, understood. Accessing the data volume directly in this way is somewhat unusual. Absolutely, and it's something I'd usually not do. However, as mentioned earlier: As some background: I've not randomly tried to break things, but got a report from a user of my app describing this issue. Apparently, migration assistant created a new folder /System/Volumes/Data/Data/ when moving to Monterey where all the files reside which he tries to edit using my app. So it's a real-life problem, the user who reported this issue loaded the files via drag and drop. In my tests I've dropped the files from a Finder window I've opened via Terminal.app open /System/Volumes/Data/Test. Dropping a folder to the location on the open panel also changes the folder. Didn't know that command-shift-G also works here :)

If you sent up a synthetic symbolic link to this directory, do you still have the problem when you navigate to it normally (that is, using /Test rather than /System/Volumes/Data/Test)? Yes, the problem persists also when using a synthetic symbolic link. NSOpenPanel.directoryURL points to /System/Volumes/Data/Test after choosing /Test. Thanks for pointing to synthetic symbolic links. I wasn't aware of the feature and learned something new today!

Many thanks for your help and guidance! I've reported this as FB9843248.