Credential failure connecting self-hosted Nextcloud in Account Manager

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

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.


Device: Fairphone 2
/e/OS: 1.2-(20220728206708)

what’s the version of your self-hosted nextcloud?

did you enable 2fa auth?

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.

Nextcloud is version 23.04

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)

here’s the logic: app/src/main/java/foundation/e/accountmanager/ui/setup/DavResourceFinder.kt · 7fb1f299 · e / os / AccountManager · GitLab

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)

1 Like

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.

Thanks again!