.well-known warning with external CalDAV provider after upgrade to NC 29

Nextcloud version (eg, 20.0.5): 29.0.0 / 29.0.1
Operating system and version (eg, Ubuntu 20.04): Debian 12
Apache or nginx version (eg, Apache 2.4.25): 2.4.59
PHP version (eg, 7.4): 8.2.19 fpm

Since upgrading NC 28 to 29 Administration/Overview/Security & setup warnings shows the well-known (sic) Your web server is not properly set up to resolve '.well-known' URLs, failed on: '/.well-known/caldav' message.

Context: Since many years my webserver is configured to serve CalDAV and CardDAV from SOGo running on an internal server instead of NC’s built-in providers. I. e. apache is configured like that:

    ProxyPassMatch ^/.well-known/caldav(.*) http://internal.machine/SOGo/dav$1
    ProxyPassMatch ^/.well-known/carddav(.*) http://internal.machine/SOGo/dav$1

Up to NC 28 on loading Administration/Overview the browser would ask me for the credentials to access the CalDAV resource (like ist does when I type https://myserver/.well-known/caldav in the URL bar) and Security & setup warnings would show no warnings WRT .well-known URLs.
Since the upgrade to NC 29 I am not asked for credentials anymore but rather warned about the .well-kown misconfiguration instead.

I see this in apache’s access log:

myserver:80 $IPADDR - - [26/May/2024:17:51:47 +0200] "PROPFIND /.well-known/caldav HTTP/1.1" 401 236 "-" "Nextcloud Server Crawler"
myserver:80 $IPADDR - - [26/May/2024:17:51:47 +0200] "PROPFIND /nextcloud//.well-known/caldav HTTP/1.1" 302 547 "-" "Nextcloud Server Crawler"

So, the crawler is answered with authentication needed.
Apache’s error log at the same time shows:

[Sun May 26 17:51:47.555913 2024] [proxy_fcgi:error] [pid ...] [client ...] AH01071: Got error 'Primary script unknown'
[Sun May 26 17:51:47.646218 2024] [proxy_fcgi:error] [pid ...] [client ...] AH01071: Got error 'Primary script unknown'

I can’t tell weather or not the latter did happen with NC 28 or earlier too.

How do I get rid of the bogus warning?

I don’t have an answer…but, I just fresh installed NC AIO 29 and I’m getting the same error message. I’m also only getting the error for CALDAV, I do not get the error for CARDDAV.

If I type the “https://my.server.tld/.well-known/[cal|card]dav” url into a browser, the browser redirects to “https://my.server.tld/remote.php/dav” and I get the following text in the browser:

“This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.”

I am running behind a reverse proxy (caddy with cloudflare tls / dns) and do have:
redir /.well-known/carddav /remote.php/dav 301
redir /.well-known/caldav /remote.php/dav 301

in my Caddyfile.

I have no obvious symptoms that would indicate something is actually not working. Without knowing exactly what caldav errors would cause, I can create calendar events within the calendar app.

Sometimes it might help to add a “/” at the end of the URL

redir /.well-known/caldav /remote.php/dav/ 301

I am running behind a reverse proxy (caddy with cloudflare tls / dns) and do have:
redir /.well-known/carddav /remote.php/dav 301
redir /.well-known/caldav /remote.php/dav 301

To me it seems that you’re problem is with NC’s default CalDAV/CardDAV providers. That’s not what I have trouble with.

I’m using an external provider (SOGo) for CalDAV/CardDAV. And up until NC 28 on loading Administration/Overview I was asked for the credentials to access this external provider. That’s no the case with NC 29 anymore.

Thanks. That did it.

Yes, fair enough. As noted above, my issue was simple with the trailing “/” on the redirect.

I have the same problem. I always just update the version number in docker-compose.yml and to a restart. This was never a problem for carddav and caldav.

  • Not when I upgraded to Nextcloud 26
  • Not when I upgraded to Nextcloud 27
  • Not when I upgraded to Nextcloud 28

But Nextcloud 29 for the first time shows me this warning:

  • Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/caldav. For more details see the documentation :arrow_upper_right:.

The documentation is not helpful regarding this new issue, and a search brought me here.

I tried adding a trailing / to the Traefik rewrite rules in docker-compose.yml as per @Mornsgrans' recommendation, but after a restart, the warning does not go away:

    labels:
      - "traefik.http.routers.nextcloud.middlewares=nc-dav"
      - "traefik.http.middlewares.nc-dav.replacepathregex.regex=^/.well-known/(card|cal)dav"
      - "traefik.http.middlewares.nc-dav.replacepathregex.replacement=/remote.php/dav/"

I can manually go to /.well-known/carddav and see the following message:

This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.

Same issue here after Upgrading to 29.0.2: resolving of /.well-known/caldav isn’t configured right.

But I already had the tailing slash added (it was there before the upgrade and is still there after it).

I am using apache these are my entries in the .htaccess file:
Redirect 301 /.well-known/carddav /cloud/remote.php/dav/
Redirect 301 /.well-known/caldav /cloud/remote.php/dav/
Redirect 301 /.well-known/webfinger /cloud/index.php/.well-known/webfinger
Redirect 301 /.well-known/nodeinfo /cloud/index.php/.well-known/nodeinfo

So I still didnt find a solution to solve this issue.

Updated to 29.04 thinking this warning would be fixed, it still persists. My install is in a subfolder.

Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/caldav

My NGINX config:

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

And my site resolves when navigating to the URLs:

mynextcloud.com/.well-known/carddav
mynextcloud.com/.well-known/caldav

To:
mynextcloud.com/subdir/remote.php/dav/
This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.

1 Like

I think what may have changed is that the system check now wants to see an actual 301 redirect rather than just the correct contents.

Both redirecting and rewriting work, insofar as with either one you reach the “This is the WebDAV interface” page, but only the one using the 301 redirect satisfies the test under the Administration/Overview page.

If you’re using traefik, instead of the “replacepathregex” rule as suggested by the documentation, you can use “redirectregex” instead:

 - traefik.http.middlewares.dav-redirectregex.redirectregex.regex=^https://(.*?)/.well-known/ca(l|rd)dav
 - traefik.http.middlewares.dav-redirectregex.redirectregex.replacement=https://$${1}/remote.php/dav/

and it will both work correctly and satisfy the self-check. Don’t forget to update the “middlewares” list too, e.g.:

- traefik.http.routers.ncapp-secure.middlewares=dav-redirectregex,nextcloud-headers,nextcloud-sts