Server: Server not properly set up to solve well-known/caldav and well-known/carddav after upgrade from 14.0.1 to 14.0.3

[Lorenzoform]

After upgrade from 14.0.1 to 14.0.3 I see the following advise:

Your web server is not properly set up to resolve “/.well-known/caldav”.
Your web server is not properly set up to resolve “/.well-known/carddav”.

I see the configuration of well.known/caldav and carddav inside /var/www/html/nextcloud/.htaccess

I tried to change the configuration inserting the complete https of my webserver but without solving.

My configuration centos/postgresql

[nextcloud-bot]

GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/11654 (Some accounts can't log in after upgrade to 14.0.1), https://github.com/nextcloud/server/issues/11825 (wrong warnings after upgrade to 14.0.2 (and 14.0.3)), https://github.com/nextcloud/server/issues/10920 (After upgrade from 14.0.0 beta 4 to 14.0.0 RC 1: Internal server errors), https://github.com/nextcloud/server/issues/11827 (Update from 14.0.1 to 14.0.3 fails), and https://github.com/nextcloud/server/pull/11784 (14.0.3).

[warthog9]

Issue looks like it's related to https://github.com/nextcloud/server/blob/5daa4f27e1a4840a1a722729ca5ebafb6e749a43/core/js/setupchecks.js#L57

Specifically the 301 is set to return "/remote.php/dav" for cardav / caldav, except the function doesn't seem to tack on the base url for the server in the check so it tries to query "/remote.php/dav" instead of "http(s)://domain/remote.php/dav"

tacking the domain onto the 301 clear the error, even though the error is erroneous and the check needs to be updated to include the base url. Quick reading it's likely:

https://github.com/nextcloud/server/blob/5daa4f27e1a4840a1a722729ca5ebafb6e749a43/core/js/setupchecks.js#L78 needing to be:
url: <base domain>/url,
instead of
url: url, like it is now. I'm not familiar enough with this setup to double check how that should get cleared though or I'd make a patch

[warthog9]

Noting this is what I had, and how it was resolved for me:
Original:

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

What fixed it:

Redirect 301 /.well-known/carddav https://example.org/nextcloud/remote.php/dav
Redirect 301 /.well-known/caldav  https://example.org/nextcloud/remote.php/dav
Redirect 301 /.well-known/webdav  https://example.org/nextcloud/remote.php/dav

Noting this is in the Apache nextcloud.conf file NOT the .htaccess

[Lorenzoform]

Hi,

in the /etc/httpd/conf.d/nextcloud.conf I have only that not Redirect 301...:

Alias /nextcloud "/var/www/html/nextcloud/"

Options +FollowSymlinks
AllowOverride All

Dav off

SetEnv HOME /var/www/html/nextcloud
SetEnv HTTP_HOME /var/www/html/nextcloud

[cvandesande]

Also seen this in 14.0.2 and 14.0.3 even though my /.well-known config hasn't changed for years from the recommended one.
`

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

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

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

location /.well-known/acme-challenge { }

`

[enoch85]

@warthog9 Hey, maybe you can send a PR to the Nextcloud Server repo here on Github with your fix?

[MorrisJobke]

@warthog9 Hey, maybe you can send a PR to the Nextcloud Server repo here on Github with your fix?

That doesn't make sense, because it includes the hardcoded URL.

Also seen this in 14.0.2 and 14.0.3 even though my /.well-known config hasn't changed for years from the recommended one.

Usually fixed in 14.0.2: https://github.com/nextcloud/server/pull/11738/files

Also: we fixed the actual check because it never worked before.

See also: https://github.com/nextcloud/server/issues/11787#issuecomment-429239543

[cvandesande]

@MorrisJobke
I'm not sure I understand. My server is in the root directory (no sub-folder), and I have tested a couple of iOS devices that use the /.well-known url. They wouldn't work if it wasn't configured correctly. The configuration I use is posted just above is straight from the nginx example, it's working fine but get the setup warnings

[MorrisJobke]

I'm not sure I understand. My server is in the root directory (no sub-folder), and I have tested a couple of iOS devices that use the /.well-known url. They wouldn't work if it wasn't configured correctly.

What do you mean with this. The point with this warning is that the initial auto discovery does not work. If the device is already set up using the full URL there is no problem.

What does curl -i https://DOMAIN/.well-known/caldav return?

[cvandesande]

I ended up wiping an old iPad for unrelated reasons and needed to setup caldav/carddav again.

Here's the curl output:

$ curl -i https://nextcloud.domain.tld/.well-known/caldav
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 30 Oct 2018 14:11:26 GMT
Content-Type: text/html
Content-Length: 178
Location: http://nextcloud.domain.tld/remote.php/dav
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Robots-Tag: none
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=31536000

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

[cvandesande]

@MorrisJobke Thank you for the curl command, I think I understand now.

There's an HAProxy in front of my Nextcloud, and it's doing SSL-offloading.
In this case, using $scheme is sending http (not https). When I replace $scheme with 'https' the checks pass.

So a fix for me is

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

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

[enoch85]

@cvandesande Thanks! I think this is the solution for me as well. Can not test right now though.

Fyi @josh4trunks

[MorrisJobke]

See also https://github.com/nextcloud/documentation/issues/899 for more details about this

[enoch85]

Confirmed, working. Thanks @cvandesande!

[rcdailey]

Using the nextcloud:apache docker container, I ran into this issue. @cvandesande's NGINX configuration solved the issue for me.

[pauvos]

@cvandesande's solution for traefik users:

traefik.frontend.redirect.permanent: 'true'
traefik.frontend.redirect.regex: https://(.*)/.well-known/(card|cal)dav
traefik.frontend.redirect.replacement: https://$$1/remote.php/dav/

[jcklpe]

I'm having similar issues. I created a thread on the help forums here: https://help.nextcloud.com/t/our-web-server-is-not-properly-set-up-to-resolve-well-known-caldav/56962/2

I've tried changing the nginx conf file but I'm still getting the same basic errors and I don't know why

[jcklpe]

Also neither http or https work for me. I'm getting the same errors either way.

[rubo77]

no need for $sheme and $host, I just added this to my config before the location / { block:

  location = /.well-known/carddav {
      return 301 /remote.php/dav;
  }
  location = /.well-known/caldav {
      return 301 /remote.php/dav;
  }

[antoneliasson]

For those running Nextcloud behind a reverse proxy (e.g. for TLS offloading), Nextcloud's documentation recommends doing the redirects in the proxy: https://docs.nextcloud.com/server/16/admin_manual/configuration_server/reverse_proxy_configuration.html#service-discovery

Example for HAProxy (can be placed either in the backend or the frontend):

acl dav path /.well-known/carddav /.well-known/caldav
redirect location /remote.php/dav/ if dav

[kesselb]

Either I've mis-config'd, or it's still an issue -- at least for this usecase.

As posted above https://github.com/nextcloud/server/issues/11787#issuecomment-429239543 and with more details http://sabre.io/dav/service-discovery/

tl;dr You're usecase is not supported. The warning will not go away. If you want autodiscover then setup the redirects for example:443/.well-known/caldav (+ the same for carddav) to your nextcloud url including the port, protocol and subfolder.

[kesselb]

@pgnd Have you read https://github.com/nextcloud/server/issues/11787#issuecomment-429239543 and http://sabre.io/dav/service-discovery/?

Anyway: Your web server is not properly set up to resolve "/.well-known/caldav". this warning (not error) tells you that service discovery does not work. CardDAV and CalDAV will work but service discovery not. https://github.com/nextcloud/server/issues/11787#issuecomment-429239543 will tell you what service discovery is and http://sabre.io/dav/service-discovery/ in more depth.

Example: Cloud is running at example.com/cloud/. CalDav-Url is something like: example.com/cloud/remote.php/dav. This is probably inconvenient (much typing involved). More user friendly is to only enter example.com and the device / caldav client will figure out the right dav endpoint. That's what service discovery is about. Setup a redirect from example.com/.well-known/caldav to https://example.com/cloud/remote.php/dav.

According to the sabre most clients will check:

• https://example.com/.well-known/caldav
• https://example.com:8443/.well-known/caldav (apple)
• http://example.com/.well-known/caldav
• http://example.com:8080/.well-known/caldav (apple)

to be clear abt which usecase

https://proxy.example.com:11111/cloud/ no client will query https://proxy.example.com:11111/.well-known/caldav. That usecase is not supported hence the warning. CalDAV and CardDAV with the right url will still work. You have to enter the complete address.

A general note: This is the issue tracker of Nextcloud, please do NOT use this to get answers to your questions or get help for fixing your installation. This is a place to report bugs to developers, after your server has been debugged. You can find help debugging your system on our home user forums: https://help.nextcloud.com or, if you use Nextcloud in a large organization, ask our engineers on https://portal.nextcloud.com. See also https://nextcloud.com/support for support options.

[AntoineMazuyer]

traefik.frontend.redirect.permanent: 'true'

@pauvos I am trying to do that with traefik v2.0, by any chance, do you have the equivalent config lines for this version ?

[pauvos]

@AntoineMazuyer , no, I use the nextcloud:17.x.x-apache docker image behind traefik 2 and they seem to have fixed it inside the apache conf:

$ curl -I https://nextcloud.my.domain/.well-known/caldav
HTTP/2 301 
location: https://nextcloud.my.domain/remote.php/dav/
server: Apache/2.4.38 (Debian)
[...]

The requests goes through traefik and gets redirected by nextcloud's apache correctly.

With traefik 2 I think you have to use routers (https://docs.traefik.io/routing/routers/#rule) to match host and the .well-kown-path, combined with a RedirectRegex middleware (https://docs.traefik.io/middlewares/redirectregex/, https://docs.traefik.io/middlewares/replacepathregex/) or something like that.

[AntoineMazuyer]

hmmm I still needed to add the redirection manually with a similar configuration. I used that:

         - "traefik.http.middlewares.nextcloud-rep.redirectregex.regex=https://(.*)/.well-known/(card|cal)dav"
         - "traefik.http.middlewares.nextcloud-rep.redirectregex.replacement=https://$$1/remote.php/dav/"
         - "traefik.http.middlewares.nextcloud-rep.redirectregex.permanent=true"
         - "traefik.http.middlewares.nextcloud-header.headers.stsIncludeSubdomains=true"
         - "traefik.http.middlewares.nextcloud-header.headers.stsSeconds=15552000"
         - "traefik.http.routers.nextcloud.middlewares=nextcloud-rep,nextcloud-header"

[LifeSteala]

@AntoineMazuyer - thank you. I tried your solution but I'm still getting the messages:

Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the documentation.
Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the documentation.

Was there anything else you did?

[joergmschulz]

did you also think of including the .well-known/webfinger ?

[DesktopMasters]

I am using nginx with a reverse proxy. This fixed it for me.
So thank you!!!
Now, I feel like after all this time the fix should be built in (somewhere).