I also posted this as a comment on FB17772372, but reposting this here: As a workaround, it does seem that if I login to a GUI session as the root user (https://support.apple.com/en-us/102367) and enable my FSKit module as the root user in System Settings, then automount works (even from a regular user). Seems like some kind of “modules enabled as the logged in user” vs “modules enabled as the root user” discrepancy. As an extra note that's somewhat unrelated, it's a little odd how that despite this now working, FSClient.installedExtensions still can't see the enabled module (FB18398975) even when enabled as the root user, despite fskitd now seemingly being able to see it during an automount operation. It still just shows the 2 system modules.

Regarding the mount issue: Thanks for pointing me to that error. Testing this myself, it seems like that error is only appearing in Console when I use mount(8) (and oddly enough, the mount succeeds despite the error). When the disk just appears and DA tries to automount I don't see that error, which makes me think this is not the (only) issue. (The reason it appeared in the logs was that I was trying out different things before reproducing - you'll see that the timestamp there is a few seconds before the time I gave, which is probably when I tried using mount(8) manually instead.) In any case, when adding var maximumFileSize: UInt64 = UInt64.max to my sample FSVolume, the situation doesn't change and the automount still fails. It does silence the error when manually using mount(8), though. Regarding the issue of fskitd not "seeing" the extensions: Ruling out something easy/obvious, is your extension running out Xcode's directory or some other user owned hieararchy? What happens if you move the app/extension into /Applications and run it from there? I've tested the following configurations, and the issue occurred in all cases: Running from Xcode build directory, macOS 15.5 (24F74) (not VM) Running from a user-owned directory on a non-boot volume (which is actually a VM shared folder), macOS 15.6 (24G5054d) (in a VM) Moving the sample app from the VM shared folder to the /Applications directory (also removing it from original location), then opening it, then trying again After moving the sample app, restarting the (VM) Mac, then trying again Also don't think this matters, but in the VM test cases I used a notarized copy of the sample app archived from Xcode since I don't have the development provisioning profile setup for my VM's device identifier (and thus it was in release mode), and in the first case I simply used the debug build directly from Xcode.

For anyone following this who can't see FB17772372, I received a reply on my bug report stating that the issue should be fixed in macOS 15.6 beta (24G5054d). I tested this and probing now seems to work, although I'm still encountering issues at the mount stage when Disk Arb tries to automount. Based on my observations in Console it seems like it can't find the module, although mount(8) still works. I replied to the feedback with additional details.

