Modern versions of macOS use a file system permission model that’s far more complex than the traditional BSD rwx model, and this post is my attempt at explaining that model. If you have a question about this, post it here on DevForums, tagging your thread with Files and Storage so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" On File System Permissions Modern versions of macOS have four different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) The first two were introduced a long time ago and rarely trip folks up. The second two are newer, more complex, and specific to macOS, and thus are the source of some confusion. This post is my attempt to clear that up. Error Codes App Sandbox and the mandatory access control system are both implemented using macOS’s sandboxing infrastructure. When a file system operation fails, check the error to see whether it was blocked by this sandboxing infrastructure. If an operation was blocked by BSD permissions or ACLs, it fails with EACCES (Permission denied, 13). If it was blocked by something else, it’ll fail with EPERM (Operation not permitted, 1). If you’re using Foundation’s FileManager, these error are both reported as Foundation errors, for example, the NSFileReadNoPermissionError error. To recover the underlying error, get the NSUnderlyingErrorKey property from the info dictionary. App Sandbox File system access within the App Sandbox is controlled by two factors. The first is the entitlements on the main executable. There are three relevant groups of entitlements: The com.apple.security.app-sandbox entitlement enables the App Sandbox. This denies access to all file system locations except those on a built-in allowlist (things like /System) or within the app’s containers. The various “standard location” entitlements extend the sandbox to include their corresponding locations. The various “file access temporary exceptions” entitlements extend the sandbox to include the items listed in the entitlement. Collectively this is known as your static sandbox. The second factor is dynamic sandbox extensions. The system issues these extensions to your sandbox based on user behaviour. For example, if the user selects a file in the open panel, the system issues a sandbox extension to your process so that it can access that file. The type of extension is determined by the main executable’s entitlements: com.apple.security.files.user-selected.read-only results in an extension that grants read-only access. com.apple.security.files.user-selected.read-write results in an extension that grants read/write access. Note There’s currently no way to get a dynamic sandbox extension that grants executable access. For all the gory details, see this post. These dynamic sandbox extensions are tied to your process; they go away when your process terminates. To maintain persistent access to an item, use a security-scoped bookmark. See Accessing files from the macOS App Sandbox. To pass access between processes, use an implicit security scoped bookmark, that is, a bookmark that was created without an explicit security scope (no .withSecurityScope flag) and without disabling the implicit security scope (no .withoutImplicitSecurityScope flag)). If you have access to a directory — regardless of whether that’s via an entitlement or a dynamic sandbox extension — then, in general, you have access to all items in the hierarchy rooted at that directory. This does not overrule the MAC protection discussed below. For example, if the user grants you access to ~/Library, that does not give you access to ~/Library/Mail because the latter is protected by MAC. Finally, the discussion above is focused on a new sandbox, the thing you get when you launch a sandboxed app from the Finder. If a sandboxed process starts a child process, that child process inherits its sandbox from its parent. For information on what happens in that case, see the Note box in Enabling App Sandbox Inheritance. IMPORTANT The child process inherits its parent process’s sandbox regardless of whether it has the com.apple.security.inherit entitlement. That entitlement exists primarily to act as a marker for App Review. App Review requires that all main executables have the com.apple.security.app-sandbox entitlement, and that entitlements starts a new sandbox by default. Thus, any helper tool inside your app needs the com.apple.security.inherit entitlement to trigger inheritance. However, if you’re not shipping on the Mac App Store you can leave off both of these entitlement and the helper process will inherit its parent’s sandbox just fine. The same applies if you run a built-in executable, like /bin/sh, as a child process. When the App Sandbox blocks something, it typically generates a sandbox violation report. For information on how to view these reports, see Discovering and diagnosing App Sandbox violations. To learn more about the App Sandbox, see the various links in App Sandbox Resources. For information about how to embed a helper tool in a sandboxed app, see Embedding a Command-Line Tool in a Sandboxed App. Mandatory Access Control Mandatory access control (MAC) has been a feature of macOS for many releases, but it’s become a lot more prominent since macOS 10.14. There are many flavours of MAC but the ones you’re most likely to encounter are: Full Disk Access (macOS 10.14 and later) Files and Folders (macOS 10.15 and later) Data container protection (macOS 14 beta and later) Data Vaults (see below) Mandatory access control, as the name suggests, is mandatory; it’s not an opt-in like the App Sandbox. Rather, all processes on the system, including those running as root, as subject to MAC. Data Vaults are not a third-party developer opportunity. See this post if you’re curious. In the Full Disk Access and Files and Folders cases, users grant a program a MAC privilege using System Settings > Privacy & Security. Some MAC privileges are per user (Files and Folders) and some are system wide (Full Disk Access). If you’re not sure, run this simple test: On a Mac with two users, log in as user A and enable the MAC privilege for a program. Now log in as user B. Does the program have the privilege? If a process tries to access an item restricted by MAC, the system may prompt the user to grant it access there and then. For example, if an app tries to access the desktop, you’ll see an alert like this: “AAA” would like to access files in your Desktop folder. [Don’t Allow] [OK] To customise this message, set Files and Folders properties in your Info.plist. This system only displays this alert once. It remembers the user’s initial choice and returns the same result thereafter. This relies on your code having a stable code signing identity. If your code is unsigned, or signed ad hoc (“Signed to run locally” in Xcode parlance), the system can’t tell that version N+1 of your code is the same as version N, and thus you’ll encounter excessive prompts. Note For information about how that works, see TN3127 Inside Code Signing: Requirements. The Files and Folders prompts only show up if the process is running in a GUI login session. If not, the operation is allowed or denied based on existing information. If there’s no existing information, the operation is denied by default. For all the details about data container protection, see WWDC 2023 Session 10053 What’s new in privacy. On managed systems the site admin can use the com.apple.TCC.configuration-profile-policy payload to assign MAC privileges. For testing purposes you can reset parts of TCC using the tccutil command-line tool. For general information about that tool, see its man page. For a list of TCC service names, see the posts on this thread. Note TCC stands for transparency, consent, and control. It’s the subsystem within macOS that manages most of the privileges visible in System Settings > Privacy & Security. TCC has no API surface, but you see its name in various places, including the above-mentioned configuration profile payload and command-line tool, and the name of its accompanying daemon, tccd. While tccutil is an easy way to do basic TCC testing, the most reliable way to test TCC is in a VM, restoring to a fresh snapshot between each test. If you want to try this out, crib ideas from Testing a Notarised Product. The MAC privilege mechanism is heavily dependent on the concept of responsible code. For example, if an app contains a helper tool and the helper tool triggers a MAC prompt, we want: The app’s name and usage description to appear in the alert. The user’s decision to be recorded for the whole app, not that specific helper tool. That decision to show up in System Preferences under the app’s name. For this to work the system must be able to tell that the app is the responsible code for the helper tool. The system has various heuristics to determine this and it works reasonably well in most cases. However, it’s possible to break this link. I haven’t fully research this but my experience is that this most often breaks when the child process does something ‘odd’ to break the link, such as trying to daemonise itself. If you’re building a launchd daemon or agent and you find that it’s not correctly attributed to your app, add the AssociatedBundleIdentifiers property to your launchd property list. See the launchd.plist man page for the details. Scripting MAC presents some serious challenges for scripting because scripts are run by interpreters and the system can’t distinguish file system operations done by the interpreter from those done by the script. For example, if you have a script that needs to manipulate files on your desktop, you wouldn’t want to give the interpreter that privilege because then any script could do that. The easiest solution to this problem is to package your script as a standalone program that MAC can use for its tracking. This may be easy or hard depending on the specific scripting environment. For example, AppleScript makes it easy to export a script as a signed app, but that’s not true for shell scripts. TCC and Main Executables TCC expects its bundled clients — apps, app extensions, and so on — to use a native main executable. That is, it expects the CFBundleExecutable property to be the name of a Mach-O executable. If your product uses a script as its main executable, you’re likely to encounter TCC problems. To resolve these, switch to using a Mach-O executable. For an example of how you might do that, see this post. Revision History 2023-06-13 Replaced two obsolete links with links to shiny new official documentation: Accessing files from the macOS App Sandbox and Discovering and diagnosing App Sandbox violations. Added a short discussion of data container protection and a link to WWDC 2023 Session 10053 What’s new in privacy. 2023-04-07 Added a link to my post about executable permissions. Fixed a broken link. 2023-02-10 In TCC and Main Executables, added a link to my native trampoline code. Introduced the concept of an implicit security scoped bookmark. Introduced AssociatedBundleIdentifiers. Made other minor editorial changes. 2022-04-26 Added an explanation of the TCC initialism. Added a link to Viewing Sandbox Violation Reports.  Added the TCC and Main Executables section. Made significant editorial changes. 2022-01-10 Added a discussion of the file system hierarchy. 2021-04-26 First posted.

