General: Forums subtopic: App & System Services > Core OS Forums tags: Files and Storage, Foundation, FSKit, File Provider, Finder Sync, Disk Arbitration, APFS Foundation > Files and Data Persistence documentation Low-level file system APIs are documented in UNIX manual pages File System Programming Guide archived documentation About Apple File System documentation Apple File System Guide archived documentation File system changes introduced in iOS 17 forums post On File System Permissions forums post Extended Attributes and Zip Archives forums post Unpacking Apple Archives forums post Creating new file systems: FSKit framework documentation File Provider framework documentation Finder Sync framework documentation App Extension Programming Guide > App Extension Types > Finder Sync archived documentation Managing storage: Disk Arbitration framework documentation Disk Arbitration Programming Guide archived documentation Mass Storage Device Driver Programming Guide archived documentation Device File Access Guide for Storage Devices archived documentation BlockStorageDeviceDriverKit framework documentation Volume format references: Apple File System Reference TN1150 HFS Plus Volume Format Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I attempted to mount a WebDAV server on macOS using Finder. The mount was successful when using the server's IPv4 address or hostname, but failed when using its IPv6 address. I also tested the mount using the NetFS framework API via NetFSMountURLSync. The results were consistent: the mount succeeded with the IPv4 address and hostname but failed when using the IPv6 address. While observing live logs via Console.app, I saw that the process NetAuthSysAgent produced the following error during the IPv6 mount attempt: GetServerInfo failed with error 5

My app for framing and arranging pictures from Photos on visionOS allows users to write the arrangements they create to .reality files using RealityKit entity.write(to:) that they then display to customers on their websites. This works perfectly on visionOS 2, but fails with a fatal protection error on visionOS 26 beta 1 and beta 2 when write(to:) attempts to write to its internal cache: 2025-06-29 14:03:04.688 Failed to write reality file Error Domain=RERealityFileWriterErrorDomain Code=10 "Could not create parent folders for file path /var/mobile/Containers/Data/Application/81E1DDC4-331F-425D-919B-3AB87390479A/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/RealityFileBundleZippingTmp_A049685F-C9B2-479B-890D-CF43D13B60E9/41453BC9-26CB-46C5-ADBE-C0A50253EC27." UserInfo={NSLocalizedDescription=Could not create parent folders for file path /var/mobile/Containers/Data/Application/81E1DDC4-331F-425D-919B-3AB87390479A/Library/Caches/com.GeorgePurvis.Photography.FrameItVision/RealityFileBundleZippingTmp_A049685F-C9B2-479B-890D-CF43D13B60E9/41453BC9-26CB-46C5-ADBE-C0A50253EC27.} Has anyone else encountered this problem? Do you have a workaround? Have you filed a feedback? ChatGPT analysis of the error and my code reports: Why there is no workaround • entity.write(to:) is a black box — you cannot override where it builds its staging bundle • it always tries to create those random folders itself • you cannot supply a parent or working directory to RealityFileWriter • so if the system fails to create that folder, you cannot patch it 👉 This is why you see a fatal error with no recovery. See also feedbacks: FB18494954, FB18036627, FB18063766

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?

