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 The exact list of file system locations protected by MAC is not documented and, as illustrated by the list above, can change over time. If your process runs into a MAC check the system might prompt the user to grant the process access, or it might just fail the access. If the user grants the process access, the system might only grant that access for this specific process, or it might persist that access for the program that this process is running. The exact behaviour varies based on the specific location in the file system and can also vary between different versions of macOS. 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. Originally ES clients operated system wide. macOS 27 introduced a new mechanism, es_new_descendants_client, that allows an ES client to operate on the process hierarchy rooted at the client itself. Revision History 2026-09-18 Extended the Endpoint Security section to discuss es_new_descendants_client. Clarified the scope of MAC. 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"

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

We are developing a security-sensitive local execution system on macOS and need clarification about supported Darwin/APFS filesystem APIs. Our requirement is to create an additional directory entry (hard link) for an existing, authorized regular-file object while retaining its original directory entry. SECURITY REQUIREMENTS The source file has already been opened and its identity verified using a held file descriptor and fstat(). The source must remain the exact same filesystem object (device/inode identity), not a copy or clone. An attacker operating under the same user account may concurrently rename, unlink, or replace the source pathname. The publication operation must not create a hard link to, or otherwise mutate, a substituted source object. The new link must be created within an already-open, authorized destination directory. Unsupported configurations must be detectable before attempting a potentially unsafe publication mutation. The original source directory entry must remain present. We have reviewed linkat(), fclonefileat(), rename-based approaches, filesystem flags, and directory-descriptor-relative operations. The difficulty is that linkat() identifies its source through a pathname. Holding a verified source file descriptor does not appear to guarantee that the pathname still identifies the same object when linkat() performs the mutation. A subsequent fstat() or pathname identity check cannot undo an already-created link to a substituted object. QUESTIONS Does macOS provide a supported public API that creates an additional hard link directly from an existing open file descriptor, without resolving a replaceable source pathname? Does Darwin support an equivalent of Linux linkat() with AT_EMPTY_PATH, or another documented descriptor-based source-linking mechanism? Can any supported macOS filesystem API guarantee that a concurrent same-user replacement of the source directory entry cannot redirect the publication mutation? If descriptor-based hard linking is unavailable, is there a supported filesystem or namespace protection mechanism that prevents same-owner source-entry substitution throughout the operation? Do AT_SYMLINK_FOLLOW, AT_SYMLINK_NOFOLLOW, AT_RESOLVE_BENEATH, AT_RESOLVE_NOFOLLOW_ANY, or related Darwin flags provide any guarantee that the linked source is the previously verified inode rather than a replacement? Are the relevant guarantees dependent on macOS version, APFS volume configuration, filesystem flags, privileges, or entitlements? Is there a supported way to determine whether the required operation and guarantees are available before performing the publication mutation? We are specifically interested in documented and supported APIs, their identity guarantees, availability conditions, and limitations. We are not seeking a workaround based solely on comparing file identities after the operation, copying/cloning the file, or assuming that same-user pathname replacement cannot occur. If no supported public API provides these guarantees, confirmation of that limitation would also be helpful. Thank you.

I've noticed that when an SMB link stalls, in a scenario such as a time machine network backup, due to any cause (NAS disk or network sleep, Wi-Fi roam/drop), in-flight SMB I/O blocks uninterruptibly instead of completing or returning an error. This unfortunately leaves APFS with outstanding I/O against a backing store that will neither finish nor fail. This results in any sort of network stall turning into a kernel panic, since nothing in the I/O path enforces a timeout or error return. I've experienced this since Sequoia, and is still present in Golden Gate. I'm sure if this is the best place to post this, but I have not been able to find a workaround to-date to prevent this from consistently happening. When I open my MacBook in the morning there's a 50/50 chance that it kernel panicked overnight. I also filed a feedback (FB24460131), but have heard no response.

