DietPi-Software | Nextcloud: Clients can't find CalDav/CardDav services.

Created on 5 Sep 2018 · 14Comments · Source: MichaIng/DietPi

DietPi version | 6.14
Distro version | Stretch
SBC device | Odroid HC2 or (EG: RPi3)
Power supply used | Official Power Supply
SDcard used | ( SanDisk ultra)

Additional Information (if applicable):

Software title | Nextcloud
Was the software title installed freshly or updated/migrated? Freshly installed
Can this issue be replicated on a fresh installation of DietPi? yes
dietpi-bugreport a2778078-b465-4286-8a6b-76ecddbc78b1

Steps to reproduce:

... Install next cloud
... Try to use a CalDav/CardDav client to connect. In this case specifically DavDroid

Expected behaviour:

CalDav/CardDav clients should connect without further configuration from an end-user

Actual behaviour:

Nextcloud CalDav/CardDav services aren't seen by CalDav/CardDav clients

Extra details:

debug.txt

Feature Request Solution available

Source

LexiconCode

All 14 comments

@LexiconCode

Checking user-given URL: https://CensoredURL/nextcloud

As we do not place any .well-known dirs into the webroot (or into nextcloud directory), or redirect those to the final Cal/Card/WebDAV URLs, you need to add the full URL.

Go to Nextcloud web UI, navigate to calendar and contacts app respectively, open settings at the bottom left. There you can copy the Cal/CardDAV URL. In my case e.g. its:

DAVdroid btw. accesses Card- and CalDAV, not WebDAV, which is for data transfer, e.g. used by the Nextcloud clients. Can you configure Nextcloud desktop/mobile clients without issues?

If with the above method sync works as expected, we can turn the issue into a feature request to allow adding URLs /nextcloud only, e.g. via .well-known redirects. Have to check how this can be done best without interfering other web services.

MichaIng on 6 Sep 2018

@LexiconCode
Just another quick question, which webserver do you use?

In case of nginx e.g. the following entries inside location ^~ /nextcloud { statement should do it, without creaking any other parallel Cal/CardDAV servers: https://docs.nextcloud.com/server/14/admin_manual/installation/nginx.html#nextcloud-in-a-subdir-of-nginx

    location = /nextcloud/.well-known/carddav {
      return 301 $scheme://$host/nextcloud/remote.php/dav;
    }
    location = /nextcloud/.well-known/caldav {
      return 301 $scheme://$host/nextcloud/remote.php/dav;
    }

There are similar possibilities for other webservers.

MichaIng on 7 Sep 2018

I'm using the Apache Web server. Normal clients desktop/android nextcloud clients connect as expected.

I believe the configuration for enabling Apache.

Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav

I'll get back to you today but with the results of testing.

Apparently I need to edit .htaccess but where is it stored?

LexiconCode on 7 Sep 2018

👍1

@LexiconCode
I believe it's

Redirect 301 /nextcloud/.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /nextcloud/.well-known/caldav /nextcloud/remote.php/dav

then, if your.domain.org/nextcloud shall work. Yours should further allow DAVdroid to find the endpoints by just entering only your.domain.org 🤔.

MichaIng on 8 Sep 2018

@MichaIng
Which file do I edit and were?
.htaccess? nextcloud.conf?

LexiconCode on 8 Sep 2018

@LexiconCode
Not sure if it works inside .htaccess, there are some limitations and more importantly it gets overwritten by Nextcloud on update and occ maintenance commands.

So better add it to /etc/apache2/sites-available/nextcloud.conf, inside the statement as a first try. Should work, but if Apache service complains syntax error, perhaps is needs to be outside the statement. Effect will be the same anyway.

On Lighttpd:

url.redirect = (
    "^/nextcloud/.well-known/caldav"  => "/nextcloud/remote.php/dav",
    "^/nextcloud/.well-known/carddav" => "/nextcloud/remote.php/dav"
)

Ref: https://github.com/bambocher/docker-baikal/blob/master/lighttpd.conf

🈴 DAVdroid still fails, while manual access to <URL>/nextcloud/.well-known/caldav via browser correctly is redirected to <URL>/nextcloud/remote.php/dav and entering <URL>/nextcloud/remote.php/dav in DAVdroid works as well 🤔. Does DAVdroid not search for .well-known/cal[/card]dav?
🈯️ The following works, outside the /nextcloud location directive:

url.redirect = (
    "^/.well-known/caldav"  => "/nextcloud/remote.php/dav",
    "^/.well-known/carddav" => "/nextcloud/remote.php/dav"
)

Seems that DAVdroid does not search for .well-known inside nextcloud sub dir, but only inside webroot. With the above, regardless if only my.domain.org or my.domain.org/nextcloud is added as base URL, DAVdroid finds the dav endpoints as wanted.

In case of Apache, /var/www/nextcloud/.htaccess already contains the following:

  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]

