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"

On macOS 26.5.2 (build 25F84), which documented API and return conditions, if any, establish that a regular file on APFS has no extended access control list (ACL), using an already-open file descriptor? We tested three disposable regular files on an APFS volume reporting ACL support. For each file, we opened a read-only file descriptor and called: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY Before and after inspection, fstat() confirmed stable device, inode, mode, and change timestamp. Observed results: 1. Newly created file, no ACL explicitly assigned acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() succeeded but omitted ATTR_CMN_EXTENDED_SECURITY from the returned attribute mask. FSOPT_PACK_INVAL_ATTRS also left that bit clear. 2. File with an explicitly assigned empty ACL acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() returned the extended-security attribute with an ACL entry count of zero. 3. File with one explicit ACL entry acl_get_fd_np() returned a non-null ACL. fgetattrlist() returned the extended-security attribute with an ACL entry count of one. Apple's published XNU attribute-packing implementation appears to use the same omission branch when ACL metadata is unsupported or when the ACL pointer is null. My question: Is there a supported descriptor-based API sequence that reliably distinguishes: Genuine absence of an extended ACL Unavailable or unsupported per-file ACL metadata An ACL retrieval failure If so, which API, capability checks, return values, attribute bits, or error conditions should a caller rely on? Are there relevant APFS or macOS version limitations? If the public API cannot establish ACL absence unambiguously in this situation, confirmation of that limitation would also be helpful. Thank you for your guidance.

What supported public contract should software use for com.apple.provenance when copying an exact expected helper binary into a new, private owner-controlled working directory for separately authorized later use? We want to leave originals unchanged, preserve security protections, and avoid removing, decoding or reconstructing opaque Apple attribute values. Program-byte identity, permissions/custody and code validation are separate from this metadata question; an attribute name or copy success is not treated as a trust decision. Public APIs reviewed: fcopyfile with independent DATA/XATTR selection, and xattr_flags_from_name with xattr_intent_with_flags for COPY intent. A bounded public-constant probe returned zero property flags and the default preserve result for both com.apple.provenance and an invented unknown name. We therefore do not interpret that default as proof of recognition or an exemption. Could you clarify: Which supported metadata postconditions apply to this specific copy use? Is source/destination raw-value equality an appropriate invariant for this opaque attribute, or may the OS legitimately create different destination metadata while preserving the intended security behavior? Which public properties or APIs can establish the intended destination state without parsing/removing private values or weakening OS protections? The xattr manual's named-wrapper return sentence appears inconsistent with its flags-based description/example. What is the supported return-polarity contract, and is using the flags-based function the intended interpretation? This asks for supported semantics, not a bypass or private value format. No paths, binaries, source, attribute values, keys, account data or logs are attached. Public references: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/fcopyfile.3.html https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_name_with_flags.3 https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_flags.h

Apple Support directed me to the Developer Forums for this API-contract question. I am implementing conservative, read-only ACL classification for existing files and directories. I need to distinguish an absent ACL from unavailable or incomplete ACL information. Ambiguous results are currently rejected. The measurements below were taken on macOS 26.5, build 25F71, Apple Silicon (arm64), on APFS. Method I tested eight newly created objects: a regular file and a directory in each of four preparation states: Fresh: no ACL setter, deletion or normalization was performed. Explicit-empty ACL preparation. One DENY entry. One ALLOW entry. “Fresh” describes preparation only; I am not assuming it independently proves ACL absence. Each object remained open through preparation and two observations using the same file descriptor. Each observation performed: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_REPORT_FULLSIZE and without FSOPT_PACK_INVAL_ATTRS. Errno was cleared immediately before each query and captured immediately afterward. Descriptor/path identity and metadata stability were checked. Returned lengths, attribute bitmaps and applicable reference/payload bounds were validated. Observations Results matched between the two observations and between regular files and directories: Preparationacl_get_fd_np resultfgetattrlist returnEXTENDED_SECURITY returnedReturned filesec ACE countAttribute-buffer lengthFreshNULL, errno ENOENT0NoN/A32 bytesExplicit-emptyNULL, errno ENOENT0Yes076 bytesOne DENY entryNon-NULL, errno 00Yes1100 bytesOne ALLOW entryNon-NULL, errno 00Yes1100 bytesWhen the getter returned NULL, ACL validation and enumeration were not performed; their results are N/A, not measured zeros or an empty entry list. When EXTENDED_SECURITY was omitted, its payload fields were unavailable. I did not interpret default buffer values as returned ACL information. An actually returned zero-entry record is distinct from omission. No NOACL sentinel was observed in this experiment. Question For a valid descriptor referring to an existing APFS object, what is the supported interpretation of: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returning NULL with ENOENT; and fgetattrlist() succeeding while omitting ATTR_CMN_EXTENDED_SECURITY from the returned attribute bitmap? In particular: Can this combination establish ACL absence under documented conditions, or must it remain classified as unavailable/ambiguous information? How should the observed NULL/ENOENT with an actually returned zero-entry ACL record be interpreted? If these results cannot establish absence, which supported read-only, descriptor-based API or verification sequence should be used? What guarantees and limitations apply regarding macOS versions, filesystem support and genuine retrieval failures? I reviewed the acl_get(3) documentation but could not find a clear explanation of this valid-descriptor ENOENT case: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/acl_get.3.html I am seeking the supported API contract, not asserting an OS defect or vulnerability. I do not want to set, delete or normalize ACLs on the objects being inspected, or treat an ambiguous result as success.