Feedback ID: FB25090184 I've been tracking recurring fseventsd memory growth and slow file-change notifications on macOS 26.7.1 (25G241), with massive Bazel build trees. There seems to be a repeatable boundary inside event-table cleanup. I may be missing another reset path, but the live observations match the disassembly closely. In fseventsd 1413.160.2, ARM64E UUID CDD7E21B-7F60-3DD4-AA03-8B36745DC0F4, cleanup at RVA 0x4604 uses a 32-bit scan cursor at table+0x14. The guard at 0x464c/0x4650 skips scanning above 0xfffffdff. Each complete pass advances by 512. Bucket indexing masks the cursor, but the stored cursor keeps increasing. Starting at zero, it stops at 0xfffffe00 after 8388607 complete passes. Table resize resets the cursor. Two observed October 3 episodes reached exactly that value, accumulated zero-reference records, and recovered without a restart when the table doubled. The resize loop rehashes records rather than freeing them, so resumed cleanup after the reset seems to explain the recovery. The reviewed resize limit is 262144 buckets. On October 6, after the table reached that size, the next cursor exhaustion persisted. Physical footprint grew from 26.6 MB to 2.31 GB in about six minutes, and fresh FSEvents probes reached an 8-second timeout. A bounded walk found 199944 zero-reference records among 200000 visited. The walk was partial and unsuspended, with linkage errors; that is not a whole-heap count. Restarting only fseventsd restored advancing cleanup, approximately 5 MB footprint and millisecond probes. The client mix changed after restart, so this is not a controlled fixed-client comparison. Finder stayed running, and Desktop add/delete checks worked on both sides. An earlier stale-Desktop symptom may be a separate issue. The boundary and table-size prediction were recorded before the live observations. The Feedback report has the timeline, graphs, counter snapshots, record walks, stack excerpts, disassembly and read-only sampler source. No daemon binary or target memory was changed. Live counter access used a temporary SIP debugging exception; a severe memory/notification failure was also captured before that exception. There is not yet a small standalone workload reproducer or a patched-build comparison. Is the scan cursor supposed to wrap or reset independently of table growth? If this is the expected mechanism, is there another cleanup path that should keep reclaiming zero-reference records once the table can no longer resize?

I am aware that for filenames, somewhere between the UI components and the kernel a conversion between / and : happens. Can someone explain where this happens? It is easy enough for me to convert ':' in kernel filenames to '/' in the string shown to or accepted from the user. But maybe there is an OS function I should be using to do that, in some more portable way, or something. More challenging is what to do when the user really wants a ':' in their filename. What is best practice? I was a bit surprised to find that in Finder, if I try to create a file called 'abc/def:ghi', I get a vague error message that tells me to "try with no punctuation marks". The case that has caused me to look into this now is a desire for filenames that are dates or times. From the user's point of view, a filename '8/10/2026 14:17:42' is not an unreasonable thing to ask for, is it? What other oddities are there? '.' and '..' of course... anything else?

What we are building We maintain an append-only on-disk store. Every update has the same shape: write a temporary file and make its contents durable; rename() it to its final name; only then publish the new state to the rest of the system. Step 3 is the one we must get right. Once we publish, other components treat the preceding step as committed. If power is lost after we publish but the renamed entry was not yet durable, we would have published a state the filesystem can no longer support after reboot. Our question is therefore narrow: after rename() returns, what does Apple document about when the resulting directory entry may be treated as durable across power loss? Two cases matter, and we would like them distinguished wherever the answer differs: the target name did not exist before — an entry is added; the target name already existed and is replaced — an entry is replaced and an older link is removed. We are not asking you to review or endorse our protocol — only what the platform documents. What we have read, and where we stopped fsync(2) here causes "all modified data and attributes of fildes to be moved to a permanent storage device", then warns that after power loss an application "may find that only some or none of their data was written". fcntl(2) says of F_FULLFSYNC that "data that had been fsync'd on the same device before is guaranteed to be persisted when this call returns", and lists APFS as supported. rename(2) "guarantees that an instance of new will always exist, even if the system should crash in the middle of the operation". In what we read, we did not find a statement connecting a successful synchronisation call on a descriptor that refers to a directory with the durability of a name added, removed or replaced in that directory. We are not claiming no such statement exists — only that we did not find one, which is why we are asking. Three questions, independent of one another Q1 — How are these calls supported on a directory descriptor? On APFS, how are fsync(2) and fcntl(fd, F_FULLFSYNC) supported when fd refers to a directory (for example one obtained with O_DIRECTORY)? Please treat the two calls separately, since they carry different documented guarantees. "Supported", "not supported" and "not specified for this use" are all useful answers to us. Q2 — If such a call succeeds, what does it cover? If the call in Q1 returns successfully, which changes are guaranteed to have been completed — the directory's own attributes; the entries added, removed or replaced; related metadata? We are asking for the documented scope, not the implementation. Q3 — Is there a documented sequence an application can rely on? Is there a sequence of calls that Apple documents for an application that needs the name resulting from a rename() to survive power loss before it publishes its next state? If so, we would appreciate the reference, the conditions it depends on — filesystem, device, call ordering — and its stated limits. If there is no public commitment of this kind, we would rather be told so plainly, together with whatever level you are able to confirm, including "this is not currently specified" if that is the accurate answer. One distinction we do not want to get wrong rename(2) uses the word crash. We do not want to read a statement about crash behaviour as one about power loss, since the two can differ at the device layer. If a documented guarantee covers one and not the other, that distinction is exactly what we need. We also note the device-level caveat in the same manual page — certain drives "have also been known to ignore the request to flush their buffered data" — and we are not asking you to speak for any particular drive. Environment macOS 26.3, build 25D125, APFS — read on our own development machine and reported here as such; not independently verified by a third party. Deliberately outside this request A rename() between two different directories touches a source directory and a target directory. Whether a guarantee would have to cover both is tracked separately and is not asked here, so that an answer about one directory is not read as covering two. We have not fixed where the temporary file lives, and we are not asking you to choose that layout. Nor do we assume your answer is independent of it: if any of the above depends on whether the source and target directories are the same directory or two different ones, please say so explicitly. We would rather be told the answer is conditional than read an unconditional answer into it.

