Seems that the /bin/cp command has an arg for accomplishing something similar to the Finder based copy. cp -c : copy files using clonefile(2) Also, The f_fsid related observations/content in my first comment on this post is not correct. Thanks @eskimo for correcting me regarding that st_ino and f_fsid are not related.

Greetings, It turns out that feature-info I was looking for is about an APFS feature called Copy-On-Write-Clones . I was able to view documentation on it so I am good for now. For Finder copy-operations, with destination being the same volume, APFS seems to be creating the new file with different meta-data but the file shares the same data-content as the original. During my tests, I found that copying a 1GB file on the same volume via Finder did not decrease the available space on the Volume by 1GB. What was cool was that if I appended to the new File, then the disk-available-space gets decreased by only the bytes that were appened to the new File. So, the Sharing of data-content/blocks continues even post the edit. I ran some more tests with Finder and /bin/cp command. 1). As expected, the same Finder copy operation on HFS+ volumes has a different behavior than Finder copies on APFS. 2). However when comparing Finder-based-copy operation with cp-command copy operation on MacOS-APFS, the behavior strangely differs when it comes to CopyOnWriteClones. Not sure why, but /bin/cp command is generating new files without sharing the Data blocks of original and the space-saving is not occurrinig; Finder based copies on the other hand are exibiting the space-saving behavior. Thanks, Vikram.S.Warraich.

Thanks @eskimo. Any documentation regarding MacOS Finder/FS's Space-Saver feature or how it is implemented ?

@eskimo , Thanks a lot. Issue seems fixed in MacOS 14.2 build 23C63.

@eskimo , Is there a way to request raising the priority of this issue ? There hasn't been any movement on the ticket FB13342978 yet. We are getting more reports of our customers running into this issue.

Thanks @eskimo . Created FB13342978.

@eskimo , I was able to repro the issue yesterday and inspect the logs. Sharing the possible ways below. 1). One way that It occurs for me is if I modify the system time to a future date via SystemPreferences and reboot. Issue occurs on next login. 2). Another way it occurred was if I set the FDA setting in System Preferences and then quit the tccd process owned by the logged-in user, and rebooted. 3). There are other possibilities too as my colleague can repro it without having to run steps 1 or 2. Attaching some relevant Log snippets from around when the issue occurs. SysDiagnosisLogSnippets.txt Please confirm if If above repro steps are known issues and covered by FB13084552 or FB13194377 ? Else, I can create a ticket for those scenarios. Regards.

@eskimo , What is the best way to view the description of FB13084552 or FB13194377. When I try to look either of them up in the FeedbackAssistant, there are no search results. I might not have access to view them possibly ?

@eskimo , Thanks for your reply. If it helps, I was able to observe the issue yesterday without requiring to REBOOT. The relevant FullDiskAccess Item for SystemExtension in SystemPreferences got unchecked while being logged in after after 4-5 hours. This is on 14.2 Beta 23C5030f. Also, I don't have access to FB13084552 . Could you please share any information about its relevancy to the issue I described ? Regards, Vikram.S.Warraich

Regarding my previous comment... Issue was observed on MacOS 14.1 . Issue occurs when FullDiskAccess is provided via the SystemPreferences->Privacy&Security->FullDiskAccess setting. AFAIK, Issue does not occur when FullDiskAccess is provided via MDM. The Full Disk Setting items in SystemPrefs get unchecked/disabled automagically after some reboots when the issue occurs. Thanks.

