I categorise software into “Just works”, “Only just works” and “Just doesn’t work”. For years I’ve had a Pi server on my local network, Caldav (eventually) linking my calendar to Seamoney calendar on desktop and, via Davx, to an Android calendar. Until the disk died while trying to sync to a second laptop whilst my main laptop is away for a hinge repair. I’ve eventually got up and running with a new server but today has been totally eaten by trying to get calendar syncing working. It’s possible that my main laptop had a Seamonkey extension installed to get that working so I’ll leave aside the fact that that’s not working until I can get it tested on the old one.
But caldav against Android. Originally I just had Davx and the calendar. Going through the setup - multiple failures until I realised that the IP address needed to be in trusted domains (local network, not address resolution against server name). Chrome needs to have have javascript enabled. Eventually I got as far as failures against invalid token and/or token expired. After clearing storage & cache for Davx I finally got logged in with just the address. No sync. No reason. Try again giving the n.n.n.n/remote.php/dav form of the address. That failed. Try installing the Nextcloud app. More data and cache clearing. The password entry on Chrome, BTW is a nightmare as it seems to display or hide the keyboard at random. Eventually got to the point where “you can close this window”. How? is it an upward swipe with the NC app still there behind it? Nope. No NC app. Start again. More invalid tokens, more clearing. Start yet again. This time let’s try back instead - token, which surely had just been granted, has expired.
So far this has deteriorated from “Just works” to apparently “just doesn’t work”.
Now I accept that somehow somehow it does work. But there’s an awful lot which is undocumented to getting it to work.
Can I suggest that whoever writes the documentation and the code (same person?) gets as USER to test the installation, adds the missing steps, removes paper cuts from the code, whatever, rinse and repeat so that an inexperienced user can pick up an Android phone, follow the documentation and get Caldav working first time every time. Because that’s what Just Works means.
I categorise forum posts in a similiar way:
- Well-structured and perfectly readable
- Readable, but confusing
- Barely readable
- Unreadable
Yours lands somewhere between 2 and 3.
Sorry, couldn’t resist. 
With Nextcloud?
Many calendar/contact apps rely on service discovery, then you just need the hostname/ip address:
Everybody can work on the documentation. If you see a problematic/outdated part, there is link on the top, edit in github, and you can update it.
For all the possible clients, it is hard to redo all the steps and keep everything updated, and this is where the community feedback helps a lot.
Maybe it’s just my ADHD, but I honestly have a hard time deciphering your post. I don’t want to invest too much effort until it’s clear whether this is a genuine attempt to solve something, or just a rant.
That said (and yes, I know this is a bit broad):
Self-hosting requires a certain DIY mindset, regardless of your specific issue and despite what all the Homelab and self-hosting YouTubers might suggest.
If you’re coming in with that mindset, please start a new thread, describe your problem in detail (ideally using the support template), and I’ll be happy to help as best I can.
Yes, working with Nextcloud, and the n.n.n.n/remote.php/dav is one of the many things that doesn’t work. FWIW I tried again, got the login working from te Nextcloud app but simply do not see any way to get from the announcement of success and the page can now be closed to anything that has a Settings/More option to tap.
In fact, looking at documentation it says firstly to install DAVx and then "In the Nextcloud mobile, go to Settings/More"e, tap on “Sync calendars & contacts” and only after that will DAVx open the login. In fact the NC app comes up without and Settings/More, just a login prompt.
It has been a long, tiring and fruitless day. Sorry.
BTW, background in IT - from Fortran in punched card days through Unix, RDBMS application development and administration and OO application development on Delphi and more - Linux user in retirement for the best part of 2 decades.
Sure, but we’re talking about web applications and PHP-based frontends here, they play by their own rules.
We could start a general debate now, but the fact is: I (with no background in development) and many other users have been using DAVx5 for years, and it’s one of the things that causes the least trouble of all components. It just runs in the background. On my current phone, it’s been working for three years straight without ever needing any attention. So I honestly couldn’t even give you a list of what might go wrong with it. Besides, guessing usually isn’t the most efficient approach anyway.
That said, if you’d be willing to open a new thread and describe your setup and what exactly isn’t working, ideally while using the support template, I’m confident we can either solve the issue or at least point you in the right direction.
Just to reiterate: Nextcloud may not be the easiest thing to self-host, and the documentation does have some rough edges. But DAVx5 is not usually the part that causes issues, assuming the Nextcloud instance itself is properly set up. I’m in the forum nearly every day, and if this were a common issue, I’d definitely had noticed.
If you pass after user authentication, the server logfile are interesting. What resources is the client trying to connect to, what does the server respond?
You can try other calDAV clients on desktop (e.g. thunderbird), and you can see if that works.
It had been working on my phone for several years under my old server. The problem was with the new server.
Some progress. After a bit more searching I came across a blog post from last year. Somebody else had had an equally bad day but eventually discovered a couple of lines in .htaccess:
RewriteRule ^.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^.well-known/caldav /remote.php/dav/ [R=301,L]
which should have an extra / in them:
RewriteRule ^/.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^/.well-known/caldav /remote.php/dav/ [R=301,L]
Applying that correction resulted in test events entered on the NC calendar appearing in a shred calendar in Seamonkey. PHP-based frontend certainly play by their own rules - you gotta get the rules right first 
This was as downloaded from the link in the online manual installation instructions. I wonder if the Docker images are different but in this version I think it has to be counted as a bug.
I think it possible that the state token might be a consequence of attempting to log in from the mobile while the desktop client is also in use but it might just be a consequence that I completed a login on the mobile after stopping the desktop client. Unfortunately There’s no further progress getting things to work there. The whole business has set my back so far with other things that I’ll look into a bug report for the .htaccess file and leave it there for a while.
My whole experience with the install, as with last time, leads me to think that the online manual install instructions were written by somebody with a great deal of experience of installing the software but done from memory so that some steps were taken for granted. It’s the sort of thing we all do from time to time when documenting stuff. When I get chance I’ll work through my notes from this time, build another server from them, work out what I’ve missed in my notes, update them and them find some way of offering them as a how-to.
Depends a bit if you use nextcloud in a subfolder, it was also explained in the linked documentation. And for nginx it might be different as well, but you never told us which configuration you used.
But such a problem with not functioning redirects, that should be visible in the logs as well (again, which you did not share).
Using the ip address and not a domain/subdomain, I don’t know for these redirects if that can be used just with ip addresses as well, or if it will automatically use (or try to use) SSL connections. Having certificates for IP addresses (I think now it is possible with public ones) but you often go back to self-signed ones, and depending on the system that can be difficult as well.
If you expect the community to help you, we came up with a support template shown by default, because now you expect us to know and imagine, what you might have broken between your old setup (we don’t know the environment, configuration, Nextcloud version) and you new setup (with as little information as well).
Well, at least you keep us updated about your progress.
With many caldav calendar clients, /dav is not enough. If I remember well, if you open de calendar in Nextcloud, on the left you see Settings. In there you can copy a link to your caldav calendar. Something like /remote.php/dav/calendar/username/
Have you tried that?
And I agree with others above that your post is hard too read.
Funny. My resume is 99% indentical. I usually start a help post with: I need some guidance. I know I am missing something.
Situation so far: I happen to have a hosted NC as well as the rebuilt on on a Pi. On that I’ve got TBird to sync. Without the Android side working so that NC can sync between laptop and mobile, however, it’s not really useful.
On Android the results on either server are either
- Mismatched access token (mostly)
- With just the server address, nothing
- With the connection string either a 401 or a 404 depending on how many parts of the connection string I provide. The connection strings for the two servers are quite different. The local one, installed from the command line is is /remote.php etc, the other possibly on Docker? is /apps etc.
I have now resigned myself to the fact that what worked well until my old server died is not now going to work in the future. The new NC server is now syncing files which is the main thing. The loss of the old one, building the new and and trying to get the calendar working has set me back about a week. I cannot afford more time to spend on it. In those circumstances the fact that during the attempts it also wiped the calendar contents on the mobile makes no difference.
As I said subsequently, sorry if the post was hard to read. It was the result of an exceptionally trying day which I can assure you was even harder to experience.
Some progress.
Working through the instructions at the trouble shooting page:
If I amend the caldav and carddav rewrite rules in .htaccess to allow for the nextcloud root being at www/nextcloud the calendar in Seamonkey works using the configuration used the original server (the server IP, name, user ID and password not been changed).
If, however, I add the rewrites for webfinger and nodeinfo recommended on that page the overview reports that webfinger cannot be resolved. If I comment them out the overview does not complain about webfinger but reports that caldav cannot be resolved despite this not having been altered in .htaccess and still working with Seamonkey. If I comment out the webfinger rewrite but leave the nodeinfo line it reports that nodeinfo cannot be resolved.
Here is the relevant section of .htaccess:
<IfModule mod_rewrite.c>
# first 4 lines as found on initial install
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} DavClnt
RewriteRule ^$ /remote.php/webdav/ [L,R=302]
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
# Next 2 lines modified to allow for root at www/nextcloud. Known to work
RewriteRule ^\.well-known/carddav /nextcloud/remote.php/dav [R=301,L]
RewriteRule ^\.well-known/caldav /nextcloud/remote.php/dav [R=301,L]
# Next 2 lines added from troubleshooting page. Still provoke fail message for webfinger
# If they are active the overview reports that webfinger is in error. If they are
# commented out no error is raised for them but an error is raised for caldav which nevertheless
# continues to work with client
RewriteRule ^\.well-known/webfinger /nextcloud/index.php/.well-known/webfinger [R=301,L]
RewriteRule ^\.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo [R=301,L]
# As found
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
RewriteRule ^ocm-provider/?$ index.php [QSA,L]
RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
mod-rewrite is installed and enabled and AllowOverride All is set.
AFAICS it appears that index.php is not providing the webfinger and nodeinfo services when the rewrite directs them to it.
If I attempt to connect Thunderbird it doesn’t even offer a login dialog so it looks as if the lack of working webfinger and/or nodeinfo is responsible for this.
This seems to be a red herring. A hosted service provides the same responses - not implemented messages - as the local server with the webfinger and nodeinfo lines commented out but T’bird connects to the hosted server but not to the local one.
There must be some other handshake that the local server is not offering.
Problem finally solved. The rewritesPreformatted text for .htaccess suggested at the service discovery page should have had nextcloud removed from the path.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.