I’m developing a sandboxed macOS app that needs persistent, read-only access to a user-selected folder. We are observing different behaviour between APFS and FAT32/exFAT after renaming the folder or moving it to Trash. The main problem is that the app can still track the folder while running, but cannot reliably restore the connection or identify its location after relaunch. Environment macOS 27.0.1 (26A434) Xcode 27.1 (27A9269) App Sandbox and user-selected file access enabled Folder selection through SwiftUI fileImporter Bookmark creation: .withSecurityScope and .securityScopeAllowOnlyReadAccess Bookmark resolution: .withSecurityScope The selected items are ordinary folders, not volume roots. Filesystem comparison APFS: the tested workflows appear to work as expected, including restoration after relaunch. exFAT: we have reproduced both bookmark renewal failure after a rename and loss of the “in Trash” classification after relaunch. FAT32: we have observed automatic bookmark renewal failures after a rename. The detailed debugger trace and Trash reproduction below were collected specifically on exFAT. Rename reproduction Select a folder through the system picker. Create and persist a read-only security-scoped bookmark. Resolve the bookmark and start accessing the resolved URL. Retain that URL and keep its security scope active throughout monitoring. Rename the folder in Finder while the app remains running. Attempt to create an updated bookmark for the same folder. The monitor retains an O_EVTONLY directory descriptor. After the rename, F_GETPATH returns the correct new pathname, and runtime identity checks still match the monitored folder. However, creating a bookmark using a URL reconstructed from that new pathname fails. Calling startAccessingSecurityScopedResource() on the reconstructed URL returns false, while the original resolved URL’s scope remains active. The bookmark creation call uses: url.bookmarkData(options: [.withSecurityScope, .securityScopeAllowOnlyReadAccess], includingResourceValuesForKeys: nil, relativeTo: nil) Exact failure measured on exFAT LLDB shows that Foundation’s internal open(): Receives the correct new pathname. Uses flags 0, meaning O_RDONLY. Immediately returns -1. Sets errno to 1, EPERM, read immediately on the same thread. The correlated Foundation error reports: NSCocoaErrorDomain Code 256 Could not open() the item: [1: Operation not permitted] This is a failed read-only open during bookmark creation. We have not established which policy causes the EPERM. A log stream filtered for com.apple.sandbox.reporting / violation produced no report during reproduction. We understand that this does not exclude sandbox involvement. We also tested a native CFURL file reference retained from before the rename. It continued to follow the folder and match its identity, but security-scoped bookmark creation from that reference also failed. Reselection works, but requires user intervention Selecting the same renamed folder again through fileImporter allows creation of a new bookmark. That bookmark resolves, is not stale, and restores access after relaunch. Without reselection before quitting, the previously saved bookmark does not restore access to the renamed folder on the next launch. The app reports it as unavailable. Separate Trash reproduction on exFAT Move the monitored folder to Trash using Finder while the app is running. The app correctly identifies the folder as being in Trash. Quit the app, leaving the folder in Trash. Relaunch: the app reports the folder as unavailable. The folder remains in Trash on the same exFAT volume. It has not been restored or permanently deleted. We also encountered failures when inspecting the Trash relationship using FileManager.getRelationship(_:of:in:toItemAt:) with .trashDirectory. We have not established whether these observations share the cause of the rename failure. Questions What is the supported public-API approach to preserve security-scoped folder access across an external rename on exFAT/FAT32, including after relaunch? What should bookmark resolution return for a folder moved to Trash, and how should a sandboxed app distinguish that condition from an unavailable resource after relaunch? Are these expected filesystem limitations, problems in our API usage, or behaviours that should be reported as macOS bugs? What additional diagnostics would help distinguish them? Ideally, the solution would preserve the original folder authorization without requiring repeated reselection or access to the parent directory or entire volume. I have read Accessing files from the macOS App Sandbox. I also found this discussion of bookmark failures involving exFAT, but it concerns volume roots and an earlier macOS release, so I’m not assuming it explains our case.