Is ineffective with DAVdroid for the same reason, it seems.

I tried to test with Thunderbird Lightning. Seems the same there, with /nextcloud inside redirect, a yellow rectangle and error log indicates that caldav could not be connected to. With the above working solution, Lightning does not show the rectangle any more. But instead it disables the calendar completely. Not sure, since v60 Lightning <> Nextcloud cal/carddav sync anyway has some issues. Could fix it with a cookie ignore workaround, but maybe there is more broken.

@LexiconCode
Do you have another Cal/CardDAV client than DAVdroid, to test? Would be great if you could verify that with all clients you use:

cat << _EOF_ >> /etc/apache/sites-available/nextcloud.conf

Redirect 301 /.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav /nextcloud/remote.php/dav
_EOF_

Allows them to connect via your.domain.org/nextcloud and as well your.domain.org

If there is no way to limit it to your.domain.org/nextcloud, we have to decide if we expect ownCloud/Nextcloud users to also use it for Cal/CardDAV and implement the above. Because if another Cal/CardDAV client, e.g. baikal is used, this may break connection. Of course we could do some magic cross checks to decide where to redirect cal/cardDAV requests to, but I am not keen to implement such things, based on guesses how users might want to use their system. Then better leave it as it is and suggest users to copy the full dav endpoint path into their clients 🤔.

MichaIng on 9 Sep 2018

👍1

I will work on finding and testing some Cal/CardDAV clients tomorrow. DAVdroid works.

LexiconCode on 11 Sep 2018

❤1

I have a good idea how we can handle it and by this implement redirection into other DAV servers as well:

We place redirection into own config files dietpi-dav_redirect.conf or something.
Baikal (and in case other explizite Cal/CardDAV servers we offer) will overwrite this file, if existent.
ownCloud/Nextcloud (and other software that optionally can be used as Cal/CardDAV server), will only create it, if the file does not yet exist.
On software uninstall, the config is only removed, if created by/pointing to the related Cal/CardDAV server.

MichaIng on 13 Sep 2018

👍1

Everything checks it seems to work in a few clients I was able to find for Windows!

LexiconCode on 13 Sep 2018

👍1

@LexiconCode
Great, will finish the PR about this tomorrow. The other new network issues prevented from finish this today 😅.

MichaIng on 13 Sep 2018

@LexiconCode
I added the redirects to the PR: https://github.com/Fourdee/DietPi/pull/2065

For Apache, I followed the method that is used within their .htaccess, using mod_rewrite. Not sure about the difference/advantage to the Redirect directive of mod_alias: https://httpd.apache.org/docs/2.2/mod/mod_alias.html#Redirect

The latter seems to be the easier more direct solution, but seems to have disadvantages, why mod_rewrite exists(?).
I had the same question with HTTPS redirects on my system. Some guides use Redirect directive, some mod_rewrite. Certbot default configuration uses the latter as well, so somehow this seems to be beneficial. But I will investigate by times when to use which method.

€: Finally moved everything to use redirection (301 status reply) instead of rewrite, as this is faster and cleaner and recommended by all official docs.

MichaIng on 14 Sep 2018

👍1

PR finished, finally 😅: https://github.com/Fourdee/DietPi/pull/2065

Testing on all webservers and distro versions passed here.

MichaIng on 23 Sep 2018

🎉1

We implemented this just the right time. Since Nextcloud v14.0.2 there appear admin panel warnings, if .well-known/caldav|carddav is not found 😄:
dav_redirect