Issue when creating Bookmark with security scope on macOS 26 RC

With the RC version of macOS 26, an issue persists when you try to create a bookmark with security scope for the root folder "/". This leads to an error "The file couldn’t be opened.". However, you can create bookmark for /Applications, /System, /Users...

This is quite annoying for one of my app because a user can create a cartography of his disk usage, and the access to the root folder "/" is the only way to do so!

Is there a workaround?

PS: reported the issue with ID FB20186406

let openPanel = NSOpenPanel()
openPanel.canChooseDirectories = true
openPanel.canChooseFiles = false
        
openPanel.beginSheetModal(for: self.view.window!) { (result) in
            
    guard result == .OK, let folderURL = openPanel.url else {
        return
    }

    openPanel.close()

    do {
        let data = try folderURL.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil)
            print("Bookmark data was created for \(folderURL.path)")
     } catch (let error) {
            print("Error creating bookmark for \(folderURL.path), with error: \(error.localizedDescription)")
     }

}
Answered by DTS Engineer in 857474022

With the RC version of macOS 26, an issue persists when you try to create a bookmark with security scope for the root folder "/". This leads to an error "The file couldn’t be opened.".

Yes. This is a known issue (r.157722315) that was introduced as part of fixing a bookmark-related security bug (r.151029665). Note that it affects the root directory of all file systems, not just "/". Fixing the issue is a very high priority, but it probably won't be possible to fix it for 26.0.

However, you can create bookmarks for /Applications, /System, /Users...

Yes. The issue is specifically tied to the root directory of the file system, which is why those other directories work fine.

This is quite annoying for one of my apps because a user can create a cartography of his disk usage, and the access to the root folder "/" is the only way to do so! Is there a workaround?

It won't be perfect, but I think this would work, at least for "/". To start with:

  1. Have the user select "/" as usual.

  2. Create a security-scoped bookmark for every object in "/".

Then, for future app runs:

  1. Resolve your bookmarks from #2 as usual.

  2. Directly read the contents of "/" (without asking the user)*, then compare those contents with #1.

  3. If 1 & 2 agree, then the contents haven't changed, and you can work with those subdirectories as usual.

  4. If 1 & 2 disagree, then tell the user they need to select "/" again and start the process all over again.

In practice, I think the contents of "/" are stable enough** that you'll rarely, if ever, need to do #4, so for most users, this will "just work".

*This (#2) works because the app sandbox actually has an extension that gives you read access to "/". Your app can't read below "/", but it can read the contents of "/" without user approval. Unfortunately, this also means that this won't work on other volumes.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

With the RC version of macOS 26, an issue persists when you try to create a bookmark with security scope for the root folder "/". This leads to an error "The file couldn’t be opened.".

Yes. This is a known issue (r.157722315) that was introduced as part of fixing a bookmark-related security bug (r.151029665). Note that it affects the root directory of all file systems, not just "/". Fixing the issue is a very high priority, but it probably won't be possible to fix it for 26.0.

However, you can create bookmarks for /Applications, /System, /Users...

Yes. The issue is specifically tied to the root directory of the file system, which is why those other directories work fine.

This is quite annoying for one of my apps because a user can create a cartography of his disk usage, and the access to the root folder "/" is the only way to do so! Is there a workaround?

It won't be perfect, but I think this would work, at least for "/". To start with:

  1. Have the user select "/" as usual.

  2. Create a security-scoped bookmark for every object in "/".

Then, for future app runs:

  1. Resolve your bookmarks from #2 as usual.

  2. Directly read the contents of "/" (without asking the user)*, then compare those contents with #1.

  3. If 1 & 2 agree, then the contents haven't changed, and you can work with those subdirectories as usual.

  4. If 1 & 2 disagree, then tell the user they need to select "/" again and start the process all over again.

In practice, I think the contents of "/" are stable enough** that you'll rarely, if ever, need to do #4, so for most users, this will "just work".

*This (#2) works because the app sandbox actually has an extension that gives you read access to "/". Your app can't read below "/", but it can read the contents of "/" without user approval. Unfortunately, this also means that this won't work on other volumes.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Accepted Answer

Thanks for your detailed answer, and your workaround. I hope you'll find a way to fix this issue ASAP 🙏

are we actually talking about the same bug though? Coe 256 seems to be an issue only for root drive of exFAT. But I can get a secure bookmark of a root drive of HFS

First off, on the bug front, these issues should be resolved in macOS 26.1, which we released to beta last week (25B5042k). Please test on that beta, and if you find any problem, file a new bug and post the bug number back here.

Are we actually talking about the same bug though?

Yes, I believe so.

Coe 256 seems to be an issue only for the root drive of exFAT.

The issue here was actually introduced as part of a security fix (r.151029665) and it affected exFAT, some SMB mounts, and the "/" AFPS mount. In both cases, the high-level issue is the same (basically, "stat" wasn't returning what it expected), but the underlying cause was different. In the case of exFAT, the file system is basically “too simple", so it's basically returning a synthetic ("invented") value because the file system doesn't really have an alternative it can provide. In the case of APFS, the issue is that the way that "data" and "system" volumes are merged means that you can get different values for the "same" object, depending on exactly how you "ask" the question.

That leads to...

But I can get a secure bookmark of a root drive of HFS

As far as macOS is concerned, HFS+ basically defined the system expectations of how a file system is "supposed" to work, which APFS then "followed". Note that the issue above isn't actually caused by APFS "itself", but by the unusual situation created by first splitting "the system" into two volumes, then partially "merging" them together.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Issue when creating Bookmark with security scope on macOS 26 RC
 
 
Q