A user of my app reported that it is slower when enumerating a large number of files on APFS compared to HFS+. Online I can only find information that this is expected for rotational hard disks, but apparently APFS should be optimized for SSDs and hence the observed performance doesn't make sense. I used the code below to enumerate a folder hierarchy with about 100'000 files. I ran it several times on both APFS and HFS+ to minimize differences due to caching. On APFS the last runs took about 4.5 seconds, while on HFS+ the last runs took about 1.3 seconds. How can this big difference be explained? Is APFS really slower than HFS+ when enumerating files on SSDs? let openPanel = NSOpenPanel() openPanel.canChooseDirectories = true openPanel.canChooseFiles = false if openPanel.runModal() == .cancel { return } let resourceKeys: [URLResourceKey] = [.isDirectoryKey, .fileSizeKey, .creationDateKey, .contentModificationDateKey, .fileIdentifierKey, .isSymbolicLinkKey, .isHiddenKey, .isUserImmutableKey, .attributeModificationDateKey] let enumerator = FileManager.default.enumerator(at: openPanel.urls[0], includingPropertiesForKeys: resourceKeys) { url, error in print(error) return true }! let date = Date() var i = 0 for case let url as URL in enumerator { let _ = try? url.resourceValues(forKeys: Set(resourceKeys)) i += 1 if i % 10000 == 0 { print(i) } } print(-date.timeIntervalSinceNow)

My custom filesystem kernel extension stores ACLs as an extended attribute, com.apple.system.Security. Sanboxed apps such as TextEdit, Pages, etc., running as a non-privileged process, fail to save modified contents when permissive ACLs are in use. Running them as a privileged process, does allow for file changes to be saved though. Non-sandboxed apps, such as VSCode, and command line programs are not susceptible to this behaviour. APFS, on the other hand, seems to handle ACLs as an ATTR_CMN_EXTENDED_SECURITY filesystem attribute, rather than as an EA. In this case, sandboxed apps have no trouble accessing the ACL data. I implemented a minimal PoC within my custom kext to verify this. I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr. This allows the file contents to be modified and saved by sandboxed apps. Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design? Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both? Thanks.

Security concern: To provide a visually appealing transition when launching or leaving an application, iOS introduced a feature that automatically captures a screenshot of the current view when an app is moved to the background. This screenshot is subsequently displayed as a preview in the App Switcher. There is security concern that the app shows sensitive information like activation codes or chat histories in the preview image of the App Switcher Need clarification on the following points: 1.Where exactly are these App Switcher preview screenshots stored on the device filesystem? 2.Can these App Switcher snapshots be accessed on a jailbroken iOS device? 3.Are these snapshots stored inside the application container or in a system-managed location outside the app sandbox? Can any Third party application or tool can access this screenshots in iOS device? 5.Is there any Apple-recommended API, entitlement, or platform-supported mechanism on iOS to prevent screenshots in iOS

I've written an PDF viewing app, and there seems to be a correlation between files opened by the app and files that Time Machine says couldn't be backed up. The files can still "not be backed up", even after the app has closed them. Is there anything I specifically need to do to sever the link between the file and the app?

