I’m a little unsure of the exact problem here, but:
I’ve been running /e/os for at least a couple of years now, and originally synced it to my self-hosted Nextcloud instance, using the /e/ account option. I can no longer remember exactly what URL etc I used to do this at the time, but it can’t have been too complicated. Otherwise today I would have found the forum topic that answered my question back then.
Since a couple of OS updates (< 6 months) I have been unable to access the Sync details (ie the Dav5x fork) to adjust which calendars are visible etc.
Due to some changes I needed to access these Sync details, so removed and attempted to re-sync the Nextcloud account.
Every attempt returns with failed credentials: ‘Please check username and password.’ Checking multiple times, there is no way the username and password are incorrect.
Specific URL https://mydomainname.tld/nextcloud
Has something changed in the Account Manager?
Am I using the correct method to Sync calendars, contacts and tasks?
Is the URL form correct?
Spent an hour trawling these forums and can’t find anything close to this.
I have no issues to sync to an v20. It’s on its own domain, no subpath (as /nextcloud), so all I do is enter the domain and let /.well-known requests do its schpiel in discovering the carddav / caldav endpoints, that is /remote.php/dav. Works only with valid auth though.
No, 2FA and password are all fine - I can connect to the server without a problem on other devices and clients.
It is particularly /e/ Account Manager that is giving me problems.
As I have mine mounted on subpath /nextcloud:
Does the URL require any extra addressing beyond ‘https:// mydomainname.tld/nextcloud’ ?
For ampache or caldav clients it needs a longer subpath (…/music/ampache or whatever, I forget exactly)
it enters the .well-known discovery if the endpoint is not a dav endpoint, so it looks for one.
So you can give it the /remote.php/dav endpoint directly (appended to your subpath), checkUserGivenURL() will derive resources and skips the well-known mechanism.
I presume your nginx/apache/xyz config handles that path correctly, it will hand you back xml if you request it. You could also make the .well-known thing work either on main domain or on your subpath
(hosting on subdomain has some origin-domain benefits)
Hey thanks for the detailed reply!
This explains why some clients need only the root sub-path and others need the full resource address. That had been bugging me, it’s good to know.
I had been considering mounting the server on a sub-domain but couldn’t see enough benefit for the extra work - given how easy mounting on sub-path is. That may change.
I have installed DavX5 as a workaround for now, but this should give me enough to get the native Account Manager back in order.
Marking solved.