Reported environment: macOS Monterey 12.7.6 (build 21H1320), Intel, APFS. The filesystem type of the relevant volume and exact installed implementation have not been independently reverified. I need a supported, read-only way to distinguish an absent filesystem ACL, an explicit zero-entry ACL, and unavailable/unsupported/invalid/incomplete ACL evidence while retaining an open descriptor to the object. One retained observation: an existing empty regular file was opened read-only with O_NOFOLLOW and O_CLOEXEC. Path and descriptor metadata matched the expected identity, owner, mode and link count before and after the call. Exactly one acl_get_fd_np(fd, ACL_TYPE_EXTENDED) call returned NULL. Errno was cleared immediately before the call and immediately captured afterward as ENOENT. Descriptor closure succeeded. This observation does not establish ACL absence or identify the internal error path. File creation and private mode are not treated as proof of no ACL. I have not tested fgetattrlist on this host, created ACL fixtures for this inquiry, or established volume ACL capability results. Apple's published Libc-1507.100.9 source shows the fstatx_np/filesec property path, and xnu-8020.140.41 shows mode-dependent extended-security attribute packing. I am treating those as version-specific implementation evidence, not as confirmation of the installed implementation or a complete supported API contract. For this reported configuration: Which supported descriptor-bound API sequence and checked preconditions distinguish these three states? A contract applicable to Monterey and the relevant filesystem is sufficient; I am not asking for a guarantee across every macOS version or filesystem. Does NULL/ENOENT from acl_get_fd_np have a supported ACL-absence meaning under specified conditions? Can an explicit zero-entry ACL produce the same result, and how should it be distinguished? With fgetattrlist requesting ATTR_CMN_RETURNED_ATTRS and ATTR_CMN_EXTENDED_SECURITY, can an omitted security returned bit ever establish absence rather than unavailable evidence? Do legacy packing or a valid filesystem capability result supply a supported distinction? Please specify the applicable conditions. Does successful fstatx_np followed by filesec_query_property for FILESEC_ACL reporting an unset property distinguish absence from an unavailable observation? When a complete, valid security record is returned, what is the supported interpretation of KAUTH_FILESEC_NOACL versus an explicit entry count of zero? Is this representation intended for application-level absence verification? Please identify applicable documentation or supported technical guidance, including failure/unknown handling. Genuine retrieval errors must remain errors, and ambiguous or incomplete evidence must remain unknown. I do not want to infer success from an error, omitted attribute, invalid default or empty display, or modify an object's permissions/ACL to establish its prior state. References consulted: Apple's ACL getter manual Apple Libc-1507.100.9 ACL getter source Apple xnu-8020.140.41 attribute manual

