As a longtime DT user, I have a number of databases saved in old-style iCloud. I am trying out the new CloudKit method of saving, but not having any luck getting it into iCloud. It keeps telling me there is a network failure in the log. How might I go about diagnosing this?
Here is what the log window shows:
According to the screenshot it is indeed a network issue, at least that’s the error returned by macOS. How fast/reliable is your internet connection, especially the upstream? Does a reboot of the computer and/or router fix this?
And are you really saving the DEVONthink database (the MacOS “package”) to iCloud?
Page 12 of the Ver 3.8 DEVONthink Handbook covers this with a warning:
Note: You cannot create or store a database in a cloud-synced folder, e.g., iCloud Drive or Dropbox. This is not data- safe so the behavior is explicitly disallowed. The advocated location is a folder in your home directory, like ~/Databases. If you try to open a database in one of these locations, you will be prompted to let DEVONthink move the database, or reveal it so you can manually relocate it.
Hi @cgrunenberg. My network connection is quite good and I am indeed able to do other Internet things (like posting to the DT forum 
). I see that my iCloud (Legacy) databases are syncing without problem. I have also tried adding another database to CloudKit sync and it also fails. It appears that DT uploads the individual records, but only gives the error at the end.
[EDIT]
I forgot to mention that I did a reboot of Mac, with no change.
Hi @rmschne, sorry I was imprecise; I am syncing not saving:
Please try whether reducing the number of max. connections (see Preferences > Sync) will make a difference.
I have dropped the number of connections to 1 and still no luck 
Did you try to reboot the computer and/or router as suggested?
I did and no change
Could be related to this?:
Since yesterday night, at least in The Netherlands, I’m experiencing some strange behaviour in iCloud.
Good find @rfog. I just looked at the Apple status page and it says it was resolved almost 2 days ago
11/23/2021, 10:45 AM - 12:20 PM
Some users were affected
I’m not much confident in those panels. When they say issues, you are sure there are, but when not… However I’m not saying that that is your case.
(I remember a couple of weeks ago, OVH in fire (real fire) most systems off, and all green until a couple of hours after. Or TeamViewer, completely down, TV staff saying only minimal partial outage, until people started to complain high and loud in Twitter and finally they recognised total outage. I think they use to do those things due up-time rules, some contracts have mandatory minimal outages or they have to pay fines).
I’m not much confident in those panels. When they say issues, you are sure there are, but when not… However I’m not saying that that is your case.
Agreed in the lack of confidence. I’m reasonably certain that’s not a real-time status board. However, I do think it updates more frequently than once a day 
So this is interesting. Syncing via CloudKit fails, but the Legacy sync works just fine. Unfortunately, I have fallen down on the job recording my Legacy secret key, so I cannot get any of the databases into DTTG 3
Just as an FYI, Console does report cloudd errors:
|default|13:27:02.527612-0500|cloudd|Task <B42D87BE-40EC-45DA-B07E-DC02733A5C7C>.<141> {strength 0, tls 4, ct 0, sub 0, sig 1, ciphers 0, bundle 1, builtin 0}|
|---|---|---|---|
|default|13:27:02.528456-0500|cloudd|Connection 1174: enabling TLS|
|default|13:27:02.528501-0500|cloudd|Connection 1174: starting, TC(0x0)|
|default|13:27:02.528542-0500|cloudd|[C1174 3A3E77E7-66D0-43CE-B886-DC8F8027D154 Hostname#8f73a900:443 tcp, bundle id: com.devon-technologies.think3, url hash: cf0e3f3b, tls, context: com.apple.CFNetwork.NSURLSession.{D39853E1-8888-498F-B0D0-CCA2D5850A98}{(null)}{Y}{2}, proc: 4811B1D0-6340-35EE-87F7-6983E3DFEC4F, effective proc: 61DD113A-277A-3B80-A37C-44ACFE229548, no cellular fallback] start|
|default|13:27:02.529191-0500|cloudd|[C1174 Hostname#8f73a900:443 initial path ((null))] event: path:start @0.000s|
|default|13:27:02.529290-0500|cloudd|[C1174 Hostname#8f73a900:443 waiting path (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: path:satisfied @0.000s, uuid: 419842E8-1E81-446E-AC30-409CD9DD0256|
|default|13:27:02.529376-0500|cloudd|[C1174 Hostname#8f73a900:443 in_progress resolver (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: resolver:start_dns @0.000s|
|default|13:27:02.529396-0500|cloudd|nw_connection_report_state_with_handler_on_nw_queue [C1174] reporting state preparing|
|default|13:27:02.529831-0500|cloudd|Task <B42D87BE-40EC-45DA-B07E-DC02733A5C7C>.<141> setting up Connection 1174|
|default|13:27:02.530519-0500|cloudd|[C1174 Hostname#8f73a900:443 in_progress resolver (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: resolver:receive_dns @0.001s|
|default|13:27:02.530798-0500|cloudd|[C1174.1 IPv6#8642efdc.443 initial path ((null))] event: path:start @0.002s|
|default|13:27:02.530920-0500|cloudd|[C1174.1 IPv6#8642efdc.443 waiting path (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: path:satisfied @0.002s, uuid: 20084121-33E0-4CAA-92FA-94FBE38513B8|
|default|13:27:02.532566-0500|cloudd|[C1174.1 IPv6#8642efdc.443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: flow:start_connect @0.003s|
|default|13:27:02.539688-0500|cloudd|nw_protocol_boringssl_error(1752) [0x7f9b6daaebc0] Lower protocol stack error pre TLS handshake. [57: <private>]|
|default|13:27:02.539853-0500|cloudd|nw_flow_disconnected [C1174.1 IPv6#8642efdc.443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] Output protocol disconnected|
|default|13:27:02.540220-0500|cloudd|[C1174.1 IPv6#8642efdc.443 failed socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: flow:failed_connect @0.011s, error Socket is not connected|
|default|13:27:02.540368-0500|cloudd|[C1174.2 IPv4#26bec851:443 initial path ((null))] event: path:start @0.011s|
|default|13:27:02.540482-0500|cloudd|[C1174.2 IPv4#26bec851:443 waiting path (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: path:satisfied @0.011s, uuid: 4F66EA8A-EF97-4555-A630-0C4C72FEBF81|
|default|13:27:02.540925-0500|cloudd|[C1174.2 IPv4#26bec851:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: flow:start_connect @0.012s|
|default|13:27:02.542419-0500|cloudd|nw_protocol_boringssl_error(1752) [0x7f9b6ddde990] Lower protocol stack error pre TLS handshake. [57: <private>]|
|default|13:27:02.542489-0500|cloudd|nw_flow_disconnected [C1174.2 IPv4#26bec851:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] Output protocol disconnected|
|default|13:27:02.542699-0500|cloudd|[C1174.2 IPv4#26bec851:443 failed socket-flow (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: flow:failed_connect @0.014s, error Socket is not connected|
|default|13:27:02.542752-0500|cloudd|[C1174 Hostname#8f73a900:443 failed resolver (satisfied (Path is satisfied), interface: en0, ipv4, ipv6, dns)] event: resolver:children_failed @0.014s|
|default|13:27:02.542773-0500|cloudd|nw_connection_report_state_with_handler_on_nw_queue [C1174] reporting state failed error Socket is not connected|
|error|13:27:02.542795-0500|cloudd|Connection 1174: received failure notification|
|error|13:27:02.542819-0500|cloudd|Connection 1174: failed to connect 1:57, reason -1|
|error|13:27:02.542855-0500|cloudd|Connection 1174: encountered error(1:57)|
|default|13:27:02.542870-0500|cloudd|Connection 1174: cleaning up|
|default|13:27:02.542886-0500|cloudd|Connection 1174: summary for unused connection {protocol=(null), domain_lookup_duration_ms=0, connect_duration_ms=0, secure_connection_duration_ms=0, idle_duration_ms=0}|
|default|13:27:02.542927-0500|cloudd|[C1174 3A3E77E7-66D0-43CE-B886-DC8F8027D154 Hostname#8f73a900:443 tcp, bundle id: com.devon-technologies.think3, url hash: cf0e3f3b, tls] cancel|
From y reduced knowing how iCloud works, and I could be mistaken, it seems the server is not sending the SSL “challenge” to your Mac, then the connection is cut (surely by security reasons as not receiving the challenge). Most probable cause is the server that initiates or controls SSL is down.
(I had similar issue with Messages, who blamed me not having connection but was an inter-servers connection failure at Apple side. If you send that to Apple Tech support they will “flip snails”).
@rfog brilliant! Your description kicked me in the head to realize I’m an idiot. It turns out that there was a Little Snitch rule that prevented cloudd from getting to a particular AWS server. I’m not sure how it got there, but removing that rule has allowed the synchronization. Ugh, a problem of my own making!
Many thanks to all who assisted!
Yes, part of iCloud is in AWS. It was in Azure but they moved to other servers.
Glad to hear it.
Thanks for the follow-up and the gracious admission