General: DevForums tags: Files and Storage, Finder Sync, File Provider, Disk Arbitration, APFS File System Programming Guide On File System Permissions DevForums post File Provider framework Finder Sync framework App Extension Programming Guide > App Extension Types > Finder Sync Disk Arbitration Programming Guide Mass Storage Device Driver Programming Guide Device File Access Guide for Storage Devices Apple File System Guide TN1150 HFS Plus Volume Format Extended Attributes and Zip Archives File system changes introduced in iOS 17 DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

File system changes introduced in iOS 17 As part of iOS 17, tvOS 17, and watchOS 10, the system has reorganized where applications and their data containers are stored. In previous systems, both lived within the same volume but, starting in iOS 17, they will be stored on different volumes. What does this mean for you? Copying large amounts of data from the app bundle to a data container will take longer than in previous versions of iOS. Previously that copy would have occurred as an APFS file clone, but now the operation will occur as a standard copy, which may take much significantly longer. Because the data will need to be fully duplicated, storage usage will increase more than was the case in previous versions. You should minimize the data they copy out of their app bundle and avoid any unnecessary duplication of data between the app bundle and data container. When upgrading from previous system version, splitting the data into separate volumes may mean that there is insufficient space for all existing apps and their data. If this occurs, the app's data container will remain on the device, preserving the user's data, while the app bundle itself is removed using the same mechanism as "Offload Unused Apps". The user can then restore the app once they've freed sufficient space for the app to install. Revision History 2023-07-11 First posted