Hello, I am Ahmed Hamade, founder of Pixel Ventures LLC, Apple Developer Program Team ID LM3P28DNVQ. I am asking Apple to grant the restricted entitlement com.apple.developer.vfs.snapshot to our team for a macOS backup application named PixelProtect. If this is not the right channel, please tell me where to send the request. PixelProtect backs up a whole Mac volume. It keeps one primary backup set on a local disk and a replica of that same set in cloud storage, protects both copies against deletion, and supports recovery. We built it for people whose AI coding agents can delete data. We need snapshots for three reasons. First, files change while a backup runs, so the backup must read from one point in time to copy a consistent state. Second, snapshots let us keep local restore points without copying the data again. Third, Time Machine takes local snapshots for the same purpose. The only alternative today is tmutil localsnapshot, whose snapshots the system manages and ages out, so we could not keep restore points of our own. We would use fs_snapshot_create, fs_snapshot_list, fs_snapshot_delete and fs_snapshot_mount. We do not use fs_snapshot_revert. Restores copy files out of a mounted snapshot. Only our privileged helper calls these functions. It runs as root, is registered with SMAppService, and is packaged as an app-like bundle (planned App ID ai.pixelventures.pixelprotect.daemon) so it can embed a provisioning profile. The main app (ai.pixelventures.pixelprotect) and our command line tool send requests to the helper and do not call these functions. We limit use as follows. Snapshots are created only on volumes the user chose to back up. The user controls how long snapshots are kept. The helper deletes only snapshots it created, which carry our own name prefix, and only under the user's retention rules or an action the user confirms. PixelProtect is signed with our Developer ID Application certificate, uses the hardened runtime, is notarized, and is distributed outside the Mac App Store to Pixel Ventures clients. It is not sandboxed, because a whole-volume backup reads the whole volume. It has no public marketing page yet, so a product description is attached. Please enable the entitlement for Team ID LM3P28DNVQ for development and for Developer ID distribution, or tell me what further information you need. I tried the code-level support request form and it requires a sample project, so I am asking here as the form suggested Thank you, Ahmed Hamade Founder, Pixel Ventures LLC Team ID LM3P28DNVQ I tried the code-level support request form and it requires a sample project, so I am asking here as the form suggested

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, a small set of ordinary development source/resource files and one project directory carry the private extended attribute com.apple.macl. We need to create a new APFS compilation-input tree, not a filesystem backup. The proposed implementation opens source and destination objects using descriptor-relative no-follow traversal and calls fcopyfile(sourceFD, destinationFD, NULL, COPYFILE_DATA), then independently verifies exact content hashes and applies an explicit destination mode and ACL policy. It does not request COPYFILE_XATTR, COPYFILE_ACL, or COPYFILE_STAT. Is omitting com.apple.macl supported for this data-only compilation export? Could preserving it transfer stale or inappropriate access authority to the destination? Which supported API or documented postconditions should establish the destination's correct security state? Is there an Apple-recommended procedure for exporting ordinary development source content without transferring private mandatory-access metadata? We are seeking an API and security contract, not an interpretation of the attribute's private bytes. No production paths, source code, private attribute values, credentials, datasets, or personal information are included.

I'm implementing a security-sensitive filesystem metadata verifier on macOS 27.0.1 (Apple Silicon, MacOSX27.0.sdk). The verifier must distinguish three states: ACL absent: Supported evidence establishes that the file or directory has no filesystem ACL. ACL present: An ACL exists, including an empty ACL. Unknown: The observation is ambiguous, unavailable, unsupported, or incomplete. Only authoritative ACL absence is acceptable. All other states are rejected. I'm investigating fstatx_np() with a filesec_t object, followed by filesec_query_property(security, FILESEC_ACL, &present). My questions are: Does this combination provide a supported API guarantee that a file or directory has no ACL when present is reported as false? Can an unset FILESEC_ACL property be reliably distinguished from an omitted or unavailable ACL observation? If this mechanism cannot establish absence, is there another supported descriptor-based macOS API that can? Is there Apple documentation specifying these semantics, including relevant error and unsupported-operation behavior? I am not treating an empty ACL entry list, an unset property, or a command-line display without ACL entries as proof of absence. I'm seeking the native API contract so the verifier can fail closed whenever ACL absence is not authoritatively established.

Our iOS app uses shm_open to create an app-owned, App Group-scoped POSIX shared-memory object. Before allowing access to previously authorized offline data, we call fstat on its file descriptor to verify the object's size, owner UID, and permission mode. We do not access file timestamps, use this information for fingerprinting, or send the metadata off-device. Apple's approved reason C617.1 refers to files inside app or App Group containers. However, POSIX shared-memory objects have no filesystem entry. Does C617.1 cover this specific use of fstat? If not, should we request a new approved reason?

Apple feedback FB25355124 The SMB client no longer accepts reads to symlinks that are an absolute path to a network volume or a symlink that contains a (..) in the relative path. Reproduction steps on an SMB mount with this file structure: dir a.txt Run this command from inside of "dir": ln -s my-link ../dir/a.txt Attempt to read that symlink: cat ./my-link Which results in this error: cat: link: Invalid argument which is translating to an EINVAL getting returned from the SMB client. Same behavior was observed when making a symlink with an absolute path: ln -s my-link /Volumes/Example/dir/a.txt The server is responding successfully to the IOCTL command but the client is still rejecting the request with that error. This behavior was not observed in macOS 26.6.2 (smbfs 6.0.1) as well as previous versions of macOS.