Environment: App: Developer ID signed, non-sandboxed macOS app Browsers affected: Google Chrome, Mozilla Firefox Safari: Working fine on macOS 27 Working on: macOS 26 and earlier Broken on: macOS 27 (Golden Gate) Issue Our non-sandboxed, Developer ID signed macOS app interacts with Chrome and Firefox directories under ~/Library/Application Support/ as part of its browser extension deployment workflow. On macOS 26 and earlier, this worked without any special permissions. On macOS 27, the same operations are silently blocked — no TCC prompt is shown to the user, access is simply denied. Granting Full Disk Access to our app via System Settings > Privacy & Security > Full Disk Access resolves the issue completely on macOS 27. Safari is unaffected — our Safari extension is bundled directly inside our app and continues to work correctly on macOS 27 without any additional permissions. Question Has macOS 27 intentionally introduced TCC or MACL-based protection over Chrome and Firefox directories under ~/Library/Application Support/, blocking access from non-owner processes including non-sandboxed Developer ID apps? If this is an intentional change, is Full Disk Access the expected requirement going forward, or is there a more targeted entitlement or Apple-recommended approach for a non-sandboxed app that legitimately needs to access browser directories as part of an extension deployment workflow?

What supported public API and verification contract should a sandboxed macOS file manager use to preserve a copied file's quarantine/provenance metadata? We observe different results in App Sandbox versus Finder and an otherwise-matched non-sandbox diagnostic. We want to keep App Sandbox and all security protections enabled, not remove quarantine or invent undocumented flag masks. Environment: macOS 26.6.2 (25G83), Apple Silicon, local APFS. Optimized Foundation-only diagnostic, Apple Development signing, Hardened Runtime, launched directly as an executable. The sandbox variant has app-sandbox, user-selected read/write and app-scope bookmark entitlements. This is not a notarized distribution-build comparison. Reproduction: Use an existing regular JPEG with naturally present com.apple.quarantine metadata identifying Chrome, raw flags 0283 and a nonempty event field. Keep the original read-only. Record SHA-256, length, full raw extended attributes and fresh NSURL quarantinePropertiesKey observations. Keep access to a user-granted local test directory active. Copy to a new, absent destination in a fresh directory using each of these three arms: fclonefileat with CLONE_ACL | CLONE_NOFOLLOW_ANY | CLONE_RESOLVE_BENEATH (28). copyfile with COPYFILE_CLONE | COPYFILE_ACL; record COPYFILE_STATE_WAS_CLONED. FileManager.copyItem(at:to:). Observe source and destination without setting, removing or repairing metadata. Each arm waits at least 1.1 seconds before copying; the source quarantine timestamp is much older than call time. Repeat with fresh destinations. Also copy the same source through actual Finder Copy/Paste twice. Compare two signed variants made from the same compiled payload, with identical executable name, bundle ID, Development identity and Hardened Runtime. The only signed entitlement difference is app-sandbox=true versus its omission. The sandbox variant resolves the existing exact folder grant; the non-sandbox diagnostic uses that same fixed test directory directly. Results: Sandbox diagnostic: all six calls succeed and data hashes/lengths match. All six outputs change raw flags 0283 to 0082, agent Chrome to the diagnostic app, event field nonempty to empty, and timestamp. Public output lacks the source event identifier and adds LSQuarantineTypeSandboxed. Matched non-sandbox diagnostic: all six copies preserve the full observed raw quarantine record and public quarantine dictionary. copyfile reports WAS_CLONED=true in both contexts. Finder: both copies preserve the full observed raw quarantine record and public dictionary. Source bytes and declared preserved metadata remain unchanged. Other compared raw attributes, mode, flags, birth/modification times, owner/group and ACL match in these cases. We also reproduced timestamp-only differences with files naturally quarantined by the diagnostic itself. The foreign-agent control above shows that the difference is not limited to timestamp. The chosen source exposes no public origin/data URL, so their preservation is untested. We have not traced the responsible internal component, tested Gatekeeper effects, or established whether the transformation is security-equivalent. We do not claim the three APIs use independent implementations or that all possible public API combinations have been tested. Could you clarify: Is this transformation expected for copying from an App Sandbox process, or should we file it as a bug? What documented preservation behavior should a sandboxed file manager rely on? Is there a supported API or operation that preserves the source's quarantine/provenance metadata in this context without disabling App Sandbox or weakening security protections? If exact raw equality is intentionally not guaranteed, which supported public properties or behaviors should verification check? Is a quarantine-properties dictionary round-trip supported, and what information does it preserve or omit? We have not attempted a metadata repair. Separately, a pathname-based repair after cloning would require its own destination-identity/race safety review because the clone call does not return a creation-bound destination descriptor. We are asking for supported API semantics, not private implementation details or a security bypass. We can prepare a minimal sanitized standalone reproducer if needed. No user files, sandbox grants, private logs or diagnostic binaries are attached to this initial question.