We want to give the user the ability to clear "document and data". We first try to calculate the size by summing the size of all the files in that directory FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask).first. But after calculating the size, we see that the size of the "document and data" that the user sees in the storage is larger than the size of our cache in ios 17. But in earlier versions 16, 15, etc. this directory is not taken into account when calculating the size . Which directories are counted in ios 17? And what directories are taken into account in an earlier version of iOS?

Hello, We are currently developing a device with a USB-C drive, and we want to connect it to iOS devices to import the stored files into our app. I have a few questions regarding this: MFi Certification Requirement We believe that MFi certification is not necessary for USB-C connections. Is this understanding correct? Implementation Method We prefer not to use standard components like UIDocumentPickerViewController. Are there any methods to access the file system directly, or any other suitable approaches you can recommend? If anyone has experience with this, your advice would be greatly appreciated. Thank you in advance.

I am using an iPhone 11 running iOS 18 Developer Beta 1. Recently, I've encountered a significant problem with my system storage. As of now, my system files are occupying 44 GB of my 128 GB drive, which is an excessive amount. Here's a detailed overview of the issue: Problem Description: My system files are consuming an unusually large amount of storage—44 GB out of 128 GB. Steps Taken: I attempted to resolve this by cleaning up my pictures, but the system file size continued to grow. I also tried clearing the caches, but this did not help. Error Messages: I haven't received any specific error messages, but some of my apps keep crashing intermittently. Frequency of the Issue: This issue is constant and does not seem to resolve on its own. Impact: I am unable to update or download new apps. I cannot download new pictures. I am unable to update to iOS 18 Developer Beta 2 due to insufficient space. Additional Information: The problem began around a week ago. At that time, the system files were around 10 GB, which was already concerning, but it has now ballooned to 44 GB. This storage issue is severely impacting the functionality of my iPhone, and I'm seeking assistance to identify the cause and find a solution.

I need to disallow folder renaming on my NSFileProviderReplicatedExtension extension as my foreign API system changes the asset id when a folder gets renamed and I can't retrieve or compute the new ID. For this reason I disable .allowsRenaming on folders for this volume but the Finder will still trigger the two step create "untitled folder" / rename when creating new folders. I can see that existing folders can't be renamed on the volume so the capability seems properly managed by my extension. Is there a way to prevent the creation of the "untitled folder" folder when creating new folders in Finder on a folder with renaming disabled ?

I have an app (currently not released on App Store) which runs on both iOS and macOS. The app has widgets for both iOS and macOS which uses user preference (set in app) into account while showing data. Before upgrading to macOS 15 (until Sonoma) widgets were working fine and app was launching correctly, but after upgrading to macOS 15 Sequoia, every time I launch the app it give popup saying '“Kontest” would like to access data from other apps. Keeping app data separate makes it easier to manage your privacy and security.' and also widgets do not get user preferences and throw the same type of error on Console application when using logging. My App group for both iOS and macOS is 'group.com.xxxxxx.yyyyy'. I am calling it as 'UserDefaults(suiteName: Constants.userDefaultsGroupID)!.bool(forKey: "shouldFetchAllEventsFromCalendar")'. Can anyone tell, what am I doing wrong here?