I'm creating an App that can accepted PDFs from a shared context. I am using iOS, Swift, and UIKit with IOS 17.1+ The logic is: get the context see who is sending in (this is always unknown) see if I can open in place (in case I want to save later) send the URL off to open the (PDF) document and load it into PDFKit's pdfView.document I have no trouble loading PDF docs with the file picker. And everything works as expected for shares from apps like Messages, email, etc... (in which case URLContexts.first.options.openInPlace == False) The problem is with opening (sharing) a PDF that is sent from the Files App. (openInPlace == True) If the PDF is in the App's Document Folder, I need the Security scoped resource, to access the URL from the File's App so that I can copy the PDF's data to the PDFViewer.document. I get Security scoped resource access granted each time I get the File App's context URL. But, when I call fileCoordinator.coordinate and try to access a file outside of the App's document folder using the newUrl, I get an error. FYI - The newUrl (byAccessor) and context url (readingItemAt) paths are always same for the Files App URL share context. I can, however, copy the file to a new location in my apps directory and then open it from there and load in the data. But I really do not want to do that. . . . . . Questions: Am I missing something in my pList or are there other parameters specific to sharing a file from the Files App? I'd appreciate if someone shed some light on this? . . . . . Here are the parts of my code related to this with some print statements... . . . . . SceneDelegate func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { // nothing to see here, move along guard let urlContext = URLContexts.first else { print("No URLContext found") return } // let's get the URL (it will be a PDF) let url = urlContext.url let openInPlace = urlContext.options.openInPlace let bundleID = urlContext.options.sourceApplication print("Triggered with URL: \(url)") print("Can Open In Place?: \(openInPlace)") print("For Bundle ID: \(bundleID ?? "None")") // get my Root ViewController from window if let rootViewController = self.window?.rootViewController { // currently using just the view if let targetViewController = rootViewController as? ViewController { targetViewController.prepareToLoadSharedPDFDocument(at: url) } // I might use a UINavigationController in the future else if let navigationController = rootViewController as? UINavigationController, let targetViewController = navigationController.viewControllers.first as? ViewController { targetViewController.prepareToLoadSharedPDFDocument(at: url) } } } . . . . ViewController function I broke out the if statement for accessingScope just to make it easier for me the debug and play around with the code in accessingScope == True func loadPDF(fromUrl url: URL) { // If using the File Picker / don't use this // If going through a Share.... we pass the URL and have three outcomes (1, 2a, 2b) // 1. Security scoped resource access NOT needed if from a Share Like Messages or EMail // 2. Security scoped resource access granted/needed from 'Files' App // a. success if in the App's doc directory // b. fail if NOT in the App's doc directory // Set the securty scope variable var accessingScope = false // Log the URLs for debugging print("URL String: \(url.absoluteString)") print("URL Path: \(url.path())") // Check if the URL requires security scoped resource access if url.startAccessingSecurityScopedResource() { accessingScope = true print("Security scoped resource access granted.") } else { print("Security scoped resource access denied or not needed.") } // Stop accessing the scope once everything is compeleted defer { if accessingScope { url.stopAccessingSecurityScopedResource() print("Security scoped resource access stopped.") } } // Make sure the file is still there (it should be in this case) guard FileManager.default.fileExists(atPath: url.path) else { print("File does not exist at URL: \(url)") return } // Let's see if we can open it in place if accessingScope { let fileCoordinator = NSFileCoordinator() var error: NSError? fileCoordinator.coordinate(readingItemAt: url, options: [], error: &error) { (newUrl) in DispatchQueue.main.async { print(url.path()) print(newUrl.path()) if let document = PDFDocument(url: newUrl) { self.pdfView.document = document self.documentFileName = newUrl.deletingPathExtension().lastPathComponent self.fileLoadLocation = newUrl.path() self.updateGUI(pdfLoaded: true) self.setPDFScale(to: self.VM.pdfPageScale, asNewPDF: true) } else { print("Could not load PDF directly from url: \(newUrl)") } } } if let error = error { PRINT("File coordination error: \(error)") } } else { DispatchQueue.main.async { if let document = PDFDocument(url: url) { self.pdfView.document = document self.documentFileName = url.deletingPathExtension().lastPathComponent self.fileLoadLocation = url.path() self.updateGUI(pdfLoaded: true) self.setPDFScale(to: self.VM.pdfPageScale, asNewPDF: true) } else { PRINT("Could not load PDF from url: \(url)") } } } } . . . . Other relevant pList settings I've added are: Supports opening documents in place - YES Document types - PDFs (com.adobe.pdf) UIDocumentBrowserRecentDocumentContentTypes - com.adobe.pdf Application supports iTunes file sharing - YES And iCloud is one for Entitlements with iCloud Container Identifiers Ubiquity Container Identifiers . . . . Thank you in advance!. B

In my app the user can select a source folder to be synced with a destination folder. The sync can also happen in response to a change in the source folder detected with FSEventStreamCreate. If the user unzips an archive in the source folder and the sync process begins before the unzip operation has completed, the sync can fail because of a "Permission denied" error. I assume this is related to the posix permissions of the extracted folder being 420 during the unzip operation and (in my case) 511 afterwards. Is there a way to detect than an unzip operation is in progress and wait until it has completed? I thought that using NSFileCoordinator would solve this issue, but unfortunately it's not the case. Since an unzip operation can last any amount of time, it's not ideal to just delay a sync by a fixed number of seconds and let the user deal with any error if the unzip operation takes longer. let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true if openPanel.runModal() == .cancel { return } let url = openPanel.urls[0].appendingPathComponent("extracted", isDirectory: false) var error: NSError? NSFileCoordinator(filePresenter: nil).coordinate(readingItemAt: url, error: &error) { url in do { print(try FileManager.default.attributesOfItem(atPath: url.path).sorted(by: { $0.key.rawValue < $1.key.rawValue }).map({ ($0.key.rawValue, $0.value) })) try FileManager.default.contentsOfDirectory(at: url, includingPropertiesForKeys: nil) } catch { print(error) } } if let error = error { print("file coordinator error:", error) }

I see this in Tahoe Beta release notes macOS now supports the Apple Sparse Image Format (ASIF). These space-efficient images can be created with the diskutil image command-line tool or the Disk Utility application and are suitable for various uses, including as a backing store for virtual machines storage via the Virtualization framework. See VZDiskImageStorageDeviceAttachment. (152040832) I'm developing a macOS app using the Virtualization framework and need to create disk images in the ASIF (Apple Sparse Image Format) to make use of the new feature in Tahoe Is there an official way to create/resize ASIF images programmatically using Swift? I couldn’t find any public API that supports this directly. Any guidance or recommendations would be appreciated. Thanks!

Apple claims you can share files to the Xcode simulator. The first step works (share-to-simulator context menu exists). But when you execute this nothing happens. This contradicts the apple documentation which states: a Simulator opens the Files app, and lets you select where to save the files. If I instead try to drag and drop between the Mac and the simulator's file manger I receive the message: Simulator device failed to open file:///Users/me/Downloads/Exchange/ExampleExport.json. So what is the trick? Is there a missing authorisation that I need to set in the simulator's settings for example? MacOS: 15.5 Xcode: 16.4 (16F6) ... the latest stable Apple versions.

Dear Apple Support, We are experiencing a critical issue affecting some of our macOS users during application updates via DMG. In certain cases, when users attempt to update the app by dragging it from the mounted DMG to the /Applications folder (replacing the old version), the application becomes corrupted. Users receive an error indicating that the app cannot be opened. On retry, they are met with an error stating that the app cannot be overwritten. Upon inspection, the resulting application bundle is incomplete and contains only the following structure: . └── Contents └── CodeResources The only known workaround is to completely remove the existing app from /Applications before copying the new version — this resolves the issue consistently. We’ve observed this issue in the field with increasing frequency, which negatively impacts user trust. We also found similar reports from other developers (e.g., https://github.com/warpdotdev/Warp/issues/5492), suggesting a broader issue. Questions: What could be the underlying cause of this behavior on macOS (e.g., MDM, security policies, filesystem behavior)? Are there any recommended practices to prevent or mitigate this issue when updating apps via DMG? We would appreciate any guidance or clarification you can provide. Best regards, Ivan Poluianov

Seems like converting groups into folders looks like a great way to clear up the project file and reduce merge conflicts for large teams, started trying it today and it even lead us to find some untracked/unused files in the project. This structure also seems to be the default now after Xcode 16. The question is, are there any downsides to converting groups to folders, the one ones that come to mind is losing Xcode virtual file ordering, which is no biggie. If you have an "enterprise level app" would love to hear your experience if your team decided to convert to a folder structure.

Seems like converting groups into folders looks like a great way to clear up the project file and reduce merge conflicts for large teams, started trying it today and it even lead us to find some untracked/unused files in the project. This structure also seems to be the default now after Xcode 16. The question is, are there any downsides to converting groups to folders, the one ones that come to mind is losing Xcode virtual file ordering, which is no biggie. If your have an "enterprise level app" would love to hear your experience if your team decided to convert to a folder structure.

what is that makes the TLS be the TLS/SErver ?

Hello Apple Developer Community, I'm encountering a persistent issue while attempting to create a new partition on my Mac, and I'm hoping to get some assistance or insights from anyone who might have faced a similar problem. Issue Description: I'm trying to partition my internal drive. I initially used Disk Utility.app for this purpose. The partitioning process starts, but consistently freezes when it reaches approximately 10-20% completion. I've left it running overnight (for over 9 hours), but there was no progress, and the application remained unresponsive at that percentage. After several attempts with Disk Utility, I decided to try using the diskutil commands in Terminal to see if that would yield a different result. I used commands such as diskutil apfs resizeContainer and diskutil partitionDisk. Unfortunately, these commands also result in the same behavior: the process starts, reports progress up to about 10-20%, and then completely freezes without any further output or completion, requiring me to force-quit Terminal. Mac Model: Apple M4 Pro MacOS Version: Sequoia 15.6

Hi All, I searched for this feedback but didn't see it, so apologies if this has been covered by another thread. Exploring the new camera app, It doesn't seem to recognize that external storage has been connected, so the additional features that allow ProRes high frame rates will throw an error dialog stating that "to use this you need external storage" even when external storage is connected. Using the Files app, the phone recognizes the storage, and this is something I can do with this external storage device on the previous version of IOS. It is clear that this release of the camera has been rewritten significantly since the last version. Is it possible that this is an oversight, a bug, or just functionality that has not been completed? Interested if anybody else is seeing this, or if it is just my setup.

I am developing an Apple app that has to download 1000s of MP4 files between 5 and 150MB each at one time (can take an hour or more - is OK). I use Apple's file picker to select the files, and then it freezes and I cannot download anything. I had this working a few months ago but now I cannot get it to work. Can someone give me some advice please?

We are seeing a kernel panic in nfsd when using vagrant synced folders. The issue started with macOS 15.4 and still occurs with macOS 15.5. It’s 100% reproducible when bringing up a new vagrant environment. The kernel panic does not occur when using smb instead of nfs. https://developer.hashicorp.com/vagrant/docs/synced-folders/nfs Other people have reported a similar issue when using nfs with Docker. https://github.com/docker/for-mac/issues/7664 I filed this under FB17853906. I spoke with an engineer at the Apps &amp; Services WWDC lab and they recommended I post here to make sure the bug gets looked at and routed to the correct team.

I work on EdenFS, an open-source Virtual Filesystem that runs on macOS, Linux, and Windows. My team is very interested in using FSKit as the basis for EdenFS on macOS, but have found the documentation to be lacking and contains some mixed messaging on the future of FSKit. Below are a few questions that don’t seem to be fully covered by the current documentation: Does FSKit support process attribution? Each FUSE request provides a requester Process ID (and other information) through the fuse_in_header structure. Does FSKit pass similar information along for each request? Does the reclaimItem API function similarly to FUSE’s forget operation? If not, what are the differences? See #1 below for why forget/reclaimItem matters to us. Is Apple committed to releasing and supporting FSKit? Is there any timeline for release that we can plan around? Does FSKit have known performance/scalability limitations? We provide alternative methods that clients can use to make bulk requests to EdenFS, but some clients will necessarily be unable to use those and stress the default filesystem APIs. Throughput (on the order of tens of thousands of filesystem requests per minute) and request size are the main concerns, followed closely by directory size restrictions. Why we’re interested in FSKit As mentioned above, my team supports EdenFS on 3 platforms. On Linux, we utilize FUSE; on Windows, we utilize ProjectedFS; and on macOS, we’ve utilized a few different solutions in the past. We first utilized the macFUSE kext, which was great while it lasted. Due to (understandable) changes in supporting kernel extensions, we were forced to move to NFS version 3. NFS has been lackluster in comparison (and our initial investigations show that NFS version 4(.2) would be similar). We have had numerous scalability and reliability issues, some listed below: NFS does not provide a forget API similar to FUSE. EdenFS is forced to remember all file handles that have been loaded because the kernel never informs us when all references to that file handle have been dropped. We can hackily infer that a file handle should never be referenced again in some cases, but a large number of file handles end up being remembered forever. Many of our algorithms scale with the number of file handles that Eden has to consider, and therefore performance issues are inevitable after some time. NFS does not provide information about clients (requesters). We cannot tell which processes are sending EdenFS requests. This attribution is important due to issue #1. We are forced to work with tool owners to modify their applications to be VFS-friendly. If we can’t track down which tools are behaving poorly, they will continue to load excess file handles and cause performance issues. NFS “Server connections interrupted:” dialog during heavy load. Under heavy load, either EdenFS or system-wide, our users experience this dialog pop-up and are confused as to how they should respond (Ignore or Disconnect All). They become blocked in their work, and will be further blocked if they click “Disconnect All” as that unmounts their EdenFS mount. This forces them to restart EdenFS or reboot their laptop to remediate the issue. The above issues make us extremely motivated to use FSKit and partner with Apple to flesh out the final version of the FSKit API. Our use case likely mirrors what other user-space filesystems will be looking for in the FSKit API (albeit at a larger scale than most), and we’re willing to collaborate to work out any issues in the current FSKit offerings.

I am developing a background application that acts as a metadata server under MacOS written in Swift. Sandboxed clients prompt the user to select URLs which are passed to the server as security scoped bookmarks via an App Group and the metadata will be passed back. I don't want the I/O overhead of passing the complete image file data to the server. All the variations I have tried of creating security scoped bookmarks in the client and reading them from the server fail with error messages such as "The file couldn’t be opened because it isn’t in the correct format." Can anyone guide me in the right direction or is this just not possible?

Hi, I'm working with the new FSKit framework and have successfully implemented a custom file system using FSUnaryFileSystem. Mounting the file system via Terminal works perfectly — I can create, delete, and browse files and directories as expected. Since /Volumes is protected on modern macOS systems, I cannot mount my file system there directly. Instead, I mount it into a different writable directory (e.g., /tmp/MyFS) and then create a symbolic link to it in a user-visible location such as ~/Downloads/MyFS. Finder does see the symlink and displays it with a "Volume" icon, but clicking it results in an error — it cannot be opened. It seems like Finder does not treat the symlinked mount as a fully functional volume. Is there a proper way to register or announce a FSKit-mounted file system so that Finder lists it as a real volume and allows access to it? Are there additional steps (APIs, notifications, entitlements, or Info.plist keys) required to integrate with Finder? Any insight would be greatly appreciated. Thanks!

We are experimenting with FileProvider on MacOS, we want to set ACL policy restriction on a folder and the same policy needs to be applied down to its children. To achieve this currently we are setting corresponding NSFileProviderItemCapabilities on parent folder and recursively iterate over all of its children and set the capability on each individual child items. GOAL: We expect the root's ACL policy to be implicitly percolated down to its children without explicitly being iterated over them and setting it individually. From our research, we couldn't find any policy that can help us achieve the above goal. If there are any such provisions in FileProvider, please guide us to them.