Hello, Any update regarding this ? I am running into this issue too. Issue: Full Disk Access setting for a Network/System Extension is getting cleared after a reboot on MacOS Sonoma. Issue does not occur with every reboot. Not sure if it gets cleared before/during/after the reboot yet. Including some relevant logs. <BEFORE/DURING REBOOT> error 2023-10-27 16:45:19.897037 -0700 tccd codeRequirementFromStaticCode:0x13f60a890 SecStaticCodeCheckValidity() fails: -67061 error 2023-10-27 16:45:19.898763 -0700 tccd Failed to post com.apple.tcc.access.changed notification (9) default 2023-10-27 16:45:19.900235 -0700 launchd exited due to SIGKILL | sent by tccd[164] during system shutdown default 2023-10-27 16:45:19.900243 -0700 launchd internal event: EXITED, code = 0 <STARTINGUP/AFTER REBOOT> error 2023-10-27 16:45:56.160784 -0700 runningboardd memorystatus_control error: MEMORYSTATUS_CMD_CONVERT_MEMLIMIT_MB(-1) returned -1 22 (Invalid argument) error 2023-10-27 16:45:56.394864 -0700 cfprefsd Couldn't open parent path due to [2: No such file or directory] fault 2023-10-27 16:45:56.406378 -0700 mDNSResponderHelper Couldn't read values in CFPrefsPlistSource<0x156e07600> (Domain: com.apple.security, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: No): accessing these preferences requires user-preference-read or file-read-data sandbox access error 2023-10-27 16:45:56.440578 -0700 kernel System Policy: dirhelper(252) deny(1) file-write-unlink /private/var/folders/zz/zyxvpxvq6csfxvn_n00000sm00006d/T/com.apple.geod/42B44A5C-6F69-441A-B4AF-F249709618EF There are some errors from endpointsecurityd error 2023-10-27 16:45:57.590703 -0700 endpointsecurityd File was empty: /Library/SystemExtensions/EndpointSecurity/.started_es_jobs.plist fault 2023-10-27 16:45:58.372379 -0700 endpointsecurityd Rejected invalid Extension Point com.apple.AppleMediaServicesUI.EngagementViewExtension targeting DEPRECATED NSExtension infrastructure! error 2023-10-27 16:45:59.482270 -0700 trustd Connection 1: received failure notification error 2023-10-27 16:45:59.482284 -0700 trustd Connection 1: failed to connect 1:50, reason -1 error 2023-10-27 16:45:59.482285 -0700 trustd Connection 1: encountered error(1:50) error 2023-10-27 16:45:59.482537 -0700 trustd Task <20F8D91C-D278-4001-A127-FD168B888BB6>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50]) ..... [self.extensionContext conformsToProtocol:auxHostProtocol.protocol] - /AppleInternal/Library/BuildRoots/11aa8fb2-5f4b-11ee-bc7f-926038f30c31/Library/Caches/com.apple.xbs/Sources/ExtensionFoundation/ExtensionFoundation/Source/NSExtension/NSExtensionSupport/EXExtensionContextImplementation.m:283: Class NEFilterPacketExtensionProviderContext does not conform to aux host protocol: ...... error 2023-10-27 16:46:02.717195 -0700 VTDecoderXPCService send_message_with_reply_sync(): XPC_ERROR_CONNECTION_INVALID for message 0x600002db0180 error 2023-10-27 16:46:02.717195 -0700 VTDecoderXPCService TCCAccessRequest_block_invoke: Connection invalid Regards, Vikram.S.Warraich

More Information. We are seeing identical behavior on Catalina. There are 2 Primary Groups being reported for Mobile Login users. Can someone please Answer if this behavior is by Design ?

More Information: I just now Observed the issue when the Primary group for the Mobile Login User on the AD Server is switched to a different Group on the AD Server.  I don't know why MacOS implements it this way, but there seem to be 2 instances of that user in 2 different NODES in DirectoryServices. These instances have the EXACT SAME UniqueID. One of these NODES is the /Local/Default node, which I assume is for the scenario when the Mobile Login user is not connected. The other NODE is the /ActiveDirectory/domain node, which might be referred to for the when-connected-to AD scenario. After switching the Primary group on the AD Server for that user, only one of the above NODE is getting updated. The above results in the account getting 2 Instances of Primary Group when the Tool is querying via the OpenDirectory/DirectoryServices Framework. It is unclear to me if this behavior is a Big Sur issue OR occurs on earlier MacOSes OR is by Design this way.