I'm an iOS developer, and I've been testing our app in iOS 18.0 Beta. I noticed that there's a problem with the font rendering, and after troubleshooting, I've found out that it's caused by the removal of the PingFang.ttc font in 18.0. I would like to ask the reason for removing this font file and which font should be used to display Chinese in the future? My test device is an iPhone 11 Pro and the system version is iOS 18.0 (22A5297). I have also tested Beta 1 and it has the same issue. In previous versions of the system, the PingFang font is located in this directory /System/Library/Fonts/LanguageSupport/PingFang.ttc. But in iOS 18.0, the font file in this directory has become Kohinoor.ttc, and I've tested that this font can't display Chinese either. I traversed the following system font directories and could not find the PingFang.ttc font file. /System/Library/Fonts/AppFonts /System/Library/Fonts/Core /System/Library/Fonts/CoreAddition /System/Library/Fonts/CoreUI /System/Library/Fonts/LanguageSupport /System/Library/Fonts/UnicodeSupport /System/Library/Fonts/Watch Looking for answers, thanks for the help!

I upgrade to IOS 18 and for about a week it worked great. Now the system storage keeps increasing in size to the point my phone freezes and crashes. While it does this my phone gets hot and lags. I have a 64gb iPhone 12. When it restarts it starts around 20GBs and just goes up.

How do I accomplish a postorder enumeration of a directory (that is, get subdirectories before the parents)? Normally I would use FileManager.enumerator(at:includingPropertiesForKeys:options:errorHandler:) for enumeration. And there is a DirectoryEnumerationOptions named includesDirectoriesPostOrder. Unfortunately it does not seem to work. If I create the enumerator like this: FileManager.default.enumerator(at: url, includingPropertiesForKeys: resourceKeys, options: [.skipsPackageDescendants, .skipsHiddenFiles, .includesDirectoriesPostOrder]) The enumerator does not provide the results postorder. And in fact if you check the isEnumeratingDirectoryPostOrder, it returns false. Am I using this incorrectly, or is it just broken? Is there some other way to accomplish this? I see that CFURLEnumerator has a similar option, though I don't know if it works any better. Plus I would rather not wrestle with Core Foundation code if I can avoid it.

Hello! I am having a serious problem with my iPad Pro 2018 64GB. I had to delete everything, from Photos to Music, to games, to apps. I left only my e-mails (around 0,8GB and work apps like Outlook, Teams, Authenticators). All this only to install the Beta 2 for iPadOS 18. The culprit: Other System Data which at some point it was 42GB. Plus the 12GB iPadOS itself....my 64GB memory is done for. How I am supposed to utilise my iPad in this conditions? I did the same thing with iPadOS 17 Beta, and never ever had this issue, the System Data memory was "flexible" as advertised. In this version, it is only growing larger and never going down. I have restarted the iPad like 10 times, it wasn't going down, only up. I am not going to Reset my entire iPad because it will take me forever to set it up again for my work (I work for a company with a lot of security measures and I need to redo them all after Reset, they are not saved in Cloud). I know Beta wasn't supposed to be all perfect and dandy, but Apple, please, make it at least usable for devices with 64GB memory, because you do offer support for them. If you don't, at least put a restriction and allow the 18 Beta to run only on devices with at least 128GB of memory. Even then, half of it to be utilised by system files that are not my choice to be there, seems like I pay that memory premium tax to increase your stock prices and not my peace of mind. Fix it because my 1000$ iPad is useless right now.

Hello apple developers I ama using macOS 15 beta 2 with M1 chip and I have 2 major issues first after update system data started using 74 gb of storage and my cpu newer gets down its always over 25%

Hello I've just got the M4 ipad pro 13 inch,256G and I've updated the ipad with ipadOS 18 for the greate new features, also my phone, I've noticed a few days after the installation my system data has been growing like crazy, it started around 120 G when I first noticed, but has grown to 185.88GB as of today, leaving my ipad with bearly any storage left, and the same case happened for my iphone 15 pro max, but when I check today iphone storage have went down, but Ipad is still having almost 200G of unknown stuff, Am I the only one getting this issue?