macOS Tahoe appears to ignore /etc/fstab ro and noauto — findings and workaround I encountered what appears to be a regression in macOS Tahoe where Disk Arbitration no longer honors ro and noauto policies in /etc/fstab for external volumes. I am posting my findings here both to see whether others can reproduce the issue and to document a workaround, particularly for anyone using macOS for disk recovery or other workflows where preventing writes is important. The problem A configuration such as: UUID= none exfat noauto does not prevent the volume from automatically mounting. Similarly: UUID= none exfat ro does not result in a read-only mount. I also tested: UUID= none exfat ro,noauto with the same problem. This configuration worked for me before upgrading from macOS Sequoia to Tahoe. I initially suspected this might be related to Tahoe's newer exFAT/FSKit path, but testing APFS produced the same general behavior. It therefore appears to be broader than exFAT alone. /etc/fstab itself is being parsed correctly I tested the libc fstab interface using getfsent(). For example, an entry containing noauto is returned as: spec=UUID= | file=none | vfstype=exfat | mntops=noauto | type=rw So this does not appear to be a simple malformed-fstab problem. Tracing also shows diskarbitrationd accessing /etc/fstab. What Disk Arbitration is doing Unified logs from an affected exFAT mount show the filesystem being successfully probed, followed by Disk Arbitration mount approval callbacks. After approval, the reported mount options are: Mount options nodev,noowners,nosuid and the volume is then mounted successfully. The ro policy expected from /etc/fstab is notably absent from those mount options. Direct read-only mounting still works The filesystem itself is capable of being mounted read-only. For example, for exFAT: sudo mkdir -p /Volumes/Exchange sudo mount_exfat -o rdonly /dev/diskXsY /Volumes/Exchange This produces a genuinely read-only filesystem; a write test fails as expected. So at least in my testing, the problem appears to be associated with the normal Disk Arbitration mounting path rather than an inability of the filesystem to support read-only mounting. A working noauto workaround Disk Arbitration still supports mount approval callbacks. I tested a small client using: DAApprovalSessionCreate DARegisterDiskMountApprovalCallback DADissenterCreate The callback checks the volume UUID against /etc/fstab. If the corresponding entry contains noauto, it returns: kDAReturnNotPermitted This successfully prevents the volume from mounting. The test output looks like: [BLOCK] mount request: /dev/disk5s1 [BLOCK] mount request: /dev/disk5s2 The volume remains unmounted. Interestingly, this also blocks: diskutil mount /dev/diskXsY because diskutil mount goes through Disk Arbitration. A direct filesystem mount such as mount_exfat, however, bypasses that approval request and can still be used to deliberately mount the filesystem read-only. Why this matters For an ordinary external disk, an unexpected automount may only be annoying. For data recovery, forensic inspection, or a failing disk, the difference can be important. If /etc/fstab says: ro I expect that policy to protect the source filesystem from writes. Silently mounting the filesystem read-write instead means that the volume becomes available to Finder and other background services. That is exactly what I am trying to avoid when working with a recovery source. For this reason, I would recommend verifying the actual mount state rather than assuming that an existing /etc/fstab ro entry is still protecting a disk after upgrading to Tahoe. For example: mount or: diskutil info /dev/diskXsY should be used to confirm the resulting state. Current workaround design I am currently using a small compatibility helper that treats /etc/fstab as the source of truth: /etc/fstab ↓ compatibility helper ↓ Disk Arbitration mount approval The daemon side handles mount policy before Disk Arbitration can automatically mount the volume. An explicit mount helper can then perform a direct filesystem mount with the options specified in /etc/fstab, including read-only mounting where required. The intention is not to replace /etc/fstab, but to restore the behavior that was previously provided by the system. Reproduction request If anyone else is running macOS Tahoe, I would be interested to know whether you can reproduce this with either: UUID= none apfs noauto or: UUID= none exfat noauto and similarly with ro. Please be careful when testing ro: use a disposable/test volume rather than a disk whose contents actually depend on remaining read-only. I have also submitted this to Apple through Feedback Assistant. Feedback ID: 24677522 I will update this post if Apple provides additional information or if a later Tahoe update changes the behavior.

