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. Put your thread in the App & System Services > Core OS topic area and tag it with Files and Storage. 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 five different file system permission mechanisms: Traditional BSD permissions Access control lists (ACLs) App Sandbox Mandatory access control (MAC) Endpoint Security (ES) 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. Finally, Endpoint Security allows third-party developers to deny file system operations based on their own criteria. This post offers explanations and advice about all of these mechanisms. 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 might 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) App bundle protection (macOS 13 and later) App container protection (macOS 14 and later) App group container protection (macOS 15 and later) Data Vaults (see below) and other internal techniques used by various macOS subsystems 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 more information about app and app group container protection, see the links in Trusted Execution Resources. For more information about app groups in general, see App Groups: macOS vs iOS: Working Towards Harmony 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 Settings 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. Endpoint Security Endpoint Security (ES) is a general mechanism for third-party products to enforce custom security policies on the Mac. An ES client asks ES to send it events when specific security-relevant operations occur. These events can be notifications or authorisations. In the case of authorisation events, the ES client must either allow or deny the operation. As you might imagine, the set of security-relevant operations includes file system operations. For example, when you open a file using the open system call, ES delivers the ES_EVENT_TYPE_AUTH_OPEN event to any interested ES clients. If one of those ES client denies the operation, the open system call fails with EPERM. For more information about ES, see the Endpoint Security framework documentation. Revision History 2025-11-04 Added a discussion of Endpoint Security. Made numerous minor editorial changes. 2024-11-08 Added info about app group container protection. Clarified that Data Vaults are just one example of the techniques used internally by macOS. Made other editorial changes. 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 app 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: 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 Building a passthrough file system sample code 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"

macOS has the clonefile*() calls to create a new file that's a clone of an existing file, but is it possible to clone only parts of an existing file into a different existing file? Linux (FICLONERANGE) and Windows (FSCTL_DUPLICATE_EXTENTS_TO_FILE) both provide this functionality. I previously filed FB12737014 with this request.

I'm debugging the following kernel panic to do with my custom filesystem KEXT: panic(cpu 0 caller 0xfffffe004cae3e24): [kalloc.type.var4.128]: element modified after free (off:96, val:0x00000000ffffffff, sz:128, ptr:0xfffffe2e7c639600) My reading of this is that somewhere in my KEXT I'm holding a reference 0xfffffe2e7c639600 to a 128 byte zone that wrote 0x00000000ffffffff at offset 96 after that particular chunk of memory had been released and zeroed out by the kernel. The panic itself is emitted when my KEXT requests the memory chunk that's been tempered with via the following set of calls. zalloc_uaf_panic() __abortlike static void zalloc_uaf_panic(zone_t z, uintptr_t elem, size_t size) { ... (panic)("[%s%s]: element modified after free " "(off:%d, val:0x%016lx, sz:%d, ptr:%p)%s", zone_heap_name(z), zone_name(z), first_offs, first_bits, esize, (void *)elem, buf); ... } zalloc_validate_element() static void zalloc_validate_element( zone_t zone, vm_offset_t elem, vm_size_t size, zalloc_flags_t flags) { ... if (memcmp_zero_ptr_aligned((void *)elem, size)) { zalloc_uaf_panic(zone, elem, size); } ... } The panic is triggered if memcmp_zero_ptr_aligned(), which is implemented in assembly, detects that an n-sized chunk of memory has been written after being free'd. /* memcmp_zero_ptr_aligned() checks string s of n bytes contains all zeros. * Address and size of the string s must be pointer-aligned. * Return 0 if true, 1 otherwise. Also return 0 if n is 0. */ extern int memcmp_zero_ptr_aligned(const void *s, size_t n); Normally, KASAN would be resorted to to aid with that. The KDK README states that KASAN kernels won't load on Apple Silicon. Attempting to follow the instructions given in the README for Intel-based machines does result in a failure for me on Apple Silicon. I stumbled on the Pishi project. But the custom boot kernel collection that gets created doesn't have any of the KEXTs that were specified to kmutil(8) via the --explicit-only flag, so it can't be instrumented in Ghidra. Which is confirmed as well by running: % kmutil inspect -B boot.kc.kasan boot kernel collection at /Users/user/boot.kc.kasan (AEB8F757-E770-8195-458D-B87CADCAB062): Extension Information: I'd appreciate any pointers on how to tackle UAFs in kernel space.

Hi all: We use MDM profile to apply Full Disk Access permission for app on macOS, After profile deployed successfully, The App can get correct Full Disk Access permission, However, on "Privacy & Security" UI, we found that our app shown disabled, see as however, on some macOS, it showed correctly as below The issue happened on different os version. macOS 15 and macOS 26 When the item shown as disable, even reboot computer several times, the issue still persist. Thanks for your help

