Does anyone have any ideas how to get photos stored in the Files app to open IN the Files app Press and hold on the file of the relevant file type, Open With > Preview with Quick Look.

It’s a bug. I saw this before too (FB18398975). I was told it’s fixed in macOS 26 beta 6 (25A5338b), and in my tests this appears to be the case.

Also, not sure if the original poster's app is sandboxed, but if your app is sandboxed then it looks like the situation is potentially worse: It seems like if the reason the file was quarantined was that it was modified by a sandboxed app, Gatekeeper instead says that the file is damaged and can't be opened, and should be trashed (FB19623735) rather than the malware warning. In that feedback I list similar user-level steps: Install Microsoft Word and Apple Pages from the App Store. In Word, create a new document and save the .docx on your Desktop. In Finder, right click > Get Info on the Word document. Set Pages to open that specific Word document (do not set Pages to open all Word documents). Double click the file to open it. Then Gatekeeper tells you the file is damaged (both Word and Pages should be sandboxed apps since they're from the App Store). IMO that wording is even worse since it would imply to a typical user that the file is somehow corrupted... not that it might be dangerous. Then they might lose data if they try to mess with it or simply delete data that is perfectly fine. If an astute user notices that it happens after they set a file to open with your sandboxed app, it works once (say it starts out unquarantined), and then the system tells them it's damaged after any modifications are made, they're likely to blame your app, too, rather than the system's antimalware checks. For reference this is the wording of that alert: I get the security implications of having a file set to open with some arbitrary app (I mean, regardless of the file type, if it contains the contents of a script it could be dangerous if you open it with an unsandboxed script interpreter app installed on the system - if a sandboxed app could do that then that would be a fairly simple sandbox escape) but I hope a better balance exists... or at least that the wording is changed.

For anyone else who finds this thread, FB18614667 is fixed in macOS 15.6 RC (24G84), and in my test I no longer needed to include FSSupportsKernelOffloadedIO for metadataRead to work in that version.

And you’re able to make that work with App Sandbox enabled? Nice! Well, mostly. We already have a mechanism to auto-detect Java installs in some standard locations. The most common is the standard Java install location at /Library/Java/JavaVirtualMachines which the sandbox seems to let us access by default. Then some other locations we check can be allowed via file temporary exception entitlements. Only part that doesn't work^ is choosing arbitrary locations via file picker since that doesn't give executable access, unfortunately. ^ Well, it's possible in that we could use the SBPL temporary exception with a regex rule to allow execution in all Java bundles since they tend to be named/structured in a certain way. Though from what I understand the SBPL temporary exception isn't like the others since SBPL itself isn't supported, but at least this is the least common case and we can recommend putting JVMs in standard locations instead of doing this. And even if we take the risk, if it breaks at some point we will still have the supported alternative method to point people to instead. But for smaller developers, or folks working on open source projects, this is a challenging task. Hmm, yeah. This project uses hosted GitHub Actions CI for most of this stuff, and it doesn't seem like they make beta versions of macOS easily available to run actions on. So practically they'd need to be run locally by someone. :( Will definitely still try to investigate ways to make testing these fragile parts easier, though. But, you know, it’s either live with this trade-off or go work on yet another boring to-do list app, and I know which one I’d rather be doing (-: Ha, that's certainly a motivator. The challenge is part of the fun (at least until it breaks) :)