I also encountered this permission issue when working with FSKit on physical external volume (e.g. a USB device). The workaround I'm using is to change the owner of the dev node to be the current user: sudo chown $(whoami) /dev/rdisk6s3 (where disk6s3 is your target disk) This probably isn't a great long-term solution but it at least got me able to test my module with a physical device. (Running mount as root didn't work for me either. It's as if it didn't know the FSKit module was there. My assumption was that enabling the module in Settings only enabled it for my user account, and root didn't have it enabled? I suppose based on @DTS Engineer 's suggestion to run mount as root, sudo mount not working is actually a bug though.)

Thanks for that. I asked over in the privacy/security section of the forums and the verdict seems to be that these types of properties don't get inherited because that's not how it works. However I was given the suggestion to possibly change the Java executable's Info.plist instead, although trying this didn't seem to successfully get Game Mode to activate (tested on macOS 15.5 (24F74)), unfortunately. (Is that expected behavior?) So looks like this won't work, as you thought. Though it is strange that Game Mode does work with apps like the Minecraft official launcher which use this architecture, which seems to imply there is some way this is done. I can't find a code-level way to implement this, but I do see that: If the "launcher" app is opened from Steam and then the launcher app opens the Java game, then fullscreening the Java game does activate Game Mode. So seems like children of Steam have some kind of special handling, though I'm not sure if that's the doing of Steam or the OS. If you change an app's bundle ID to that of the Minecraft launcher (com.mojang.minecraftlauncher) it also causes Game Mode to enable when the Java window is fullscreened. Since the code in a sample app I'm using to test this doesn't change, only the bundle identifier, it seems like this is done at the OS level. Although obviously pretending to be the official Minecraft launcher is not a possible solution in the real app. It seems like the system has special handling for at least the second case somehow since the behavior only changes based on the bundle identifier of the app. Is this type of behavior (inheriting the Game Mode support for the child process) accessible to other developers?

Thanks for that info and possible lead! Hmm, the approach of using our own copy of Java with a custom Info.plist seems to add a significant amount of complication and has several drawbacks for a relatively minor feature so I'm not sure it's actually realistic for our case. But lets say I want to investigate whether that angle works anyway. One thing I want to clarify is that you differentiated between the location of an Info.plist when the code is bundled versus when it is a standalone executable. My initial thought is that since a Java installation I have on hand is a bundle that clearly has a Info.plist file in its Contents directory, and the java executable is contained within that bundle, then the "code is bundled" rule should apply. But when I use otool to look at the relevant section of the java executable, I see content as well: $ otool -P /Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home/bin/java /Library/Java/JavaVirtualMachines/zulu-21.jdk/Contents/Home/bin/java: (__TEXT,__info_plist) section ... (Info.plist content here, different from the Info.plist in the bundle) Some clarifying questions I have are: Looking at the documentation it doesn't seem to follow the normal convention for a bundle? java is located in Contents/Home/bin/java. Does this matter for which Info.plist is used? In the bundle's information at Contents/Info.plist, the CFBundleExecutable listed is not the one I am concerned about (it is not java). Does this affect which Info.plist is relevant? In this case where both the bundle has an Info.plist file and an executable somewhere in it also has an __info_plist section, which one is used (or is some combination used)?

@DTS Engineer No worries, I'm sure this is a busy time for all of you. Filed FB17772372, sample project included.

@nikolajpognerebko For the not appearing in Finder issue, in my experiments I saw that if you've only implemented a stub attributes(_:of:) that doesn't return some of the attributes requested, the volume might not appear in Finder. For example right now I have an implementation that returns attributes for: uid gid mode flags fileID type size accessTime changeTime modifyTime birthTime linkCount parentID and my volume appears in Finder when I navigate to where I mounted it. If I remove some of the attributes (e.g. if I don't set modifyTime) then it no longer appears. (I'm not sure the minimum set of attributes you need to support for it to appear in Finder so you might be able to get away with not implementing some of the above.) Not sure if other things can cause this, but if you're using a dummy implementation for testing that doesn't fully implement this then this could be one thing to check.

but it would be polling, which seems inefficient I think this is what Disk Arbitration is for (see the documentation’s recommendation to use it and you may also find the archived documentation on it useful as well). The service itself still needs to launch before the disk mounts so that it can listen for these events, though. I think you could just use #3 and use Disk Arbitration to respond when your disk appears (and disappears, if you need to handle that) in an efficient way.

Both of these are policy decisions App Review will need to make, however, I will say that it's possible that #1 might be allowed Marking this as solved because App Review approved my app that uses SMAppService.daemon to run a sandboxed launch daemon, so at least in this context, this was allowed. 🎉

Thanks for the insights! I'm surprised to see that the relevant code is open-source. I'm also surprised, but pleased, to hear that my first workaround isn't guaranteed to be hopeless; I'll give it a try and see what App Review thinks. the "diskutil" command line tool Unfortunately, this didn't seem to get around the issue. I tried let process = Process() process.executableURL = URL(filePath: "/usr/sbin/diskutil") process.arguments = ["mount", "readOnly", diskBSDName] try? process.run() which had the expected behavior when App Sandbox was disabled but did not work when App Sandbox was enabled. It's certainly worth filing an enhancement request asking for the sandbox to handle this better. I filed FB16728800 and attached a sample project to it.