After upgrading to MacOS Sequoia, MacOS no longer connects to an existing WebDAV sync target. This behavior was not present on MacOS Sonoma, and I've validated this against another Mac running Sonoma.
After entering the sync username/password, and clicking "check synchronizaton settings", the following error is presented: Completed: 24/09/2024 19:31 (21s) Last error: FetchError: request to https://192.168.1.11/Shared/Joplin/info.json failed, reason: connect EHOSTUNREACH 192.168.1.11:443 - Local (192.168.0.70:61736)
Connectivity is on the same network, same subnet (/22) and this setup has worked for the past few years uninterrupted. Windows and Linux clients are unaffected by this behavior.
Expected behaviour
I would expect a successful connection without any errors, as was present in previous versions of MacOS
Logs
The logs in the development tools don't seem to indicate any issues; I posted in the Discourse, but my post was temporarily hidden, and this post contained several logs. Once that post is un-hidden, I will transfer the logs & details here, but I believe this is a BUG behavior moreso than a support request given my testing.
kmanwar89
commented
6 days ago
Operating system
macOS
Joplin version
3.0.15
Desktop version info
Joplin 3.0.15 (prod, darwin)
Client ID: 7368c42332fe4ba4a68d7dffba0fcc69 Sync Version: 3 Profile Version: 47 Keychain Supported: Yes
Revision: 598677b
Backup: 1.4.1
Current behaviour
After upgrading to MacOS Sequoia, MacOS no longer connects to an existing WebDAV sync target. This behavior was not present on MacOS Sonoma, and I've validated this against another Mac running Sonoma.
After entering the sync username/password, and clicking "check synchronizaton settings", the following error is presented:
Completed: 24/09/2024 19:31 (21s) Last error: FetchError: request to https://192.168.1.11/Shared/Joplin/info.json failed, reason: connect EHOSTUNREACH 192.168.1.11:443 - Local (192.168.0.70:61736)Connectivity is on the same network, same subnet (/22) and this setup has worked for the past few years uninterrupted. Windows and Linux clients are unaffected by this behavior.
Expected behaviour
I would expect a successful connection without any errors, as was present in previous versions of MacOS
Logs
The logs in the development tools don't seem to indicate any issues; I posted in the Discourse, but my post was temporarily hidden, and this post contained several logs. Once that post is un-hidden, I will transfer the logs & details here, but I believe this is a BUG behavior moreso than a support request given my testing.