I have an iPad app which is trying to support document renaming in the title bar. For IOS 17+ I set the renameDelegate to the document instance and it works fine. For IOS 16 I need to create an actual delegate, but no matter how I structure the code it fails with a permission error: Rename failed: “original_file_name” couldn’t be moved because you don’t have permission to access “Desktop”. It seems to always happen accessing the parent directory. I have tried using the file coordinator as well with the same result. It seems impossible to implement unless the callback contains a security permissioned url for the parent directory. Is there anyway to make this work in IOS 16 in the sandbox? Do I have to create my own rename functionality using a FilePicker? Seems like this should be built in like it is in MacOS, or even IOS17+ Here is the code: extension DocumentWindow : UINavigationItemRenameDelegate { func navigationItem(_ navigationItem: UINavigationItem, didEndRenamingWith title: String) { guard let doc = document else { return } let oldURL = doc.fileURL let newURL = oldURL.deletingLastPathComponent() .appendingPathComponent(title) .appendingPathExtension(oldURL.pathExtension) if newURL == oldURL { return } let access = oldURL.startAccessingSecurityScopedResource() defer { if access { oldURL.stopAccessingSecurityScopedResource() }} do { try FileManager.default.moveItem(at: oldURL, to: newURL) } catch { print("Rename failed: \(error.localizedDescription)") } // // // 1. Jump to a background queue to avoid the deadlock // DispatchQueue.global(qos: .userInitiated).async { // let coordinator = NSFileCoordinator(filePresenter: doc) // var error: NSError? // // // coordinator.coordinate(writingItemAt: oldURL, error: &error) { outOld in // do { // // 2. Perform the actual rename // try FileManager.default.moveItem(at: outOLD, to: newURL) // } catch { // print("Rename failed: \(error.localizedDescription)") // } // } // // if let error = error { // print("Coordination error: \(error.localizedDescription)") // } // } } // 2. Optional: Validation (e.g., prevent empty names) func navigationItem(_ navigationItem: UINavigationItem, shouldEndRenamingWith title: String) -> Bool { return !title.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty } }

Hi, I have a app group registered in mac os app called gorup.com.company.app and i am saving the key/values in userdefaults to this with suitname. within the mac os app the group userdedaults write/read are working fine. I have a switt cli app with same app group registered in the code signing entitilement for the swit cli app. trying to read the group user default key value registered in mac os app in swift cli app returning no value. this was working fine with macOS 26. Is there some changes have been made in macos 27 in regaard to this?

Environment macOS Tahoe 26.2 (Build 25C56) Also tested with macOS 26.3 Developer Beta - same issue Windows Server 2022 DFS namespace Connection via Tailscale VPN (but also tested with direct network connection) Problem Description When connecting to a Windows Server 2022 DFS namespace from macOS Tahoe, the root namespace connects successfully, but all subfolders appear empty and return either: "No route to host" "Authentication error" (alternates inconsistently) Steps to Reproduce Set up a Windows Server 2022 DFS namespace (e.g., \\domain.com\fs) Add DFS folder targets pointing to file servers (e.g., \\fs02\share, \\fs03\share) From macOS Tahoe, connect via Finder: smb://domain.com/fs Root namespace mounts successfully Issue: Subfolders show as empty or return "No route to host" when accessed What Works Direct SMB connections to individual file servers work perfectly: smb://10.118.0.26/sharename ✓ smb://fs02.domain.com/sharename ✓ Same DFS namespace works from Windows clients Same DFS namespace worked from macOS Sonoma 14.4+ What Doesn't Work DFS referrals from macOS Tahoe 26.x to any DFS folder target The issue persists regardless of: Kerberos vs NTLM authentication SMB signing enabled/disabled on servers Various /etc/nsmb.conf configurations DNS resolution (tested with IPs and FQDNs) Historical Context A similar DFS referral bug existed in macOS Sonoma 14.0 and was fixed in 14.1. This appears to be a regression in macOS Tahoe 26. Request Please investigate the DFS referral handling in macOS Tahoe. The fact that direct SMB connections work while DFS referrals fail suggests an issue specifically in the DFS referral processing code. Feedback Assistant report will be filed separately.

Hi, we are looking for a solution to install an extension to Microsoft PowerPoint app in a way that's compatible with the new macOS 15 behavior for Group Containers content. PowerPoint extensions Microsoft PowerPoint can be extended by PowerPoint Add-in (.ppam) files. These files must be installed in the app's container at this location: ~/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Add-Ins.localized/ The PPAM file must be also registered in the MicrosoftRegistrationDB.reg file which is a sqlite database stored at this location: ~/Library/Group Containers/UBF8T346G9.Office/MicrosoftRegistrationDB.reg These locations can be access by non-sandboxed app on macOS 14 and earlier. Slido integration Our Slido app for macOS is distributed outside the Mac App Store, it is not sandboxed and it signed and notarized. The Slido app will install the PPAM file to the documented location and register it in the database. This installation did not require additional user approval on macOS 14 and older. With changes to macOS 15, a new permissions dialog is shown with this text: "Slido" would like to access data from other apps. This will allow Slido to integrate with Microsoft PowerPoint app. [Don't Allow] [Allow] We understand this is a security feature, yet we would like to make the experience for customers much better. As users are able to save PPAM files to the location by themselves without additional permissions, they expect the Slido app would be able to do so as well when run in the user context. Slido installs its files to this location: ~/Library/Group Containers/UBF8T346G9.Office/User Content.localized/Add-Ins.localized/SlidoAddin.localized/ Can we obtain com.apple.security.temporary-exception.files.home-relative-path.read-write to the SlidoAddin.localized folder? Even when we are different TeamID? Can we obtain a user permission which will be persisted so next time the Slido app can verify its files and uninstall them without further prompts? By having access to the SlidoAddin.localized folder our app would not be able to access any other data in Microsoft PowerPoint. We understand accessing the MicrosoftRegistrationDB.reg file is more sensitive and getting exception to access it would not be feasible. But we are trying to find out our options to make the experience seamless as that's what is expected by our customers on Apple platform. I am thankfully for any guidance and constructive feedback. Jozef, Tech Leader at Slido integrations team

I'll try to ask a question that makes sense this time :) . I'm using the following method on NSFileManager: (BOOL) getRelationship:(NSURLRelationship *) outRelationship ofDirectoryAtURL:(NSURL *) directoryURL toItemAtURL:(NSURL *) otherURL error:(NSError * *) error; Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'. So this method falsely returns NSURLRelationshipSame for different directories. One is empty, one is not. Really weird behavior. Two file path urls pointing to two different file paths have the same NSURLFileResourceIdentifierKey? Could it be related to https://developer.apple.com/forums/thread/813641 ? One url in the check lived at the same file path as the other url at one time (but no longer does). No symlinks or anything going on. Just plain directory urls. And YES calling -removeCachedResourceValueForKey: with NSURLFileResourceIdentifierKey causes proper result of NSURLRelationshipOther to be returned. And I'm doing the check on a background queue.

Hello! Some colleagues and work on Jujutsu, a version control system compatible with git, and I think we've uncovered a potential lock contention bug in either APFS or the Darwin kernel. There are four contributing factors to us thinking this is related to APFS or the Kernel: jj's testsuite uses nextest, a test runner for Rust that spawns each individual test as a separate process. The testsuite slowed down by a factor of ~5x on macOS after jj started using fsync. The slowdown increases as additional cores are allocated. A similar slowdown did not occur on ext4. Similar performance issues were reported in the past by a former Mercurial maintainer: https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/. My friend and colleague André has measured the test suite on an M3 Ultra with both a ramdisk and a traditional SSD and produced this graph: (The most thorough writeup is the discussion on this pull request.) I know I should file a feedback/bug report, but before I do, I'm struggling with profiling and finding kernel/APFS frames in my profiles so that I can properly attribute the cause of this apparent lock contention. Naively, I ran xctrace record --template 'Time Profiler' --output output.trace --launch /Users/dbarsky/.cargo/bin/cargo-nextest nextest run, and while that detected all processes spawned by nextest, it didn't record all processes as part of the same inspectable profile and didn't really show any frames from the kernel/APFS—I had to select individual processes. So I don't waste people's time and so that I can point a frame/smoking gun in the right system, how can I can use instruments to profile where the kernel and/or APFS are spending its time? Do I need to disable SIP?

I have the following code - you can see where I had to comment out the code on the simulator. Is this expected? The code works perfectly fine on a physical iPad device. Is it documented somewhere that NSFileVersion doesn't work with non-local versions in the simulator? func loadPreviewDirectly( from version: NSFileVersion, completion: @escaping (CIImage?) -> Void ) { let versionURL = version.url let access = versionURL.startAccessingSecurityScopedResource() defer { if access { versionURL.stopAccessingSecurityScopedResource() } } print("Loading version: \(version.persistentIdentifier) | Local: \(version.hasLocalContents)") // 1. SIMULATOR CATCH: If running in simulator and the file is missing, it will never download. #if targetEnvironment(simulator) if !version.hasLocalContents { print("⚠️ iOS Simulator cannot materialize remote NSFileVersions. Fallback triggered.") // You cannot test remote versions here. For testing on the simulator, // test with a version where version.hasLocalContents == true (created locally in this session). DispatchQueue.main.async { completion(nil) } return } #endif let coordinator = NSFileCoordinator() var coordinationError: NSError? // 2. Wrap everything in a sequential reading coordination coordinator.coordinate(readingItemAt: versionURL, options: [], error: &coordinationError) { readURL in let image = CIImage(contentsOf: readURL) DispatchQueue.main.async { completion(image) } } if let error = coordinationError { DispatchQueue.main.async { self.errorMessage = error.localizedDescription completion(nil) } } }

I have a UGreen NAS. My app can read the contents of a folder on the NAS from macOS, but it cannot read the contents of a folder from iOS. I bring up a UIDocumentPickerViewController(forOpeningContentTypes: [UTType.folder], asCopy: false). I can pick a folder on the iPad’s internal storage, and successfully enumerate its contents. On the UGreen, I can pick a folder, but the content enumeration always returns zero items (no errors). Enumeration of the UGreen works from macOS. It also works on the iPad when connecting to a Mac mini, or a Synology NAS. . Files.app is able to view the UGreen folder and its contents. Oddly, my app cannot enumerate the contents, but it IS able to write a file to that UGreen folder. Since Files.app can enumerate and I can write to the UGreen folder (and I can enumerate contents on other servers) - how can I get the enumeration to work? Feedback is FB22955130

There is an API in NSFilePresenter called primaryPresentedItemURL. It is implemented on macOS, but not iOS or Catalyst. I want to use it to write an XMP sidecar file next to original image files. However, because it’s not implemented on iOS or Catalyst, I cannot do this. The only workaround I have found is to ask the user for access to the whole folder. This, of course, is bad from a user privacy / security standpoint, especially as it gives the app access not only to the folder contents, but all subfolders. Can you give me a better workaround, or implement the API on iOS and Catalyst? Feedback Number is FB22771292

What is the recommended way to determine whether an item can be moved to Finder Trash on a given volume? If no Trash directory is available, is user confirmation followed by immediate deletion the expected path? For which common volume types is a Trash directory unavailable? Thanks!

What is URLResourceKey.documentIdentifierKey intended to identify compared with fileIdentifierKey? Is it expected to persist across save/replace operations, rename, move, app relaunch, or unmount/remount? Thanks!

In my sandboxed app, if a bookmarked network source is unavailable, is resolving the source/root security-scoped bookmark the recommended way to way to trigger a remount of the network volume? Thanks!

Any chances of URL-style mounts (myfs://blah) being back ported to macOS 15? They have several upsides compared to volume-based mounts (/tmp/my-fake-vol.dmg => /dev/disk4 => /Volumes/my-vfs) including unprivileged mounts, but also, it feels a bit early still to set a minimum requirement of macOS 26 for end-user applications.

For network volumes where volumeUUIDStringKey is nil, is there any other stable volume/share identifier suitable for namespacing file IDs? More generally, what should I use as the volume identity component when persisting file identifiers for network files? If volumeSupportsPersistentIDsKey == true on a network volume, can fileIdentifierKey / systemFileNumber be expected to survive unmount/remount, reconnect, and server restart? Does fileIdentifierKey on network volumes represent the same kind of filesystem identity as it does on local/removable volumes? Thanks!

Are there new file-system APIs in macOS 27 that improve performance when writing frequent real-time monitoring logs?

We are deploying Mac mini nodes in a headless server environment. FileVault is required for security compliance, but the boot-time unlock requires physical user interaction, which is incompatible with unattended server deployments. We understand that FileVault by design requires an external actor to provide the unlock secret. What is the supported mechanism for an external trusted service to supply that secret automatically at boot — similar to BitLocker + TPM + network unlock on Windows — without requiring physical access to the machine?

When implementing kernel offloaded IO, FSExtentType.zeroFill (https://developer.apple.com/documentation/fskit/fsextenttype/zerofill) indicates it should only be used for sparse files to represent ranges that haven’t been allocated yet. What if I have ranges that have been allocated disk space but not yet zeroed out, and have some kind of marker that indicates that those ranges aren’t initialized (and thus should be interpreted as zeroes)? Is it fine to use zeroFill to represent this case?