Thanks for the comprehensive answer! My file system is mounting a video container which contains RAW DNG images, so the volume is actually exposing these DNG files. I'm glad to say that mounting with "mount" command also works with passed security scope, when enabling "FSRequiresSecurityScopedPathURLResources". I was constantly trying to pass in a security scope bookmark through my client app, but in the end this option did it for me. If I may ask a follow up question, what do you think would be a preferred way to mount these files that my file system supports (they have ".mcraw" file extension) in Finder? Is having a client app that associates with this file extension okay? Which in turn calls the "mount" command internally. But that would cause some problems with App Sandbox, since I don't think it's possible to call "mount" with Sandbox enabled. That I think is the current limitation. Are there any plans to be able to do it with Sandbox in the future?

Actually, for now, I'm going to put the project on ice, since I can't get the satisfactory performance out of it. This project is actually just a rewrite of an existig project I did a while ago, but it used macFUSE and its kernel extension. To compare, for the same functionality, the macFUSE implementation uses about 40% of CPU, while the FSKit one uses between 100 and 150%. I tried squeezing the last drops of performace out of the FSKit one, but it seems I hit the ceiling. Unfortunately, I also can't seem FSVolumeKernelOffloadedIOOperations, since this is a virtual filesystem, without the underlying block device or similar (correct me if I'm wrong). Nevertheless, I fully support FSKit and the efforts behind it. If you're interested in the code, you can find it here: https://github.com/baso53/mcrawfs