When I drag and drop a file with flag "shouldAttemptToOpenInPlace: true", I was able to access the original file name in macOS 15. After upgrading to macOS 26, I can't access the original file name anymore. Instead, I got some useless file name such as ".com.apple.Foundation.NSItemProvider.gKZ91u.tmp". The app no longer works with these tmp filenames because it needs the orignal file name to do the file transfer. (Btw, this is a WinSCP like app on Mac platform) Could you please check and fix this issue? Thank you. FileRepresentation(contentType: .item, shouldAttemptToOpenInPlace: true)

Hello everyone, I've been chasing a nasty silent data corruption bug in the macOS SMB client (smbfs.kext) and wanted to share what I found, in case someone else has hit it and in the hope that someone from the SMB team sees it. What happens Under concurrent writes with repeated reopens, the client can regress its cached file size (np->n_size) to an earlier, smaller value - behind data it has already written and flushed to the server. The next write then treats the already-written range as a hole, zero-fills it via IO_HEADZEROFILL, and sends the zeros to the server, right on top of the correct bytes it transmitted moments earlier. No write(2) fails and nothing is logged - the file just quietly comes back with a chunk-aligned run of zeros in the middle, at the correct overall length. Environment macOS 26.5 (Darwin 25.5.0), Apple silicon (16 KiB VM pages), SMB 2.1 Sources referenced: SMB client 538.121.1, xnu 12377.121.6 How to reproduce Mount an SMB 2.1(2.0.2 has the same issue as well) share. Have several threads write the same files in 8 KiB chunks, each chunk via its own open/lseek/write/close (so the file is reopened constantly as it fills), while the files are concurrently resolved by name (stat / directory enumeration). Read the files back through a cache-cold path (second mount, or F_NOCACHE) and compare. Roughly 1 file in several hundred came back corrupted for me. The core of the write pattern: CHUNK = 8192 # 2 chunks per 16 KiB page def write_chunk(path, data, offset): fd = os.open(path, os.O_CREAT | os.O_RDWR) # own handle per chunk try: os.lseek(fd, offset, os.SEEK_SET) os.write(fd, data) finally: os.close(fd) # per file: content = os.urandom(random.randint(265000, 300000)); # chunks written in batches of 8 threads, joined between batches; # each file written twice from the same buffer: NAME, then NAME.copy In my runs the corruption always landed on the second (.copy) write. One caveat: I reproduced this against a third-party SMB server, not against macOS File Sharing (smbd), and I don't expect it to reproduce against smbd directly. The stale size arrives via reopen-via-lookup (smbfs_update_size <- smbfs_nget <- smbfs_vnop_lookup) on a freshly instantiated vnode, whose n_sizetime lets the freshness guard pass. smbd instead reopens via vnop_compound_open -> smbfs_attr_cacheenter (warm vnode; the guard rejects it) - the same stale-size candidates occur, they just all get rejected. The server merely steers the client onto the vulnerable path; the bug itself is entirely client-side. What I observed I captured the kernel side with dtrace fbt probes on smbfs_setsize() / smbfs_update_size() (os_log drops events under this load). Timeline for one corrupted file, correlating pcap and dtrace (dtrace has whole-second resolution, marked ".x"): [pcap] = network packet capture of the SMB traffic between client and server [dtrace] = kernel-side trace of the smbfs size-update functions; timestamps only have whole-second resolution, so ".x" marks an unknown sub-second time :39.778 [pcap] — client sends WRITE off=32768 len=32768 with the correct data, covering [40960:65536). :39.777–.860 [pcap] — throughout, the server's CREATE/CLOSE responses report a strictly monotonic EOF: 0, 8192, 40960, 65536, ... 288255. :39.x [dtrace] — on a reopen, smbfs_update_size applies EOF 40960 (a superseded value), regressing n_size from 65536 to 40960. :39.x [dtrace] — the next write starts past the regressed size, so zero_head_off = 40960 and IO_HEADZEROFILL is set. :39.804 [pcap] — client sends WRITE off=32768 len=57344, ALL ZEROS over [40960:65536), on top of the correct data it sent 26 ms earlier. End result: the file is 288255 bytes (correct length) with 24 KiB of zeros at [40960:65536) - three consecutive 8 KiB chunks, i.e. 1.5 x 16 KiB VM pages. Worth stressing: the server's own responses reported a strictly monotonic EOF the whole time, so the regression to 40960 was purely the client applying a superseded value. Expected, obviously: the file reads back byte-for-byte identical to what was written. Where I think the bug is From reading the smbfs and xnu sources, three things combine: np->n_size isn't consistently synchronized - read under the node lock only (smbfs_vnops.c:7329/7387/7391) but written under f_clusterWriteLock (:7411) and by smbfs_vnop_strategy under the cluster lock, so the reader deciding the zero-fill has no ordering guarantee. Possible fix: read it once under f_clusterWriteLock in smbfs_vnop_write so the snapshot, extend, and zero_head_off stay consistent. The freshness guard checks the wrong thing - smbfs_update_size's reqtime <= n_sizetime guard validates the reply's request time, not whether the value is still current, so a superseded (smaller) size applied later still passes and calls smbfs_setsize(smaller). Possible fix: never shrink n_size from fa_size while the vnode has dirty pages or in-flight writes beyond that size. The zero-fill is destructive - zero_head_off = np->n_size (smbfs_vnops.c:7391) feeds IO_HEADZEROFILL, and cluster_write zeros [n_size, uio_offset) without checking whether the UBC already holds those pages as valid/dirty (vfs_cluster.c), then flushes the zeros to the server. A defensive check there would neutralize the corruption regardless of cause. Has anyone else seen silent zero-runs in files written over SMB under concurrent access? Thanks!

