Nextcloud calendar sync with macOS

Support
, ,
#1

NethServer Version: 7.5
Module: Nextcloud 14.0.1

I’m noting some strange behavior with the Nextcloud calendar on my Neth 7.5 installation. I also have SoGo and WebTop installed on this server, though I’m not entirely sure why that should matter. I’m trying to set up calendar sync with Thunderbird Lightning, my iPhone and iPad, and the macOS calendar. Following the instructions in the Nextcloud User Manual (which doesn’t seem to have been updated for Nextcloud 14 yet), I’m logging into my Nextcloud installation, going to my calendar, clicking on Settings and Import, and copying the iOS/macOS CalDAV address. It looks like this:

https://www.mydomain.org/nextcloud/remote.php/dav/principals/users/9ea222d8-a9c4-1037-923c-01a044b2ff54/

When I use that address on my iPhone and my iPad, I’m able to log in with user (rather than user@domain) with my password, and the calendar syncs–I see the same events on both devices, my Linux box using Thunderbird/Lightning, and the Nextcloud web UI. However, when I use that same address to add a CalDAV account on my Mac, authentication fails unless I use user@domain. When I use user@domain, I’m able to log in, but I don’t see events on my calendar that I see everywhere else. When I expand my calendars list, it appears that I’m using the WebTop calendar instead:
image
…and if I create an event on that calendar and then log into WebTop, that event appears there as well.

So what’s up? I’d understand somewhat if Nextcloud were using a generic path (e.g., /.well-known/something), but it isn’t–the CalDAV URL is explicitly a /nextcloud/blah URL. How is WebTop getting involved here, and why is it only happening on the macOS calendar?

#2

Cannot answer your question but from experience in a complete different setup I think you are on the right track (e.g. /.well-known/caldav and /.well-known/carddav) . In my case, using Emclient and another (sabre based) dav service, explicitly disabling automatic configuration was needed, even if you opted setting the dav connections up manual. Some how the emclient had a preference to search for the dav-services at ^/.well-known/…
(IIRC Thunderbird’s cardbook plugin had the same behavior.)

Note all 3 (SOGo / Webtop5-webdac / Nextcloud) offer redirects from /.well-known/…to their services and a client with automated configuration connects to the first it “finds”.

Back then i had 3 solutions:

  • explicitly configure your client to use a URL to the dav-service
  • remove the redirects /.well-known form the apache configuration for dav-services with less preference
  • move dav-services to virtual hosts (although the latter may need to be done manual for webtop5-webdav)
#3

CORRECTION:

Nethserver-nextcloud does not have a redirect (yet)…

#4

…and the obvious solution would seem to be to remove WebTop. I installed it so my users would have options, but if it’s going to cause problems it might be better to remove it. So off to the software center I go to remove it–and it seems that it wants to remove a lot of other things I don’t want to remove:

Why does removing WebTop result in removing every other webmail system? And how can I remove the one without removing the others?

#5

Yesterday @alep faced a similar issue with this PR: https://github.com/NethServer/nethserver-nextcloud/pull/44

The problem is that you can’t have multiple DAV servers installed on the same virtualhosts which are using well-known CalDAV/CardDAV urls.

More info on well-known urls:

Currently, NS doesn’t have a mechanism to say something like “this software is my default DAV server provider”. Each application (WebTop, NextCloud and SOGo) must avoid to override the current configuration and break configured clients.

Maybe we can implement some sort of DAV handler where a software can register, then the user must choose what is its own DAV provider. But for a user is really hard to configure such technical thing.
The real fix, is to install only one CalDAV/CardDAV provider: choose your groupware an stick with it :slight_smile:

Because you’re removing a yum group.

Take a look at:

Workaround:

yum remove nethserver-webtop5
1 Like
#6

It’s unfortunate that CalDAV/CardDAV don’t operate like IMAP–the server software is installed and running, and each client (WebTop, SoGo, iOS Calendar, Thunderbird, etc.) connects to that server to do its thing. With IMAP, of course, you see the same mailboxes no matter which client you’re using–but the calendars are tied to a specific web app, and the others can’t see them.

I suspected the problem might be something like this, but Nextcloud doesn’t use a /.well-known URL, as you see above–apparently there are redirects going on behind the scenes.

So one fix, as you note, is to just install one and stick with it. Surely another would be to put each of them on a different virtual host? Put webtop on webtop.example.com and sogo on sogo.example.com (and/or Nextcloud on cloud.example.com)? As long as no two of them are on the same virtual host, there shouldn’t be a conflict, right?

That is very broken behavoir.

…which still leaves all the software itself floating around.

#7

Right, as long as you keep them in separate virtual hosts, no problem should arise.

1 Like
#8

…which looks like it’s going to be harder than I expected–from what I can see in the Nethserver WebTop docs, there’s no way to put it in its own virtual host. Or am I missing something?

#9

You’re right.
Maybe we can implement it, still we can’t break existing installations. So a specific virtualhost should be an option and not the default.

#10

Given the conflicts in *DAV implementations, maybe it should be the default for new installations. But yes, existing installations should still work–which is why I can’t easily change Nextcloud to be on its own vhost.

Allow dedicated virtual host for webtop