“We are unable to process your request”

What you'll find is that there are two clients— yours and a (presumably unrelated) 3rd party client. The other ES client is basically a 3rd party logger that's not active. Ours does some auth work, but we're fairly certain in this case it's just monitoring to do reporting and follow-up scans. Do you know exactly what kicked off your helper process? Both in terms of the triggering event and the target file? No. At the time, the system had been idle for 2 hours. In this case, we do observe a system update being staged in the background, but not in all other instances. I suspect it was a FILE_NOTIFY_CLOSE. It would be insightful to know if APFS triggers that or related ES events when decompressing a file. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. I will submit unified logs that cover the period in question, but your point remains. That ES check can

This sounds like a general synchronization issue, and so you can probably start with the technotes mentioned in this post to hopefully figure out the cause of the issue. NSPersistentCloudKitContainer supports many-to-many relationships. Before seeing an evidence that proves it doesn't work (by going through the debugging process the technotes describe), I probably won't change the Core Data model. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thank you for sharing your post. I understand that it can be frustrating, especially when the job is impacting your daily routine. I am eager to assist you in any way I can. I have a potential idea, but I would like to request a bug filing for further investigation. Typically, authentication tokens expire after a few hours. In a stable build, Xcode silently uses a “refresh token” to obtain a new session in the background. Consequently, the system may be terminating your session when the initial token expires. This is an issue that requires immediate attention. However, I am only speculating about the cause. Given that this issue is occurring across two separate computers and began specifically in beta 3, it is highly probable that the problem lies within the beta itself rather than a misconfiguration on your end. Instead of simply signing out and signing back in, I recommend completely deleting the integration from Xcode. Navigate to Xcode > Settings > Accounts (or the specific Claude Agent set

Thank you for the detailed guidance. After performing a full reset on all devices as you suggested, the OTA process completed successfully through the TestNet backend. Good! There isn't a good way to know for sure, but I suspect the HomePod was hanging on to an expired profile which then confused the rest of the system. I appreciate your help in resolving this! You're very welcome. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Let me start by saying two slightly contradictory things: It's very likely that there is an APFS bug here, so if you haven't already, please file a bug on this and post the bug number back here. It's ALSO very likely that your ES client (possibly both ES clients) are required to actually experience this bug, and you should address it as well. Next, I think I want to be clear that some of what I'm saying is a bit of an educated guess. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. That doesn't invalidate what I'm describing above, but I do think it's important to have some awareness of the limitation of the data at hand and that, most importantly, new data could totally change our understanding of the overall state of things. Getting into the details: But here, I don't see such things. When EndpointSecurityEventManager is on the spindump, it's only because they

Thank you for your post. The App Store team does not monitor the forums, and I believe you set your app as “Made for Kids” for the first time when you deployed the app. Since your app is already live, the “Made for Kids” flag and the “Kids” category are often locked to prevent developers from changing an app’s target audience without parental consent. This will be a significant privacy issue as you can see. To resolve a locked metadata field like that, you need to contact App Store Connect Support, not App Review. Visit the Apple Developer Contact Us page. The representative can file an internal ticket directly to the App Store Connect engineering team to manually unstick the metadata field on your account if appropriate. Now, depending on your app and the people affected by that change, the engineering team will decide whether to make that change. I’m not in that team now I know their process. Once App Store Connect Support unlocks the field and you successfully uncheck “Made for Kids,” you can subm

Hi, @Dominik_2 I'm a little late here but I'm having the same issue. Did you ever figure this out? I can't even get a 2019 Mac Pro to properly activate LOM and a 2023 Mac mini which gives me the same Address Already In Use error. Here's all my testing and info. Apple are you there??? Infrastructure: • Mac mini 2023 (M2, 10Gb Ethernet, MacMini.local, macOS 15.x Sequoia 15.7.4) — MicroMDM v1.13.1 • Mac Pro 2019 (MacPro7,1, Intel T2, MacPro.local, macOS 15.x Sequoia 15.7.5, T2 firmware 23P3120) • Both supervised via Automated Device Enrollment (DEP) through Apple Business Manager • Both enrolled: IsSupervised = 1, APNs working on both • Both are Controllers and Clients LOM Current State: Mac mini (Apple Silicon M2): • LOM profile installed ✓ • lom0 interface active ✓ • Port 55555 listening on * ✓ • LOMDeviceServerColsolidated path (Apple Silicon) ✓ • com.apple.AppleLOM.XPC active=1 ✓ • com.apple.AppleLOM.Watchdog active=1 ✓ • Mac Pro CAN reach mini's lom0 port 55555 — TCP connection established ✓ • BUT connectio

You can formally request new API functionality, like an animated map layer of wind data, through Feedback Assistant.

Regarding fclonefileat API, my expectations are actually met in macOS 26.4 now - I do expect that the Kernel is capable of rejecting invalid calls of clonefile API and does fail the operation. It is tricky to predict the future as there might be new regular file types that might not be clonable/will become clonable, so I always delegate the file clonability decision to the Kernel. So, stepping back for a moment, my larger advice here in terms of future proofing would actually be to avoid the direct call to clonefile and instead call copyfile. While kernel panic'ing is a relatively extreme failure, clonefile is a low-level syscall, and I'd fully expect that there can/are/will be edge cases where clonefile fails and copyfile does not. The difference here is a matter of API role - clonefile is only designed to do the specific task of sending a specific request to the VFS system, while copyfile() is designed around the broader job. If you specifically want to fail in any case where a file can't be cloned