Hello, I am preparing an existing macOS screenshot utility for distribution through the Mac App Store. The app stores captured PNG files under its temporary directory: FileManager.default.temporaryDirectory .appendingPathComponent("ShelfDragPoC/Captures", isDirectory: true) A context-menu "Edit" action passes the original PNG URL to Preview using NSWorkspace. The app does not create an editing copy. Relevant code: import AppKit @MainActor func openInPreview(_ url: URL) { guard let previewURL = NSWorkspace.shared.urlForApplication( withBundleIdentifier: "com.apple.Preview" ) else { return } let configuration = NSWorkspace.OpenConfiguration() configuration.activates = true NSWorkspace.shared.open( [url], withApplicationAt: previewURL, configuration: configuration ) { _, _ in } } The app monitors the original PNG URL for file changes and refreshes its thumbnail when changes are detected. Observed behavior: In the existing non-sandboxed app, rotating an image in Preview updates the original PNG and the thumbnail without requiring Command-S. In the sandboxed validation app, Preview opens the image, but editing results in a separate copy. When closing the edited document, Preview displays a message indicating that the original document will not be changed. The original PNG and the app's thumbnail are not updated. The Preview launch code and file watcher are unchanged between the non-sandboxed and sandboxed versions. The sandboxed app has these entitlements: com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write com.apple.security.files.bookmarks.app-scope The app-scoped bookmark is used for a separate Desktop export feature. The PNG opened in Preview remains in the app's sandbox container. My question: Is there a supported public API that allows a sandboxed Mac App Store app to open its own container-resident PNG in Preview with the permissions required for in-place editing and normal automatic saving? Ideally, the user would only need to select "Edit" once, without an additional file-selection dialog or an explicit Save command. We want to preserve the original PNG URL, keep App Sandbox enabled, and avoid automatically exporting temporary images to the Desktop. If this workflow is not supported, what is Apple's recommended approach? Thank you.

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'm building a sandboxed macOS app (Developer ID, App Sandbox enabled) with a File Provider extension that exposes on-demand placeholder files under  ~/Library/CloudStorage/<domain>/ . Expected: The app writes the placeholder file URLs to  NSPasteboard.general . The user presses ⌘V in Finder, and Finder fetches the contents on demand via  fetchContents . Observed: • Finder's own copy and paste of the same placeholders works, and  fetchContents  is called at paste time as expected. • When the sandboxed app writes the URLs to the pasteboard,  CFPasteboard  logs:  Sandbox extension creation failed ... (error -20) . The paste does not happen. • Writing  NSPasteboardItem  with  .fileURL  strings instead of  NSURL  objects produces the same error. • Adding  com.apple.security.temporary-exception.files.absolute-path.read-only  for the CloudStorage domain path fixes it. Questions: Is there a supported way for a sandboxed app to put File Provider placeholder URLs on the pasteboard without the temporary-exception entitlement? Is the temporary-exception entitlement acceptable for Mac App Store distribution, or is it only viable for Developer ID builds? Should the app grant itself access another way, for example through a security-scoped bookmark or by using  NSFileProviderManager  APIs?

I’m seeking authoritative documentation on the lifecycle and integrity significance of files under mapped/ in an encrypted macOS sparsebundle using backing-store version 2. Six regular files, each 2,048 bytes, were verified under mapped/ in the sparsebundle package before attachment. After a normal detach, those six files were absent from the disposable image’s package. The source backup retains all six. Additional band-level checks have not established the significance of this change. It remains unclear whether this is expected lifecycle behavior or has integrity implications. No data corruption has been proven, and these observations do not establish that the removal was safe. What purpose do mapped/ entries serve specifically in backing-store version 2? Can writable attachment or normal detach legitimately remove these entries while retaining the corresponding band data? Under which documented conditions, if any, is their removal safe? Could missing entries affect logical block addressing or data integrity even when the corresponding band files remain present? What supported, non-destructive, read-only validation can establish whether the image remains logically consistent? Pointers to authoritative Apple documentation or an applicable backing-store v2 implementation reference would be appreciated.

