Alternatively, is there a way for a script to set this option in System Settings?

Actually, the program is a test program, and the answer to the question will be used to create a file name for a screen shot of the application window so that I know what the screen shot represents. FB20868055

Thank you! That subtle change makes the difference.

I configure Java with: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 Java says: Listening for transport dt_socket at address: 5005 nc from the other machine says: nc -v mac-mini.local 5005 nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc: connectx to mac-mini.local port 5005 (tcp) failed: Connection refused nc on the same host says: Mac-mini:13 alan$ nc -v localhost 5005 Connection to localhost port 5005 [tcp/avt-profile-2] succeeded!

I take it back. That error message is written even after I have agreed, whether or not I run using sudo.

Actually, it appears that sudo is not required to determine the status. xcodebuild -license >junk 2>error will write an error message to stderr if a new agreement is needed.

sudo xcodebuild -license run it in an empty directory so it doesn't actually build anything. Except I'm running this from a program and I don't want to ask the user to do anything (including entering a password). I just want to find out the license status. If the status is OK, the program should keep running without user interaction.

Uninstalling Little Snitch and restarting fixed the problem. Thank you!

In the above test, the remote volume is APFS. If I try using an HFS+ volume, the client can delete R2 with no problem. I figured the difference was APFS using copy on write. However, if I rename (mv) the copied volume on the server, the client still can delete it on the HFS+ volume (and still fails to delete it on APFS).

Some surprising results: (client) I copied runtime-x86 to the server [R] (server) I duplicated R [R2] (client) I tried to delete R2 — it fails (Contents/Home/conf not deleted) (server) restarted File Sharing (server) I duplicated R [R3] (client) no errors listing R, R2, R3 (client) I tried to delete R3 — success (server) I duplicated R [R4] (client) I tried to delete R4 — success (client) I tried to delete R and R2 — success

It remains to be seen if only trying to delete directories that are known to be empty avoids this problem. I tried this and it does not solve the problem. The directory that mysteriously fails to delete is reported to be empty just before I try to delete it. Although deferred deletes may play a role in determining which directory fails to delete, I think an incorrect cache is the root of the problem.

There does seem to be a special case. When rm tries to delete the parent of a directory that is known to be non-empty, it gets an error response.

Revising my last point, if actual deletion is performed asynchronously, then presumably there is a queue of items waiting to be deleted, and it does not matter which directory elements are still present when the attempt is made to delete the directory. It does not have to be the last one.

However, keep in mind that this is a problem in the other direction as well. That is, the client cannot delete all the files it knows about and then assume the directory is empty, as someone else can be creating files at the same time it's deleting them. I don't believe that this particular problem can be blamed on interference from other known parties, such as Finder or MDS. Such interference would only temporarily prevent a directory being deleted. As far as I can tell, the inability to delete the directory persists until File Sharing is restarted. (I'm not worried about rogue agents that perpetually create and delete files.) Recall that after restarting FIle Sharing, the client regained the ability to list the directory tree. Just now, in this state where clients can list the directory tree, I made another attempt to delete the (remaining) tree, and it failed (but not at the same directory). Mac-mini:test6 alan$ rm -rf V* rm: VAquaManager.app/Contents: Permission denied rm: VAquaManager.app: Permission denied Mac-mini:test6 alan$ ll V* total 32 drwxr-xr-x 1 alan staff 16384 Feb 28 12:02 Contents Mac-mini:test6 alan$ ll -R total 32 drwxr-xr-x@ 1 alan staff 16384 Jan 14 19:59 VAquaManager.app ./VAquaManager.app: total 32 drwxr-xr-x 1 alan staff 16384 Feb 28 12:02 Contents ./VAquaManager.app/Contents: total 32 drwxr-xr-x 1 alan staff 16384 Feb 28 12:02 runtime-arm ./VAquaManager.app/Contents/runtime-arm: total 0 ls: fts_read: Permission denied There are problems reading the directory, but apparently no problems reading the directory metadata. (I'm not sure if this is new, as I had not tried all of these commands before now.) Mac-mini:test6 alan$ ls -l VAquaManager.app/Contents/runtime-arm total 0 ls: fts_read: Permission denied Mac-mini:test6 alan$ ls VAquaManager.app/Contents/runtime-arm ls: fts_read: Permission denied Mac-mini:test6 alan$ xattr -l VAquaManager.app/Contents/runtime-arm Mac-mini:test6 alan$ stat VAquaManager.app/Contents/runtime-arm 905970052 275529348 drwxr-xr-x 1 alan staff 0 16384 "Feb 28 12:13:31 2025" "Feb 28 12:02:56 2025" "Feb 28 12:02:56 2025" "Jan 14 19:59:24 2025" 4096 32 0 VAquaManager.app/Contents/runtime-arm Mac-mini:test6 alan$ ls -ld VAquaManager.app/Contents/runtime-arm drwxr-xr-x 1 alan staff 16384 Feb 28 12:02 VAquaManager.app/Contents/runtime-arm The evidence at this point, along with your explanations, is that the problem is bad state in the file sharing daemon. What kind of state could this be? You say that caching is not useful, but it sure seems like some caching is happening. From a performance perspective there is a pretty ENORMOUS performance benefit to SMB "assuming" operations will succeed and proceeding forward with a command stream instead of individually waiting on every single action. If this is known behavior, clients can be written to double check when needed (accepting the performance hit). However, I won't hold my breath waiting for a new command line argument to rm. It remains to be seen if only trying to delete directories that are known to be empty avoids this problem. It also doesn't explain what makes this particular directory different. When trying to delete the last item a directory, returning success too soon could cause failure on the attempt to delete the directory. Perhaps something about these directories increases the odds of a delay in the deletion of the last item that is too large.

I just noticed something interesting in these (old) results: Mac-mini:test alan$ rm -rf VAquaManager.app rm: VAquaManager.app/Contents/runtime-arm/Contents/Home: Permission denied rm: VAquaManager.app/Contents/runtime-arm/Contents: Permission denied rm: VAquaManager.app/Contents/runtime-arm: Permission denied rm: VAquaManager.app/Contents/runtime-x86/Contents/Home: Permission denied rm: VAquaManager.app/Contents/runtime-x86/Contents: Permission denied rm: VAquaManager.app/Contents/runtime-x86: Permission denied rm: VAquaManager.app/Contents: Permission denied rm: VAquaManager.app: Permission denied Mac-mini:test alan$ xattr -lr VAquaManager.app xattr: [Errno 13] Permission denied: 'VAquaManager.app/Contents/runtime-arm/Contents/Home/conf' The file VAquaManager.app/Contents/runtime-arm/Contents/Home/conf was not deleted, but rm did not complain about it. It only complained about its parent, which could not be deleted because it was not empty. That tells me that the system call did not return an error, which makes me think that the file sharing daemon returned an OK status before it was known that the directory was not deleted. I observed this problem earlier when using my own program to delete. It is what made me think that operations were being performed out of order. Regarding Finder, the client Finder responds quickly when a change is made on the server. I assume it getting notifications of changes, which implies that the file sharing daemon is also getting notifications of changes. That could explain how caching done by the file sharing daemon could get out of sync with the file system. It could also be that the file system's implementation of FSEvents is causing the problem. When file sharing is turned off, the FSEvents listeners are unregistered and any associated state in the file system is presumably flushed. The problem is to explain why local FS operations do not fail. Does the file sharing daemon use alternative or private APIs to read directories?