FSSupportsKernelOffloadedIO Oh, interesting. This actually came up when I filed a different bug where kernel offloaded IO wasn't working (FB17773100). At first it was closed because I didn't include that key (since it wasn't documented or in the template), but it still didn't work after adding that key until macOS 15.6 beta 3, where it's now fixed. Interesting to see that metadata{Read,Write} is linked to that at the moment. It was indeed the case that adding that key made it work. the FSKit team is working very hard to ship as many fixes as possible in macOS 15 (not just macOS 26) Yeah, I have noticed that the FSKit team has generally been quite responsive and good at updating the statuses of feedbacks I've filed recently. Highly appreciated, by the way! No, or at least not exactly... Interesting insight! I mostly come from a background (or lack thereof) where I kinda just started working with filesystem code first with FUSE as a small thing (for a school project) and found it interesting, then FSKit coming out gave me motivation to try to go deeper into it in my own time. Thus I never really used the older KPI to create filesystem kernel extensions and thus don't have some of this background knowledge, which makes filling in some of the gaps in the documentation a bit more challenging. Thank you to you and the team for being helpful in answering FSKit-related questions here on the forums, it's very helpful.

Wow, that’s quite a corner you’ve painted yourself in to (or maybe been painted in to :-). Haha, yeah 😅 more so the former, luckily(?) - the joys of trying to pick up a several year old open source issue (definitely seeing why no one has done it yet) Am I right in assuming that each mod’s entry point is in Java? So at some point the mod transitions from Java to native code? How does that transition happen? And could you hook that? Yes. In general Java's System.load function is used to load it with JNI. (Well, more specifically, the mod probably is using some Java library it depends on that calls System.load rather than the developer directly using it, but from our perspective that should basically be the same thing.) And on hooking it... If you could tweak that support then that’d provide an equivalent to your dlopen interpose, without the interpose. Hmm, maybe. The two ways I can think of that we could hook at the Java level is either distributing modified JVM runtimes or maybe using Java agents/instrumentation (which I'm woefully unfamiliar with). Though we do allow users to select their own JVM (sometimes different versions of the game need different JVM versions, and it can sometimes be useful to select specific versions to workaround certain bugs in certain cases), which would mean the second option is likely the better option. This would, of course, fall down if a mod’s native code unpacks more native code, so I’m curious if that happens in practice? I don't believe this really happens (I'm making an assumption based on the fact that most mods I've extracted only contain one library at maximum, so I don't think we'll see any "native loads more native" situations), so I think we can ignore this case. Though, in the rare case it does happen, we would intend to distribute both sandboxed and unsandboxed versions and allow users who really want to use these mods (or simply need to use mods that are fundamentally incompatible with the sandbox) to use the unsandboxed version. Though, one question I have is that if I simply move the same implementation I have working (call to XPC service which checks that file is actually a library then removes quarantine, then proceed with library load) to move from a dlopen interposition to some Java instrumentation of System.load, wouldn't your comment about the overall system being brittle That is, your overall system is gonna be quite brittle, and I suspect that interposition wouldn’t be the first thing to break O-: still apply? Or are you just speaking in general, that if I had to do this hack, there's probably a lot of other, more fragile hacks in place too?

I'm not familiar with how Time Machine on a NAS works but I'm looking at a Time Machine backup I have on a USB external drive and I can access backups of /var/root by using sudo(8), and didn't need to mess with special mount commands or SIP: $ sudo ls /Volumes/.timemachine/B5557776-FA71-48D9-B1E9-442B2BB5D0ED/2025-07-15-015123.backup/2025-07-15-015123.backup/Data/private/var/root .CFUserTextEncoding Downloads Movies .forward Library I was then able to restore some file from it with tmutil(8): $ sudo tmutil restore -v /Volumes/.timemachine/B5557776-FA71-48D9-B1E9-442B2BB5D0ED/2025-07-15-015123.backup/2025-07-15-015123.backup/Data/private/var/root/.CFUserTextEncoding ~/testrestore Copying file . ... 3 bytes for . Total copied: 0.00 MB (3 bytes) Items copied: 1 This was on a USB drive mounted with the regular automount system. I assume mounting a network drive with Finder would work similarly. The only thing that was tricky is that /var/root is currently a symlink to /private/var/root (at least on macOS 15.5) so you have to access the backup of /private/var/root. You might also need to give your terminal app Full Disk Access in System Settings.

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.