I am not sure if it's from Xcode or macOS 27, but here is what I get after running df: /dev/disk3s3 228Gi 1.5Gi 15Gi 9% 112 161M 0% /Volumes/Recovery devices -- file:///Users/USER/Library/Containers/com.apple.CoreDevice.CoreDeviceService/Data/ 1.0Ti 0Bi 1.0Ti 0% 0 9.2E 0% /Users/USER/Library/Developer/CoreDevice/DeviceFS It's really annoying. Is there any way to remove this?

I'm seeing a recurring issue on macOS 26.5.2 (build 25F84) where the kernel's Sandbox/System Policy layer intermittently denies file access on NFS mount points from local network servers. Posting here in case anyone recognizes this pattern or has a workaround, and flagging it since I've also filed a Feedback Assistant report (with a live-captured sysdiagnose) for the same issue. WHAT HAPPENS Two independent NFS mounts to two separate, unrelated servers on my LAN start failing simultaneously with "Operation not permitted." The kernel log shows: kernel: (Sandbox) System Policy: mount_nfs(PID) deny(1) file-mount /path/to/mount Critically, it's not limited to the mount syscall - within the same few-second window, System Policy also denies ls, perl, diskutil, and even umount -f on the exact same path, for otherwise unrelated processes. So it looks like a transient, path-scoped kernel decision rather than something specific to NFS or the mount syscall. It self-heals anywhere from seconds to ~30 minutes later, then recurs - documented 30-80+ occurrences/day via a background watchdog script. WHAT I'VE RULED OUT Server-side cause: two independent servers on different hardware fail identically at the same instant. Network issue: checked network logs in the same window, no correlated connectivity event. Third-party kext conflict: kextstat shows zero third-party kexts loaded. syspolicyd database corruption: no "ASP: Validation category" signature present. TCC/Full Disk Access: already granted; the denying layer is kernel Sandbox "System Policy," not TCC. QUESTION Has anyone else run into System Policy denying file-mount/file-read-data/file-unmount on network volume paths intermittently like this? Is there any userland way to inspect or reset whatever internal state drives this decision (I haven't found one - no spctl/tccutil/sysctl lever that touches it)? Happy to share more log excerpts if useful.