Open kmanwar89 opened 2 months ago
@laurent22 I usually avoid tagging developers directly, but in this case I think the functionality is substantially broken due to the recent MacOS Sonoma upgrade. I've read lots of reports of network issues caused by changes in Apple's firewall and a few other things.
Is there anything we can do to restore this functionality? Downgrading isn't feasible as I don't have a TimeMachine backup, unless I manually backup everything and wipe from scratch (which I would rather not do if at all possible).
I usually avoid tagging developers directly, but in this case I think the functionality is substantially broken due to the recent MacOS Sonoma upgrade. I've read lots of reports of network issues caused by changes in Apple's firewall and a few other things.
Then isn't it something that Apple should fix? Or maybe there's a general fix for this, not specific to Joplin? My first thought would be to name that IP in /etc/hosts but I don't know if that would help
I'm not sure what the general fix might be or where the delination is made between the software maintainer and underlying OS, but as I mentioned in my post, other WebDAV targets are fine even on the 15.0 version of MacOS - it's only WebDAV in Joplin that seems broken. Other sync targets, such as OwnCloud, are fine in Joplin, so that narrows the issue further. I fully understand it's one of those gray areas, so I'm willing to be patient for a fix (and of course, thank you for releasing a product so many people use, it's truly a great piece of software!)
Apple released a 15.01 update on October 2nd according to 9to5 Mac and I just upgraded before making this post, but unfortunately the error is still present.
Here's a screenshot of the error if this helps at all - I can also grab packet captures, too, if needed.
Did you try what's mentioned in this thread? https://forums.developer.apple.com/forums/thread/757824
It seems there's a new setting in the Privacy panel and you need to enable it for the app?
I have, and it's been enabled for some time (though I can't determine exactly when I toggled it).
Again, the only issue only exists with Joplin & WebDAV; other WebDAV clients are not affected. I'm happy to try other options if any exist.
Ok, interesting thing here - I added an entry in my reverse proxy that points to
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.
This issue unfortunately still exists even after the latest MacOS 15.1 upgrade.
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.