We are seeing similar issue, reported as FB8996394.     [x86_64] libnetcore-2288.100.93   0 libnetwork.dylib          0x00007fff247b10d8 __nw_create_backtrace_string + 120   1 libnetwork.dylib          0x00007fff243f5004 nw_context_is_inline + 276   2 libnetwork.dylib          0x00007fff24358d2e nw_queue_context_async + 46   3 libnetwork.dylib          0x00007fff2477efd4 nw_interpose_handle_path_update_locked + 372   4 libnetwork.dylib          0x00007fff2477ee3c __nw_interpose_start_block_invoke.3 + 108   5 libdispatch.dylib         0x00007fff203ad673 _dispatch_call_block_and_release + 12   6 libdispatch.dylib         0x00007fff203ae856 _dispatch_client_callout + 8   7 libdispatch.dylib         0x00007fff203b64cc _dispatch_workloop_invoke + 2140   8 libdispatch.dylib         0x00007fff203bec5d _dispatch_workloop_worker_thread + 811   9 libsystem_pthread.dylib      0x00007fff205554c0 _<…>

Quinn, We did test with uploads of 100 times 25MB, the result was that the first run 0/100 failed, the second round 1/100 failed. In production builds we are doing notarization uploads of 25, 40, 120, 700 MB and this is repeated 2 times, so in total 8 uploads for notarisation. In this case it seems that during working hours in CET the probability of failure with the above error is more that 50%, but if made out side working hours it will in most cases succeed.

Hi Gualtier Malde, thank for confirming my findings. It seems strange that you can't approve BT for an app using an MDM as you can for a users Desktop/Documents/Downloads folder. Is this something intentional or is it going to b implemented as part MDM Privacy Preferences payload to grand BT access for system apps/daemons? Thanks