I’ve been trying to update my Macbook pro for a while now. I’m on version 10.14.6, I’ve been able to get away with not having enough storage for the newer updates but now it is unavoidable as my laptop is nearly unusable. My issue is that I do not have enough storage. I’ve done everything, deleted old files, cleared my trash, deleted apps, etc. Still, the two things taking up the majority of my storage are applications the laptop will not let me delete and the system itself. It’s become incredibly frustrating, especially since the majority of the apps that I can’t delete I don’t even use. Is there a way to bypass this? Or any other possible solution?

The presenter in this WWDC session from 2019 (https://asciiwwdc.com/2019/sessions/701) states: "So, now in macOS Catalina, executables that are denied access to files due to a lack of Full Disk Access approval are now prepopulated unchecked." I'm unable to make this work. Included is a minimal test app that tries to access a resource that would require Full Disk Access (FDA) and then opens Privacy & Security ... FDA in settings. When I run this from Xcode or manually run the app from Finder the test app does not appear in the list of apps in FDA. If I manually drag and drop the app from the build folder into the FDA window and enable it then the app is granted FDA access successfully. To be clear I understand that even the app is automatically populated in the FDA list the user will still need to toggle the switch to enable it. But I'd like to avoid making the user hunt down the app manually add it. Testing on macOS Sonoma 14.5. Xcode 15.4. Link to project file: https://akiairzavu3i3x4dmaya-public.s3.amazonaws.com/FDA+test.zip

Default behaviour of the macOS when interacting via Finder with a network share is to create thumbnails to provide a nice user experience. This behaviour is implemented by QuickLook framework. This triggers the full file download and quickly lead to cache using large disk space and even cache trashing. We can disable QuickLook selectively by injecting specially prepared .DS_Store file with instruction/setup to disable thumbnails in that directory but still degrades user's experience only in the network share ecosystem. Is there any way we can provide our own thumbnails or ask Finder to not download full file to generate the thumbnail?

In an app we can use FileManager.SearchPathDirectory.cachesDirectory (objc:NSCachesDirectory) to store files that could be recreated if necessary (and will be automatically deleted by iOS in cases of low disk memory). For app groups, there is a shared location that is automatically created as soon as we use containerURL(forSecurityApplicationGroupIdentifier:) (objc:containerURLForSecurityApplicationGroupIdentifier) : Library/Caches Is this cache directory (created by iOS) also gets automatically deleted by iOS in cases of low disk memory ? I also have more related questions : does this cache directory size count in the used disk space by the app displayed in the settings app ? is this cache directory (and same question for the top containerURL directory) saved in the cloud backups ? Does anyone have any information about this?

Hey all, my first time posting on these forums as I've finally become completely stumped. I'm working to implement a ShareLink to share data between users on my app, and have gotten pretty far (file saves, sends correctly), but am having significant issues getting the link to open in my app when sharing by email and not getting any action at all when tapping a shared link in iMessage. I'll go through my setup below: I have declared my new UTType, and created my new model which conforms to transferable here: struct transferTemplate: Codable { var id: UUID = UUID() var name: String = "TempName" var words: [String] = ["word1","word2"] } extension transferTemplate: Transferable { static var transferRepresentation: some TransferRepresentation { CodableRepresentation(contentType: .oltemplate) } } extension UTType { static var oltemplate: UTType { UTType(exportedAs: "com.overloadapp.oltemplate") } } I have declared the document type in my info.plist: <key>CFBundleDocumentTypes</key> <array> <dict> <key>CFBundleTypeName</key> <string>Template Session</string> <key>LSHandlerRank</key> <string>Owner</string> <key>LSItemContentTypes</key> <array> <string>com.overloadapp.oltemplate</string> </array> </dict> </array> I have declared the Exported Type Identifier: <key>UTExportedTypeDeclarations</key> <array> <dict> <key>UTTypeConformsTo</key> <array> <string>public.json</string> </array> <key>UTTypeDescription</key> <string>Template Session</string> <key>UTTypeIconFiles</key> <array/> <key>UTTypeIdentifier</key> <string>com.overloadapp.oltemplate</string> <key>UTTypeTagSpecification</key> <dict> <key>public.filename-extension</key> <array> <string>oltemplate</string> </array> <key>public.mime-type</key> <array> <string>application/json</string> </array> </dict> </dict> </array> I've also included the "LSSupportsOpeningDocumentsInPlace" boolean to True in the PLIST. My physical ShareLink setup is: @State private var transferred: transferTemplate = transferTemplate(name: "NameTemplate", words: ["One","Two"]) ... ShareLink(item: transferred, preview: SharePreview("Share your template", image: Image("tanLogo"))) Heres where the above code gets you: ShareLink brings up the share sheet and allows you to send the file (with the .oltemplate file extension). Sharing via iMessage will send a file, but within iMessage, the file cannot be opened at all. By email, the file can be opened but does not show any information. If you open the ShareSheet within the email attachment, you can manually choose to open the file in my app. If the file is saved to "Files", it will open my app when it is tapped (work as intended). Heres what I have tried to fix this: Modifying the Exported File Type "Conforms to" value. Ive used public.data, public.text, public.json. Including and not including the mime type I've scoured forums trying to solve this issue, and it doesn't seem like there is a clear cut solution for this issue. I appreciate any help you can provide! Please let me know if I can include any more helpful information.

Hello all, I am wondering if anyone can help me with writing a script that fully uninstalls an app with one click or can point me to a script already written please? So that when I click the script it uninstalls the app and leaves nothing behind. So when I click finder and use the search function with the name of the app, then click add and then name matches (input name of app) then click add and select system files are included, nothing comes up as the script has completely removed it from my system. I am Using Mac Mini M2 Pro 16gb ram and macOS Sonoma. Thank you

This is one of the files being looked for during initialization of the RoomPlan WWDC Demo package but it cannot be found since moving to IOS 18.0. it is not anyrhere since the upgrade. Reference is 2024-06-18 16:03:36.871062-0500 RoomPlanExampleApp[860:159744] [loading] Unable to create bundle at URL (file:///System/Library/CoreServices/SystemVersion.bundle): does not exist or not a directory (0)

Hi folks! I'm David Barsky and I work on rust-analyzer, which is the IDE for the Rust programming language. For a while, we've had issues with VS Code not sending the correct changed files to the language server (such as changing commits or rebasing), so I started using rust-analyzer's native, off-by-default file watching functionality that binds to FSEvent via the notify library. This has helped a bunch, but I'm not sure how completely reliable it is. Before I consider changing the default file watching behavior for our (many!) users, I wanted to check: is it possible to combine "walk &amp; watch" into a single, atomic operation? My goal is that upon getting a notification for a file change event, rust-analyzer can read the changed file and not worry about TOCTOU-esque conditions (rust-analyzer has a pretty robust incremental computation system, so we're able to invalidate changes pretty reliably). That being said, based off: this response from Quinn "The Eskimo!" about 8 years ago, and FSEventStreamCallback being a bit limited in the number of args, ...it seems like the answer appears to be "no". (I'm also familiar with Watchman, but it'd be great if the big pile of heuristics that Watchman uses were less necessary.)

I'm writing a virtual file system as my educational project (generic kernel extension). Currently, mostly everything is implemented, however, I'm having trouble using Finder search and tags. The results simply don't show up - despite I am having vnop_... calls to those files. The extended attributes are supported. Inodes are stable. Mmap is implemented. Vnop_ioctl returns KERN_SUCCESS (but no implementation). An important moment: Previously, the search didn't work at all. Researching the web has shown me, that Spotlight indexation and Finder search are tightly glued. So basically I was trying to enable support for spotlight, thinking that would be the source of the problem. I was receiving "Unknown indexing state". All those tricks with mdutil, launchd, manual and reindexation either were doing nothing or returning error. The problem was resolved FOR SONOMA by making by VFS appear as local one (adding flags for MNT_LOLCAL and MNT_DOVOLFS). This has changed the state from Unknown indexing state for spotlight to Indexing is disabled. No need to turn it on for me - I am interested only in search and tags, not the spotlight itself. Basically, whether spotlight recognises my driver as no-error, the Finder works correctly, even with indexation disabled. Whether on Monterey*, or Ventura, I get the same problem. However, neither system logs nor my driver show any kinds of errors. The spotlight simply returns error. Reindexation attempt via Security&Privacy returns "Unknown error occured". The metadata for Ventura and Monterey read attempt (mdls) returns "Unable to locate file", however returns a huge list for Sonoma. *Monterey and Ventura never have .Spotlight-V100 folder. No disable indexing files or other spotlight restrictions are present. No user space solutions seem to help. The kext is unsigned and running in an environment with SIP disabled and Security Mode reduced to Permissive. Maybe there some abstract rules for what is required on VFS side to be recognised okay'ish by Spotlight ? Or maybe something specific right for my case ? Any pointers and/or assistance would be greatly appreciated.