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

🚧 Installation
#1

I have a relatively new/clean manual install of NC 15.0.4 and I am trying to make my way through the security & setup warnings. This post relates to the following two warnings:

  • 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.
  • if I browse to “mynextcloud” I get a functional version of NextCloud (spoiler alert, this is NOT public facing, and is relying on my personal DNS lookup for this).
  • if I browse to “mynextcloud/remote.php/dav/” I get a page saying “This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.”
  • if I browse to “mynextcloud/remote.php/dav/” I get a page saying “This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.”
  • if I browse to “mynextcloud/.well-known/caldav” I get a page saying “The requested URL /.well-known/caldav was not found on this server.”

My suspicion is that the redirect (or lookup for redirect) is not occurring.

Below is part of my “.htaccess” file in apache (this seems to be the relevant portion, if the full file is needed I can provide that).

Blockquote

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} DavClnt
RewriteRule ^$ /remote.php/webdav/ [L,R=302]
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^.well-known/host-meta.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^.well-known/webfinger /public.php?service=webfinger [QSA,L]
RewriteRule ^.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^remote/(.) remote.php [QSA,L]
RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/. - [R=404,L]
RewriteCond %{REQUEST_URI} !^/.well-known/(acme-challenge|pki-validation)/.*
RewriteRule ^(?:.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

I have read through a number of other forum posts on this website but most of them either seem to be related to specific quirks in synology (which I’m not using) or recommend changing the .htaccess file to have a specific redirect that does not seem to translate to my case. As I said above, I have a url that seems to work so I do not think a symlink is the correct approach…but if someone can provide a functional symlink, I’ll take it!

Thank you for your help in this!

1 Like
#2

I am also having a similar problem. Did you ever find a solution for this @coatmaker618 ?

My htaccess contains the same stuff as yours. But I’m on nginx, while you’re on apache. I don’t know if that makes difference but wanted to note that in case it was pertinent to my issue.

I see a lot of threads commenting on this issue in all of them they seem to indicate that redirect information about the web dav etc are supposed to be held in the apache or nginx configuration directly instead of in the .htaccess of nextcloud? But the .htaccess of nextcloud 16 ships with this information in it’s htaccess so there must be something missing?

Here’s a thread I found that seemed to indicate the issue was related to the apache or nginx settings: Caldav and carddav error resolving

#3

@ thedonquixotic I have not found a solution for this issue :frowning: I’ve actually gotten distracted with other problems and haven’t looked at this for some time–but I can refresh my memory when I get a chance over the weekend and what I can make of that forum post!

1 Like
#4

nginx does not support .htaccess-rules. For a good reason: performance
https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/

For nginx the .well-known-redirects need to be setup in the nginx configuration. Have a look here and pay attention whether your nextcloud runs in webroot or in a subdirectory of webroot:
https://docs.nextcloud.com/server/16/admin_manual/installation/nginx.html

1 Like
#5

Thank you, if you can link me that or reply here that would be big help. I’m currently going through all the related threads and trying to find solutions and or at least catalogue them to my current thread Our web server is not properly set up to resolve "/.well-known/caldav"

I also think I might have found my problem at least.

#6

Hey @Bernie_O Sorry I just now saw your reply.

I’ve looked over the nginx configuration you linked and I think I’ve got the necessary well-known/caldav information.

My nextcloud configuration is found /etc/nginx/conf.d/cloud.jackalope.tech and it contains the following information. The information is slightly different in multiple places but mostly it looks the same, and since my nginx was set up via an ansible playbook I’m not honestly sure how much those differences matter or not.

server {
	listen 80 default_server;
	server_name cloud.jackalope.tech;
	#Your DDNS adress, (e.g. from desec.io or no-ip.com)
	location ^~ /.well-known/acme-challenge {
		proxy_pass http://127.0.0.1:81;
	}
	location / {
		return 301 https://$host$request_uri;
	}
}
server {
	listen 443 ssl http2 default_server;
	server_name cloud.jackalope.tech;
	root /var/www/nextcloud/;
	access_log /var/log/nginx/nextcloud.access.log main;
	error_log /var/log/nginx/nextcloud.error.log warn;
	location = /robots.txt {
		allow all;
		log_not_found off;
		access_log off;
	}
 location = /.well-known/carddav {
      return 301 $scheme://$host:$server_port/remote.php/dav;
    }
    location = /.well-known/caldav {
      return 301 $scheme://$host:$server_port/remote.php/dav;
    }
	client_max_body_size 10240M;
# BEGIN ANSIBLE MANAGED BLOCK collabra
location ^~ /loleaflet {
proxy_pass https://localhost:9980;
proxy_set_header Host $http_host;
}
location ^~ /hosting/discovery {
proxy_pass https://localhost:9980;
proxy_set_header Host $http_host;
}
location ^~ /lool {
proxy_pass https://localhost:9980;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
# END ANSIBLE MANAGED BLOCK collabra
	location / {
		rewrite ^ /index.php$uri;
	}
	location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
		deny all;
	}
	location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
		deny all;
	}
	location ~* \.(?:flv|mp4|mov|m4a)$ {
		mp4;
		mp4_buffer_size 5m;
		mp4_max_buffer_size 10m;
		fastcgi_split_path_info ^(.+\.php)(/.*)$;
		include fastcgi_params;
		include php_optimization.conf;
		fastcgi_pass php-handler;
		fastcgi_param HTTPS on;
	}
	location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
		fastcgi_split_path_info ^(.+\.php)(/.*)$;
		include fastcgi_params;
		include php_optimization.conf;
		fastcgi_pass php-handler;
		fastcgi_param HTTPS on;
	}
	location ~ ^/(?:updater|ocs-provider)(?:$|/) {
		try_files $uri/ =404;
		index index.php;
	}
	location ~ \.(?:css|js|woff|svg|gif)$ {
		try_files $uri /index.php$uri$is_args$args;
		add_header Cache-Control "public, max-age=15778463";
		access_log off;
		expires 30d;
	}
	location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
		try_files $uri /index.php$uri$is_args$args;
		access_log off;
		expires 30d;
	}
}
#7

aaaand I’m hitting this problem again. No clue why… :frowning: