Carddav and caldav still not working

[Khymick]

Hi all,

I still get the message that my webserver is not correctly configured to resolve"/.well-known/caldav" (and also for carddav). Details of my system see below. I hope that somebody can help me to solve it.

My config is so far:

1. next cloud config file for apache:

<IfModule mod_headers.c>
      Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>

Alias /ncloud "/var/www/nextcloud/"

<Directory /var/www/ncloud/>
  Options +FollowSymlinks +MultiViews
  AllowOverride All
  Require all granted
 <IfModule mod_dav.c>
  Dav off
 </IfModule>

 SetEnv HOME /var/www/ncloud
 SetEnv HTTP_HOME /var/www/ncloud

</Directory>   

2. .htaccess file of next cloud dir:

<IfModule mod_headers.c>
  <IfModule mod_setenvif.c>
    <IfModule mod_fcgid.c>
       SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
       RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
    <IfModule mod_proxy_fcgi.c>
       SetEnvIfNoCase Authorization "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>
  </IfModule>

  <IfModule mod_env.c>
    # Add security and privacy related headers
    Header always set Referrer-Policy "no-referrer"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Download-Options "noopen"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Permitted-Cross-Domain-Policies "none"
    Header always set X-Robots-Tag "none"
    Header always set X-XSS-Protection "1; mode=block"
    SetEnv modHeadersAvailable true
  </IfModule>

  # Add cache control for static resources
  <FilesMatch "\.(css|js|svg|gif)$">
    Header set Cache-Control "max-age=15778463"
  </FilesMatch>

  # Let browsers cache WOFF files for a week
  <FilesMatch "\.woff2?$">
    Header set Cache-Control "max-age=604800"
  </FilesMatch>
</IfModule>
<IfModule mod_php7.c>
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>
<IfModule mod_rewrite.c>
  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 /ncloud/public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /ncloud/public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/webfinger /ncloud/public.php?service=webfinger [QSA,L]
  RewriteRule ^\.well-known/nodeinfo /ncloud/public.php?service=nodeinfo [QSA,L]
  RewriteRule ^\.well-known/carddav /ncloud/remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /ncloud/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]
</IfModule>
<IfModule mod_mime.c>
  AddType image/svg+xml svg svgz
  AddEncoding gzip svgz
</IfModule>
<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>
AddDefaultCharset utf-8
Options -Indexes
<IfModule pagespeed_module>
  ModPagespeed Off
</IfModule>
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /ncloud/
ErrorDocument 404 /ncloud/

Nextcloud version (eg, 12.0.2): 17.0.3
Operating system and version (eg, Ubuntu 17.04): Debian 9.11
Apache or nginx version (eg, Apache 2.4.25): Server version: Apache/2.4.25 (Debian)
Server built: 2019-10-13T15:43:54
PHP version (eg, 7.1): 7.3

[JimmyKater]

@Khymick

please refer to several threads here on the forum about solving this issue as this forum contains of a built-in search-function.
you could easily find it by looking for a -icon located to the upper right corner of this window

good luck

[Khymick]

@JimmyKater

I know that there are a quite some threads here. The ones I already tried are:

/.well-known/caldav

jo. du machst dir ja nicht so richtig viel mühe… beispielsweise gibt deine fehlermeldung durchaus an, WO du nachschauen könntest (meines wissesns nach gibts da auch genaue anleitungen)… und auch hier im forum gibts zig threads zu dem thema. vermutlich schreibst du die bemängelten infos 2x durch eine doppelkonfiguration. das könnte den fehler verursachen. viel erfolg.

Not properly set up to resolve "/.well-known/caldav"

I’m after getting rid of the message suggesting to only use https I’ve encountered the above mentioned error. Didn’t have that one before. I’ve searched through the forum and read the documentation but I have already made those changes that are mentioned. I’ve set the URL to the suggested path of RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L] RewriteRule ^.well-known/caldav /remote.php/dav/ [R=301,L] but I am still getting a warning: Your web server is not properly set up t…

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

you can test it with wget <ip-address>/.well-known/caldav and see some redirections. “Outside” could even be a ubuntu terminal/shell. But I don’t think the test is wrong. That one is a tricky one… As it sure is not certain, that you need the function those rewrite-rules give to you… You don’t have problems on “the system” but with probably attached computers/mob-phones… that would be: problems setting up calendar and contact apps. (So: problems elsewhere and the fix on “the system”) But some…

None of them got rid of the messages.
That’s why I kindly ask for help. This issue seems to be discussed quite a lot, but I didn’t find any solution up to now.

[JimmyKater]

so you made sure that .htaccess isn’t written twice? that was the common problem with that ki9nd of errors.

plus: from when on this problem did appear to your server? like right after upgrading to 17.03. or ahead of it?

[Khymick]

I tried quite a lot of combinations up to now.
Let me just add some informations:

DocumentRoot: /var/www
Nextcloud root: /var/www/nextcloud

What I tried so far:

• .htaccess only in Nextcloud root
• .htaccess both in DocumentRoot and Nextcloud root
• .htaccess only in DocumentRoot

None of them worked. I am not sure if the paths are always correct. Let me therefor ask the following questions:

1. If I include the .htaccess in DocumentRoot, do I have to include
   “RewriteRule ^.well-known/host-meta /public.php?service=host-meta [QSA,L]”
   OR
   “RewriteRule ^.well-known/host-meta /ncloud/public.php?service=host-meta [QSA,L]”

2. The same question if I have it in Nextcloud root?

3. Is there any possibility for me to check if these rules are applied?

Concerning your question if this appeared before or after the update to 17.0.3, I cannot answer: I did not check it before the update.

[JimmyKater]

i just got through your apache-config-

i see your setting a variable

@Khymick

Alias /ncloud “/var/www/nextcloud/”

but make no use of it… at least no real use…

because from my understanding

@Khymick

SetEnv HOME /var/www/ncloud 
SetEnv HTTP_HOME /var/www/ncloud

doesn’t use your variable from above but points to a different place than

@Khymick

Nextcloud root: /var/www/nextcloud

so i thought that
SetEnv HOME /var/www/ncloud
SetEnv HTTP_HOME /var/www/ncloud

should change into
SetEnv HOME /var/www/nextcloud
SetEnv HTTP_HOME /var/www/nextcloud

but please correct me if i’m wrong. i’m still more or less a noob

[kesselb]

I tried to explain this whole topic a bit over here. Probably helpful: https://github.com/nextcloud/server/issues/11850#issuecomment-569310169

[Khymick]

Hi,

@JimmyKater
Thanks for your reply. I am no apache expert. Your point do sound quite logic to me. I changed the settings for HOME and HTTP_HOME. I also checked if I got “nextcloud” instead of “ncloud” in my .htaccess ; unfortunately this did not change the warning. So this seems not to be the cause.

@kesselb
Thanks for your infos. As I understand, this is only a warning. But what does this mean for the use in everyday life? I use quite some apple devices and if I got this correct, they will not discover these things. Does this mean that I will face problems when I configure access to it?

Generally, I´d really like to help to approach a possible solution to the problem. I read some threads about this warning, but there were no real explanations how the things behind the scenes do work. I will try to put an explanation as I see things ; please correct me, if I am wrong in any point.

So, here we go:

1. The client will try to contact the nextcloud server for the functionalities

2. for discovery of CalDAV and CardDAV service, the following address is used:
   https://example.com/.well-known/

3. In order that this address can be correctly contacted, the web server itself has to be configured correctly in order to resolve it.

4. Here, I start to do not know what exactly does happen, as I am no apache expert. Most of the times, threads talk about configuring the correct resolving lines in a file called “.htaccess”. I wonder why it has to be done there, because the name of this file rather says that it has is connected to “how can access the web server directory”. The configuration of resolving imho is rather connected to the apache2 / virtual host configutration. This is the first thing I do not understand - and as I read some threads, this may help to understand what is happening really.

5. Now, if we take into consideration that we have to to the changes in the “.htaccess” file, there is a big black hole as I understand what this file really does when it is stored in a specific folder. Let me explain what I mean:

• A web server such as apache has a “DocumentRoot” directory. This is the top folder under which all web sites are saved. An example is “/var/www”
• A sub-dir of the DocumentRoot in which you store the nextcloud server files. In most examples I read, this may be “/var/www/nextcloud”

Now, there might be an “.htaccess” file in both directories.
@JimmyKater wrote in threads that if there are two files (one in DocumentRoot and one in the nextcloud subdir), the admin (=you, in my case me) should make sure that these 2 files do not contain the same redirections.
What is not really cleared to me is the following:
If we read through the general settings that should be made in the .htaccess file (I mention only one line in order to make it easier to understand):

RewriteRule ^\.well-known/host-meta /nextcloud/public.php?service=host-meta [QSA,L]

Now, in this line we see the part “/nextcloud/public.php?”. Here, the subdir of the nextcloud data is explicitly mentioned. To me, it is not clear if this is necessary in both cases, I mean:

• .htaccess stored in DocumentRoot
• .htaccess stored in nextcloud subdir

Why do I ask this? I do not understand how apache is really working here. I got the DocumentRoot and the nextcloud subdir configured - is this connected to the paths I configure here or are these settings completely independent? If we could answer this question, I think some people could better understand how this is all connected together.

6. For the settings itself, it would be good to understand what

RewriteRule ^\.well-known/host-meta /nextcloud/public.php?service=host-meta [QSA,L]

does really do. I did not find any easy explanation for ^ - I think that this may be some kind of first part of the string. If this is correct, this would mean that

 ^\.well-known/host-meta
would be automatically filled with the following string
https://example.com/.well-known/host-meta

Again: Somebody would have to clear if this is correct.

7. Now, in the next step we should insert a functionality what should happen if

https://example.com/.well-known/host-meta

is entered in a browser. In my tests (in a working nextcloud setup), I only get back a blank site.
In the misconfigured nextcloud site, the apache answers with a 404 not found error.
(Unfortunately, I have no access to the config files of the correct set up nextcloud instance).

8. If 7 leads to a 404 error, we should clarify if there are further steps in order to check what is really wrong. I think of check of config files, testing of some replies with different tools than a browser…

I know that this is quite a lot, but to me, it would be good if we could go through this. Imho, this would really help to understand what is really happening - and help people with this problem to search for the cause. Most of the issues should be in a wrongly configured web server, but as most people are not deep into the technologies of such things, it would help to give these people direct commands as well as background info - therefor “help the people to help themselves”.