Reference environment: macOS 26.7.1, build 25G241, arm64, local APFS. Consistent capture of a source file We are evaluating NSFileCoordinator with the forUploading and withoutChanges options for a single regular file. Does the resulting snapshot guarantee byte contents corresponding to a single point in time, even if another process writes during capture without file coordination, using write/pwrite or a shared writable memory mapping? We need to establish the scope, conditions, and limitations of this guarantee. We do not require capturing an editor’s unsaved changes or application-level database consistency. If any of these concurrent writing methods are not covered, please identify them explicitly. Durability of the final filename after a rename We are evaluating the following sequence: a verified temporary file has successfully completed strong synchronization, and is then renamed using renameatx_np with RENAME_EXCL. The temporary and final names are in the same directory on the same volume. Next, fsync_volume_np is called with SYNC_VOLUME_FULLSYNC and SYNC_VOLUME_WAIT. Under what conditions does a successful return confirm that the final filename and its association with the prepared file contents will survive a system crash or power loss? We also need clarification on whether all relevant data and metadata write errors are propagated to the caller, or whether an earlier error might remain unreported by this operation. Please provide the documented scope and limitations for this environment.

I am seeking advice about supported macOS performance tracing, NOT reporting a confirmed APFS bug. This is a real application failure. AI assisted with organizing this report, and the measurements were reviewed against existing records. Environment Apple Silicon Mac Studio, 32 GB RAM, macOS 15.7.9 (24G830). CPython 3.11.15, linked SQLite 3.50.4. SQLite database: 3,224,576,000 bytes on an internal APFS volume, journal_mode=DELETE. The application runs PRAGMA quick_check before starting worker processes. A progress handler cancels the operation after 30 seconds, producing SQLITE_INTERRUPT. This is application-triggered, not proof of corruption. Observed results Original database: 30.008 s wall / 5.220 s CPU; a separate run took 30.192 s wall / 5.420 s CPU. Both were interrupted. A two-second sample showed 95/96 samples on SQLite's checkTreePage → readDbPage → unixRead → pread path. Individual pread latency was not measured. A transaction-consistent SQLite Backup API snapshot on a different APFS volume completed quick_check in 2.412 s and integrity_check in 8.797 s, both returning "ok". The snapshot and original were checked at different times with uncontrolled cache and system-load conditions. Additional mmap experiment On the same offline snapshot: A: mmap_size=0, executed first, quick_check took 31.070 s and was interrupted. B: reported mmap limit approximately 2 GiB, executed second, quick_check returned "ok" after 22.146 s. Cache conditions and host load were not equivalent, so these observations do NOT establish an mmap performance improvement. A separate deliberate mapped-I/O error test ended with SIGBUS in an isolated child process. This does not establish an ordinary APFS defect. Questions Which supported macOS Instruments templates or APIs can correlate pread offsets, sizes and timings with physical disk latency, filesystem cache activity, memory pressure and thread scheduling, without disabling system security protections? What minimum set of simultaneous observations could distinguish cache misses, APFS metadata/layout overhead, physical device delays and CPU scheduling contention? How should process read-byte counts be interpreted against physical disk I/O? How should I safely compare read-only SQLite mmap against normal pread access on disposable copies, without mistaking a warmer second run for a performance gain? What SIGBUS containment and recovery checks would be appropriate? I am primarily looking for a reliable instrumentation plan and interpretation criteria before conducting further tests. I do not want to modify the original database, weaken integrity checks or bypass security controls.

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.

Hello, I am working on a backup process on macOS. Before copying files, the script needs to check that it is looking at the correct mounted backup volume. A fictional example A user opens an encrypted disk image called ExampleBackup.sparsebundle and enters the password themselves. The volume then appears in Finder as ExampleBackup. Before copying anything, the script needs to confirm: This mounted volume actually belongs to the intended disk image. The volume is mounted read/write. File ownership is being enforced. The destination has not been replaced or changed since the previous check. Simply checking the volume name or its path does not seem sufficient: another volume could have the same name, or a device name could be reused after ejecting and reconnecting an image. My questions What supported macOS API or command should a script use to establish this relationship reliably? Can we rely on specific fields from hdiutil info -plist and diskutil info -plist <device>? If so, where are their meanings and limitations documented? How should the script distinguish “no” from “unknown” when information is missing or a check fails? What should it check again immediately before copying, since the volume could change between separate checks? The checks themselves should only read information. They should not unlock or mount images, change permissions, or disable any security protections. If the script cannot confirm the destination safely, it should stop. A recommended approach or small example would be very helpful. Thank you.

