Hi, I am very excited for the fskit changes. Now I finally had some time to actually read the docs. But I am not very sure how the new cache api is able to propagate external file tree changes to fskit. As far as I understand it only handels cached file data but not metadata? I really hope I am just misunderstanding and this is possible. Greetings Nils

Hi! I'm developing an FSKit module and experiencing some troubles with test harness automation: Registering an FSKit AppEx requires user intervention by clicking through a GUI. Re-deploying a new build signed with a local certificate involves the same roundabout to re-toggle the registered AppEx in the Settings. Are there any plans to improve developer experience in this regard?

Hi folks! I’ve been paying attention to FSKit for moment to develop a network file system designed for source control-use cases (à la Eden or Google’s CITC). The design goal is support instant clones, even of massive repositories, by lazily fetching files as needed. Based on this thread, it seems like macOS 27 has added some of the requisite APIs needed to support inode invalidation for network/shared file systems like the cache coherency APIs. For example, I’m thinking that for this file system, I’d want to bypass the kernel’s own caching and have my file system be entirely responsible for it, as it‘d have a better understanding/picture of what is up-to-date and what isn’t and there won’t need to be multiple layers of cache invalidation/coherency. Am I correctly reading the intent of these new APIs?

Installing ZFSFSKit.appex ? /Library/ExtensionKit/Extensions/ Substituting real Mach-O (libtool wrapper ? .libs/ZFSFSKit) Installing zfs.fs ? /Library/Filesystems/ mount_zfs: Mach-O 64-bit executable arm64 Done. Signing (before pluginkit, so it sees a valid signature)... Re-signing /Library/ExtensionKit/Extensions/ZFSFSKit.appex ad-hoc (no identity). Note: requires amfi_get_out_of_my_way=1 in boot-args. Team ID: ADHOC /Library/ExtensionKit/Extensions/ZFSFSKit.appex: replacing existing signature Done. Signature: Identifier=org.openzfsonosx.filesystems.zfs.fsext Signature=adhoc TeamIdentifier=not set Entitlements: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.application-identifier</key><string>ADHOC.org.openzfsonosx.filesystems.zfs.fsext</string><key>com.apple.developer.fskit.fsmodule</key><true/><key>com.apple.developer.team-identifier</key><string>ADHOC</string><key>com.apple.security.app-sandbox</key><true/></dict></plist> Registering with pluginkit... pluginkit -a done. Restarting fskitd... # sudo pluginkit -v -m -p com.apple.fskit.fsmodule + org.openzfsonosx.filesystems.zfs.fsext((null)) 6A12A41280FB-4190-B957-FA94DC89BB1E 2026-05-29 01:17:58 +0000 /Library/ExtensionKit/Extensions/ZFSFSKit.appex # sudo mkdir /Volumes/tank # sudo mount -F -t zfs /dev/disk4 /Volumes/tank # ls -la /Volumes/tank total 3 drwxr-xr-x 3 lundman staff 4 May 29 09:21 . drwxr-xr-x 4 root wheel 128 May 29 10:18 .. -rw-r--r-- 1 lundman staff 11 May 29 09:21 file.txt drwxr-xr-x 2 lundman staff 2 May 29 09:21 HelloWorld # cat /Volumes/tank/file.txt HelloWorld Even though FSKit isn't quite ready, I built a proof-of-concept FSKit extension to understand what the migration path looks like. This post shares what we got working, specific technical findings that weren't documented, and the gaps we hit that would need Apple's attention for a production implementation. Luckily, OpenZFS already compiles in userland for the "zdb" utility so not much work was required on that side. There were certain amount of desperation applied when we came across hurdles, so possibly some assumptions we formed are not correct. (We didn't go back and confirm the problem after it started working).

Any plans to provide (a subset of) the FUSE3 API directly on top of FSKit/an underlying primitive, in a way that doesn't compromise the new security model, but also reduces porting friction?

