“sandbox”

Thanks for looking into this. Re: timing — I can't give you a clean before/after-26.5 comparison. This specific NFS mount setup only went live on 2026-07-03, and I was already on 26.5.1/26.5.2 (25F84) at that point — so I have no data on this exact mount configuration under an earlier OS version. I did run a different mount method (SSHFS/macFUSE) at the same path before that, on earlier OS builds, but it failed differently (kext/Gatekeeper corruption), not with this deny(1) signature — so I can't say this is a regression tied to a specific OS version, only that it's new since I switched mount methods. Re: the StorageKit/r.171126338 log line — the timestamp you posted (2026-07-05 10:52:14+0200) lands within seconds of a deny(1) cluster I already captured a full sysdiagnose for (10:52:11–10:52:54, attached to FB23576006). I'll dig through that archive specifically for the StorageKit/SKManager entries around r.171126338 and report back what I find. Re: the workaround — good lead, and it lines up with something I

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. Did this JUST start happening in 26.5? If not, do you know when it might have started? There was change at that time (r.171126338) which also introduced this error: 2026-07-05 10:52:14.292554+0200 diskutil: (StorageKit) [com.apple.storagekit:general] -[SKManager _diskForPath:isNetworkMount:]: open() failed: errno=1 I'm not sure how that would then connect to the failure you're seeing, but I think it might be connected to this. or has a workaround, So, the one thing I would try is moving the mount point out of /Users/Shared/ and into a location you more directly control- either a new directory in your home directory or a new directory you create within the system hierarchy. Creating your own directory helps shift you out of the systems normal view, which can reduce the possibility of unrelated activity disrupting you

@DTS Engineer I think your explanation is not entirely accurate. Actually the sandbox is already treating different system components differently. Therefore it seems very unlikely that the sandbox can not distinguish between allowed and forbidden network traffic. MapKit is an encapsulated system component, so it is more or less impossible for a Quicklook extension to send random and uncontrolled network requests. All the network access is completely controlled by the system. So it seems extremely unlikely that there are serious security issues here. BTW: in the past, MapKit did work in Quicklook extensions. On the other hand, WebKit (WKWebView) is(!) working in Quicklook extensions just fine. But unlike MapKit, WebKit is able to do random and uncontrolled network requests, therefore could be a security issue. Which means the sandbox is actually distinguishing between different system components. The harmless one it does block, the dangerous one it let pass. I do understand that WebK

[quote='837008021, DANgerous25, /thread/837008, /profile/DANgerous25'] The iOS entitlement com.apple.developer.shazamkit is rejected by the macOS validator at upload [/quote] My undestanding is that this entitlement isn’t valid on iOS either. See here. [quote='837008021, DANgerous25, /thread/837008, /profile/DANgerous25'] Is it correct to place the exception on the main app … rather than on the helper itself? [/quote] That depends on how you run the helper. If you spawn it as a child process then it inherits your app’s static sandbox and thus adding entitlement to the parent app is the right choice. As to your main issue, am I right in assuming that this nested helper stuff isn’t a factor there? That is, the behaviour you’ve described applies regardless whether you run the code in your helper or in your main app? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I have same problem. There always a monthly subscrition . Can't clear by sandbox

observed that mastercard from sandbox can be added with activating status. the card is activated after one day activating.

If you are using TestFlight, then Sandbox would be used. To clear purchase history in sandbox please follow instructions in https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox#Clear-the-purchase-history-for-a-Sandbox-Apple-Account For me personally clearing purchase history didn't work https://developer.apple.com/forums/thread/829459 Please let me know if it works / doesn't work for you, thanks!

Your question is primarily about App Store policy. I don’t work for App Review and can’t offer definition answers about there policy. What I can say is that our documentation makes it clear that the Accessibility APIs are not supported in sandboxed apps. See the Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Is this affecting an app that you’ve built? Or are you seeing this with apps built by other developers? For context, the immediate cause of this crash is an app container ownership check. When a sandboxed app first launches, the system creates its app container and records information about the app’s identity into that container. The next time the app launches it checks that that this is the same app. This prevents a malicious app from impersonating some popular app and snarfing up its data. This “same app” check is based on code signing requirements. See TN3127 Inside Code Signing: Requirements. Something has gone wrong with that check in your case. I’m not aware of any specific reason why this check would suddenly start failing for your app. To understand what’s going on I’ll need a bunch of information from you, and hence the question above is the first of many (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com