I'm developing SipBudget, an iPhone app that will store manually entered alcohol-consumption records locally using SwiftData. The app will not use CloudKit synchronization, HealthKit, or a developer-operated cloud database. I understand that App Review Guideline 5.1.3(ii) prohibits storing personal health information in iCloud. I would appreciate technical guidance on two questions: Can a local SwiftData database be reliably excluded from ordinary iCloud device backups? If so, what is Apple's recommended implementation for ensuring that the database and related files remain excluded, including after database updates or migrations? I'm asking before implementation so I can design the storage architecture correctly. Thank you.

Configuration being evaluated: macOS 15.4.1 (24E263), Apple silicon, Apple's native APFS, and an existing executable that calls fsync(fd) on an already-open regular file. This is the selected configuration for our question, not a claim that a new runtime qualification has been completed. We need to preserve the executable's original call semantics and the native APFS target. We are not proposing a replacement filesystem, a modified fsync implementation in the executable, or a private kernel patch. Is there a documented, customer-deployable interface for synchronously rejecting this particular fsync request before the filesystem accepts or begins the synchronization work attributable to that request? The critical schedule is: an initial check allows the request; execution is delayed; a deadline expires or the originating thread/operation loses its authorization; the request then tries to begin. We need to know whether a supported interface can prevent that still-unstarted request from proceeding, rather than merely report an error after it has begun. If such an interface exists, please identify: The API and supported OS versions, including availability on the configuration above, plus any entitlement, component, signing, or deployment requirements. The precise event where allow/deny takes effect, and the caller, file-object, and request identity available there, including an already-open descriptor. Whether authorization remains revocable after an allow response and before execution. If any timing guarantee is offered, its exact interval, assumptions, and documented bound. Whether denial, an enforcement timeout, or loss of the enforcing component prevents this request's synchronization work, or can occur after that work has started. We distinguish request admission, filesystem execution, return, and persistence completion. We do not assume that an earlier authorization marker is the execution boundary. We are asking about work attributable to this request, not unrelated background writeback, and are not asking for a bound on completion of an already-started fsync. We will separately evaluate how any documented platform guarantees can be bound to our application's authority and lifetime rules. If no supported interface provides the stated control on this configuration, please confirm that scope. If a route requires a different OS version, executable, filesystem, or deployment policy, please identify that change explicitly. This is an API/support-scope question; no proprietary source code or project archive is attached.

We are evaluating a separately App-Sandboxed GUI helper for one explicitly reviewed AIFF NAME edit on internal-disk APFS. The main app retains user-selected read-only access. The helper has only App Sandbox and user-selected read/write entitlements. We would like the supported API and failure/reconciliation contract before implementing physical-file edits. Bounded observation A local synthetic-fixture probe used macOS 27.2 (26B118), SDK 27.0, arm64, ad-hoc signing with Hardened Runtime, LaunchServices and the helper's own NSOpenPanel. Captured stat fields, raw xattrs and bytes were unchanged after selection and an O_RDONLY read. Across a later O_RDWR open/fstat/close gate, com.apple.quarantine was added and ctime changed; bytes stayed identical and close returned 0. There was no content-write call. This describes one observed build/run, not a general OS mechanism. We have not tested copyfile, clonefile or replacement paths. Questions Existing-file conflicts. We read the later DTS explanation in thread 850377 about path-based link/rename substitution limits. Our use case is an ordinary editor replacing an existing user-selected file while another uncoordinated app might edit or replace it. What supported pattern and limits should we use to avoid silently overwriting unrelated updates, detect conflicts and retain truthful indeterminate outcomes? Is any supported replacement operation conditional on the previously reviewed destination object/content version, or should that guarantee be treated as unavailable under this concurrency model? We do not assume a post-operation identity check prevents an earlier effect. Protected metadata. What preservation contract should this sandboxed helper rely on for quarantine/provenance, ACLs and unrelated xattrs through copy/clone, a native-field edit and replacement? The current copyfile/clonefile manuals describe metadata copying and exceptions, while FileManager replacement documents selected original metadata. If exact raw quarantine equality is not the supported invariant, which public properties or behaviors should verification check, including originally absent quarantine? We want to retain Apple's security semantics without stripping quarantine, normalizing undocumented flags or disabling App Sandbox. Replacement access. After selecting an existing file in NSOpenPanel, is FileManager's itemReplacementDirectory plus replaceItemAt a supported safe-save route under that file selection? What additional consent, if any, is required for temporary-file creation and namespace publication? We do not assume parent-directory access or propose adding selected-source write rights to the main app. Relevant references: FileManager replacement File coordination No user media, paths, saved grants, private logs or binaries are attached. We are seeking supported semantics and refusal boundaries before further implementation or experiments.