I've been looking at the new kernel caching APIs in FSKit (FSVolume.DataCacheHandler), and they look like they'll be quite useful for network file systems. But are they recommended to be implemented for block device file systems? I see an "Important" note in the documentation that says If a file system doesn’t conform to this protocol, the kernel may still cache it. However, such a file system has no control over caching behavior; the kernel caches data as it sees fit. So I'm wondering in the case of a block device system, where I'm (mostly) using kernel offloaded IO, whether this has any relevance, or if I should instead skip this implementation and just let the kernel "do its thing."

Outside of a very narrow happy path, Filesystem Extensions can leave the system in a bad state that can be hard to get out of: For example, a hanging Volume call can leave any process attempting to read from it permanently stuck (no timeouts, process is unkillable, ps / pkill / pgrep themselves may start hanging). When it comes to installation, FS AppEx are registered with two subsystems afaict (LaunchServices and fskitd) — those two states can get out of sync, and typically cannot be repaired manually. In particular, the only way to reset fskit state seems to be to kill it (notably, disabling SIP is required to launchctl kickstart it, but sudo killall fskit works like a charm). AppEx installed/enabled state seems to be per-user. When mounting as root, fskit queries a different state (implying that a FS may be enabled for an admin user ie. John Doe, but not from the perspective of a root SMAppService — even when using launchctl asuser/bsexec to attempt to replicate the security context of John Doe's login session at their behest). The actual question here is hard to formulate... are there any plans to make FS AppEx behave more like the rest of the platform? More consistent/helpful/centralized logging (it is currently spread across multiple targets and as much as the "boom" and emojis are entertaining, on day 14 of debugging transient failures, it does get old). Making a .pkg installer with an FS AppEx inside prevents the AppEx from being installed through the prescribed happy path (simply having the user launch the containing .app) since it gets pre-registered via LaunchServices. In fact, building an AppEx through XCode automatically registers it with ls, making real-world testing of AppEx really difficult... The sheer breadth of subtle challenges in shipping a working, reliable FSKit-based filesystem on macOS has prevented me so far from filing tidy, individual bug reports, and for this I apologize, but: if you have a roadmap of "reliability improvements / behavior normalization / edge case resolutions" to share today, I'm sure many of us would be eager to read it.

Is FSBlockDeviceResource thread-safe, or do I need to ensure that it’s not written across multiple threads simultaneously? I see that FSBlockDeviceResource is not marked as Sendable in Swift. (This question could also apply to the other FSResources as well if it's simple to answer for them too, but it's just that for my specific use case I'm using FSBlockDeviceResource.)

What does volumeSupportsPersistentIDsKey represent and guarantee on macOS? Is it specifically about persistent filesystem object IDs such as fileIdentifierKey / inode / systemFileNumber, or can it refer to other kinds of persistent IDs? For which common volume/filesystem cases would this property be false, and what should I fall back to as file identity in those cases? Thanks!

Is it necessary to switch to the new FSExtentType.readOnly when implementing kernel offloaded IO if my entire volume is read-only and marked as such via requestedMountOptions? (My assumption is "no" since I'd think all writes to the resource at that point should be prevented anyway, but wanted to ask just in case.)

I cannot find anywhere in the documentation how to invalidate an FSItem. It seems to be cached indefinitely or am I missing something?

What I'm building An FSUnaryFileSystem that projects a large, read-mostly tree of existing on-disk files into a sandbox namespace — a build sandbox that lays out an action's declared inputs and points outputs at host scratch. This is squarely the "replace a third-party kext (macFUSE-style) with FSKit" use case, and it's a projection/overlay filesystem: nearly every file the volume serves is just a view of a regular file that already exists on a local APFS volume. The problem For file content, the only available path for a file-backed (non-block-device) volume is FSVolumeReadWriteOperations — every read that misses UBC is an XPC round-trip into my extension, where I memcpy from the backing file into the kernel buffer. The kernel already has, or could trivially open, the backing file; instead each page-in becomes: pagein → IPC → extension read → copy → return. FSVolumeKernelOffloadedIOOperations looks like the intended fast path, but it's built around FSBlockDeviceResource — i.e. it assumes the volume is backed by a block device the kernel can do extent I/O against. A projection over regular files has no block device, so there's no way to say "this item is backed by host file X — kernel, please do I/O directly against X and skip my process." What I measured In one representative build action my volume serves ~440 files and the kernel issues ~630 read RPCs (cold). A real build runs thousands of such actions, so this is on the order of millions of round-trips and buffer copies per build, for data that is already sitting in the host page cache. UBC absorbs repeats, but cold reads, cache eviction under memory pressure, and large sequential reads all pay the full RPC+copy cost. It dominates the I/O profile. The ask A passthrough/offload API for file-backed volumes: let the extension associate an FSItem with a backing file descriptor (or vnode) and have the kernel perform reads — and optionally writes — directly against the backing file, bypassing the userspace round-trip. Per-item, opt-in, and read-only-only would already be a huge win for projection/overlay workloads. This is exactly the model that already exists on other platforms: Linux FUSE passthrough (FUSE_PASSTHROUGH, backing-id via FUSE_DEV_IOC_BACKING_OPEN, mainline since 6.9): a FUSE daemon registers a backing fd and the kernel routes I/O straight to it. Windows Projected File System (ProjFS): content is hydrated/served from a provider-supplied source without a per-read user-space hop. FSKit is positioned as the supported replacement for kext-based filesystems, and projection/overlay/caching filesystems are a primary motivation for it — yet those are precisely the volumes that need zero-copy passthrough to be viable at scale. The block-device offload path covers disk-image-style filesystems; the gap is the file-backed case.

Environment macOS Version: 26.1 Xcode Version: 16.2 Description I'm developing a custom file system using FSKit and have encountered an issue where the removeItem(_:named:fromDirectory:) method in my FSVolume.Operations implementation is not being invoked when attempting to delete files or directories through Finder or the command line. Implementation My volume implements the required FSVolume.Operations protocol with the following removeItem implementation: func removeItem( _ item: FSItem, named name: FSFileName, fromDirectory directory: FSItem ) async throws { logger.info("remove: \(name)") if let item = item as? MyFSItem, let directory = directory as? MyFSItem { directory.removeItem(item) } else { throw fs_errorForPOSIXError(POSIXError.EIO.rawValue) } } Steps to Reproduce Mount the custom FSKit-based file system using: mount -F -t MyFS /dev/diskX /tmp/mountpoint Create files using Finder or terminal (works correctly - createItem is called) Attempt to delete a file using any of the following methods: Terminal command: rm -rf /path/to/mounted/file option + cmd + delete to remove the file in Finder Expected Behavior The removeItem(_:named:fromDirectory:) method should be called, logging "remove: [filename]" and removing the item from the directory's children collection. Actual Behavior The removeItem method is never invoked. No logs appear from this method in Console.app. The deletion operation either fails silently or returns an error, but the callback never occurs. Additional Context Working operations: Other operations work correctly including: createItem - files and directories can be created lookupItem - items can be looked up successfully enumerateDirectory - directory listing works read and write - file I/O operations work correctly Volume state: The volume is properly mounted and accessible Files can be created, read, and written successfully Volume capabilities configured: var supportedVolumeCapabilities: FSVolume.SupportedCapabilities { let capabilities = FSVolume.SupportedCapabilities() capabilities.supportsHardLinks = true capabilities.supportsSymbolicLinks = true capabilities.supportsPersistentObjectIDs = true capabilities.doesNotSupportVolumeSizes = true capabilities.supportsHiddenFiles = true capabilities.supports64BitObjectIDs = true capabilities.caseFormat = .insensitiveCasePreserving return capabilities } Questions Are there specific volume capabilities or entitlements required for removeItem to be invoked? Is there a specific way deletion operations need to be enabled in FSKit? Could this be related to how file permissions or attributes are set during createItem? Are there any known issues with deletion operations in the current FSKit implementation? Do I need to implement additional protocols or set specific flags to support item deletion? Any guidance would be greatly appreciated. Has anyone successfully implemented deletion operations in FSKit? Thank you!

Hello there, I am wanting to create a custom FSKit extension, and am trying to get the sample passthrough project running: https://developer.apple.com/documentation/fskit/building-a-passthrough-file-system I have just followed the basic instructions from the tutorial above, so have: Selected my team for the signing certificate (required for FSKit module). Built and run. Enabled "Passthrough file system" under "File System Extensions". Made a test directory to mount to: mkdir ~/test But when I run the mount command, I get the following error: mount -t passthrough ~/Documents ~/test mount: Loading resource: The operation couldn’t be completed. (com.apple.extensionKit.errorDomain error 2.) mount: exec /Library/Filesystems/passthrough.fs/Contents/Resources/mount_passthrough for /Users/xxxxxxxx/test: No such file or directory mount: /Users/xxxxxxxx/test failed with 72 The contents of /Library/Filesystems/ is empty, so I don't know if allowing the extension is meant to add something to this directory or not. Any help would be much appreciated!

I'm writing a read-only filesystem extension. I see that the documentation for loadResource(resource:options:replyHandler:) claims that the --rdonly option is supported, which suggests that this should be possible. However, I have never seen this option provided to my filesystem extension, even if I return usableButLimited as a probe result (where it doesn't mount at all - FB19241327) or pass the -r or -o rdonly options to the mount(8) command. Instead I see those options on the volume's activate call. But other than saving that "readonly" state (which, in my case, is always the case) and then throwing on all write-related calls I'm not sure how to actually mark the filesystem as "read-only." Without such an indicator, the user is still offered the option to do things like trash items in Finder (although of course those operations do not succeed since I throw an EROFS error in the relevant calls). It also seems like the FSKit extensions that come with the system handle read-only strangely as well. For example, for a FAT32 filesystem, if I mount it like mount -r -F -t msdos /dev/disk15s1 /tmp/mnt Then it acts... weirdly. For example, Finder doesn't know that the volume is read-only, and lets me do some operations like making new folders, although they never actually get written to disk. Writing may or may not lead to errors and/or the change just disappearing immediately (or later), which is pretty much what I'm seeing in my own filesystem extension. If I remove the -F option (thus using the kernel extension version of msdos), this doesn't happen. Are read-only filesystems currently supported by FSKit? The fact that extensions like Apple's own msdos also seem to act weirdly makes me think this is just a current FSKit limitation, although maybe I'm missing something. It's not necessarily a hard blocker given that I can prevent writes from happening in my FSKit module code (or, in my case, just not implement such features at all), but it does make for a strange experience. (I reported this as FB21068845, although I'm mostly asking here because I'm not 100% sure this is not just me missing something.)

I'm trying to make an FSKit module for NTFS read-write filesystem and at the stage where everything is more or less working fine as long as I mount the volume via mount -F and that volume is a RAM disk. However, since the default NTFS read-only driver is already present in macOS, this introduces an additional challenge. Judging by the DiskArbitration sources, it looks like all FSKit modules are allowed to probe anything only after all kext modules. So, in this situation, any third-party NTFS FSKit module is effectively blocked from using DiskArbitration mechanisms at all because it's always masked during the probing by the system's read-only kext. This leaves mount -F as the only means to mount the NTFS volume via FSKit. However, even that doesn't work for volumes on real (non-RAM) disks due to permission issues. The logs in Console.app hint that the FSKit extension is running; however, it looks like the fskitd itself doesn't have permissions to access real disks if it's initiated from the mount utility? default 16:42:41.939498+0200 fskitd New module list <private> default 16:42:41.939531+0200 fskitd Old modules (null) default 16:42:41.939578+0200 fskitd Added 2 identifiers: <private> default 16:42:41.939651+0200 fskitd [0x7fc58020bf00] activating connection: mach=true listener=true peer=false name=com.apple.filesystems.fskitd debug 16:42:41.939768+0200 fskitd main:RunLoopRun debug 16:42:41.939811+0200 fskitd -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: start default 16:42:41.939870+0200 fskitd Incomming connection, entitled 0 debug 16:42:41.940021+0200 fskitd -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: accepting connection default 16:42:41.940048+0200 fskitd [0x7fc580006120] activating connection: mach=false listener=false peer=true name=com.apple.filesystems.fskitd.peer[1816].0x7fc580006120 default 16:42:41.940325+0200 fskitd Hello FSClient! entitlement no default 16:42:41.940977+0200 fskitd About to get current agent for 503 default 16:42:41.941104+0200 fskitd [0x7fc580015480] activating connection: mach=true listener=false peer=false name=com.apple.fskit.fskit_agent info 16:42:41.941227+0200 fskitd About to call to fskit_agent debug 16:42:42.004630+0200 fskitd -[fskitdAgentManager currentExtensionForShortName:auditToken:replyHandler:]_block_invoke: Found extension for fsShortName (<private>) info 16:42:42.005409+0200 fskitd Probe starting on <private> debug 16:42:42.005480+0200 fskitd -[FSResourceManager getResourceState:]:not_found:<private> debug 16:42:42.005528+0200 fskitd -[FSResourceManager addTaskUUID:resource:]:<private>: Adding task (<private>) debug 16:42:42.005583+0200 fskitd applyResource starting with resource <private> kind 1 default 16:42:42.005609+0200 fskitd About to get current agent for 503 info 16:42:42.005629+0200 fskitd About to call to fskit_agent debug 16:42:42.006700+0200 fskitd -[fskitdXPCServer getExtensionModuleFromID:forToken:]_block_invoke: Found extension <private>, attrs <private> default 16:42:42.006829+0200 fskitd About to get current agent for 503 info 16:42:42.006858+0200 fskitd About to call to fskit_agent, bundle ID <private>, instanceUUID <private> default 16:42:42.070923+0200 fskitd About to grab assertion on pid 1820 default 16:42:42.071058+0200 fskitd Initializing connection default 16:42:42.071141+0200 fskitd Removing all cached process handles default 16:42:42.071185+0200 fskitd Sending handshake request attempt #1 to server default 16:42:42.071223+0200 fskitd Creating connection to com.apple.runningboard info 16:42:42.071224+0200 fskitd Acquiring assertion: <RBSAssertionDescriptor| "com.apple.extension.session" ID:(null) target:1820> default 16:42:42.071258+0200 fskitd [0x7fc58001cdc0] activating connection: mach=true listener=false peer=false name=com.apple.runningboard default 16:42:42.075617+0200 fskitd Handshake succeeded default 16:42:42.075660+0200 fskitd Identity resolved as osservice<com.apple.filesystems.fskitd> debug 16:42:42.076337+0200 fskitd Adding assertion 183-1817-1669 to dictionary debug 16:42:42.076385+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]:bsdName:<private> default 16:42:42.076457+0200 fskitd [0x7fc5801092e0] activating connection: mach=true listener=false peer=false name=com.apple.fskit.fskit_helper default 16:42:42.077706+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]_block_invoke: Open device returned error Error Domain=NSPOSIXErrorDomain Code=13 info 16:42:42.077760+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]: failed to open device <private>, Error Domain=NSPOSIXErrorDomain Code=13 default 16:42:42.077805+0200 fskitd [0x7fc5801092e0] invalidated because the current process cancelled the connection by calling xpc_connection_cancel() debug 16:42:42.077830+0200 fskitd +[FSBlockDeviceResource(Project) openWithBSDName:writable:auditToken:replyHandler:]:end info 16:42:42.078459+0200 fskitd openWith returned err Error Domain=NSPOSIXErrorDomain Code=13 dev (null) error 16:42:42.078501+0200 fskitd -[fskitdXPCServer getRealResource:auditToken:reply:]: Unable to convert proxy FSBlockDeviceResource into open resource error 16:42:42.078538+0200 fskitd -[fskitdXPCServer applyResource:targetBundle:instanceID:initiatorAuditToken:authorizingAuditToken:isProbe:usingBlock:]: Can't get the real resource of <private> default 16:42:42.105443+0200 fskitd [0x7fc580006120] invalidated because the client process (pid 1816) either cancelled the connection or exited The mount utility call I use is the same for RAM and real disks with the only difference being the device argument and this permission error is only relevant for real disks case. So, the proper solution (using DiskArbitration) seems to be blocked architecturally in this use case due to FSKit modules being relegated to the fallback role. Is this subject to change in the future? The remaining workaround with using the mount directly doesn't work for unclear reasons. Is that permission error a bug? Or am I missing something?

If I'm in an enumerateDirectory call, I can very quickly fill in the fileID, parentID, and (maybe) the type attributes based on the directory entry I have loaded. That is, I can quickly fill in anything that is contained in the dirent structure in dirent.h, plus the parentID. However, if any other attributes are requested (say, flags), or if the file system doesn't store the filetype in the directory entry, then I need to do additional I/O and load an inode. If I have to load an inode, I might keep a reference to it and assume that I can clean it up later whenever there is a matching call to reclaimItem. But in the enumerateDirectory call, I never provide an FSItem to the system! By observation, I see that normally, a call to enumerateDirectory of this nature is followed up by a lookupItem call for every single fetched item, and then assumedly the system can later reclaim it if need be. At least, I tried various ways of listing directories, and each way I tried showed this behavior. If that's the case, then I can rely on a later reclaimItem call telling me when to clean up this cached data from memory. Is this guaranteed, however? I don't see a mention of this in the documentation, so I'm not sure if I can rely on this. Or, do I need to handle a case where, if I do additional I/O after enumerateDirectory, I might need to figure out when cached data should be cleaned up to avoid a "leak?" (Using the term "leak" loosely here, since in theory looking up the file later would make it reclaimable, but perhaps that might not happen.)

Shouldn't it be supported? Also is there a way to disable spotlight indexing on a mounted folder? mds_stores is going wild on fskit volumes. mount -o nobrowse -t passthrough ~/Downloads ~/mnt alexf@MacBook-Pro-3 build % mount file:///Users/alexf/Downloads/ on /Users/alexf/mnt (passthrough, local, nodev, nosuid, noowners, noatime, fskit, mounted by alexf)```

After building the sample and enabling the file system extension the mount command is freezing. Any tips how to diagnose that? The logs show the following: log stream --style compact --info --debug --predicate 'subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"' Filtering the log data using "subsystem == "com.apple.FSKit" OR process CONTAINS[c] "samplecode"" Timestamp Ty Process[PID:TID] 2026-03-17 15:15:51.832 I mount[16111:d88caa] [com.apple.FSKit:default] FSClient setting up connection to fskitd 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: start 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Incomming connection, entitled 0 2026-03-17 15:15:51.833 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[liveFilesMountServiceDelegate listener:shouldAcceptNewConnection:]: accepting connection 2026-03-17 15:15:51.833 Df fskitd[589:d88a5f] [com.apple.FSKit:default] Hello FSClient! entitlement no 2026-03-17 15:15:51.834 Df mount[16111:d88caa] [com.apple.FSKit:default] Setting remote protocol to all XPC 2026-03-17 15:15:51.834 Df fskitd[589:d88a5f] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.834 I fskitd[589:d88a5f] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.835 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.836 Db fskitd[589:d88a5f] [com.apple.FSKit:default] -[fskitdAgentManager currentExtensionForShortName:auditToken:replyHandler:]_block_invoke: Found extension for fsShortName () 2026-03-17 15:15:51.837 I fskitd[589:d88a5f] [com.apple.FSKit:default] Probe starting on 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager getResourceState:]:found: 2026-03-17 15:15:51.837 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[FSResourceManager addTaskUUID:resource:]:: Adding task () 2026-03-17 15:15:51.837 Df fskitd[589:d87c31] [com.apple.FSKit:default] About to get current agent for 501 2026-03-17 15:15:51.837 I fskitd[589:d87c31] [com.apple.FSKit:default] About to call to fskit_agent 2026-03-17 15:15:51.837 I fskit_agent[10123:d877d9] [com.apple.FSKit:default] Getting extensions 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] -[fskitdXPCServer getExtensionModuleFromID:forToken:]_block_invoke: Found extension , attrs 2026-03-17 15:15:51.838 Db fskitd[589:d87c31] [com.apple.FSKit:default] applyResource starting with resource kind 4

I developed a cloud drive using fskit, but after mounting it, it did not appear in the Finder sidebar and the disk tool could not list it. How should I adapt? The mounting looks successful, and you can also open and see the fixed files I wrote in the code. I have also turned on the Finder sidebar settings function