Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Lorenzoform opened this issue Oct 15, 2018 · 34 comments

Comments

@Lorenzoform
Copy link

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
Copy link
Member

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

@warthog9
Copy link

Issue looks like it's related to

checkWellKnownUrl: function(url, placeholderUrl, runCheck) {

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:

url: url,
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
Copy link

warthog9 commented Oct 18, 2018

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
Copy link
Author

Hi,

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

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

<Directory /var/www/html/nextcloud/>
Options +FollowSymlinks
AllowOverride All

Dav off

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

@cvandesande
Copy link

cvandesande commented Oct 21, 2018

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
Copy link
Member

enoch85 commented Oct 28, 2018

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

@MorrisJobke
Copy link
Member

@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: #11787 (comment)

@cvandesande
Copy link

cvandesande commented Oct 30, 2018

@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
Copy link
Member

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
Copy link

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
Copy link

cvandesande commented Oct 30, 2018

@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
Copy link
Member

enoch85 commented Oct 31, 2018

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

Fyi @josh4trunks

@MorrisJobke
Copy link
Member

See also nextcloud/documentation#899 for more details about this

@enoch85
Copy link
Member

enoch85 commented Oct 31, 2018

Confirmed, working. Thanks @cvandesande!

@rcdailey
Copy link
Contributor

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

@pauvos
Copy link

pauvos commented Dec 1, 2018

@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
Copy link

jcklpe commented Jul 20, 2019

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
Copy link

jcklpe commented Jul 20, 2019

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

@rubo77
Copy link
Contributor

rubo77 commented Oct 1, 2019

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
Copy link

antoneliasson commented Nov 2, 2019

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
Copy link
Contributor

kesselb commented Dec 26, 2019

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

As posted above #11787 (comment) 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
Copy link
Contributor

kesselb commented Dec 27, 2019

@pgnd Have you read #11787 (comment) 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. #11787 (comment) 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
Copy link

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
Copy link

pauvos commented Jan 27, 2020

@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
Copy link

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
Copy link

@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
Copy link

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

@DesktopMasters
Copy link

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).

@ianhundere
Copy link

i added the following to my nextcloud ingress:

    nginx.ingress.kubernetes.io/configuration-snippet: |
      location = /.well-known/carddav {
          return 301 /remote.php/dav;
      }
      location = /.well-known/caldav {
          return 301 /remote.php/dav;
      }

@g-vdn
Copy link

g-vdn commented Apr 26, 2022

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

After 4 years, this is what helped me :) Nothing else worked

@canonex
Copy link

canonex commented Jul 7, 2022

@g-vdn I confirm that it is, also for me, the only viable solution.

@JuliusWiedemann
Copy link

This tip did not work for me in nextcloud.conf. I had to change this in the .htaccess file to work properly. Here the configuration is similar.

Before:

<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/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]
      RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
      RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

After:

<IfModule mod_rewrite.c>
      RewriteEngine on
      RewriteCond %{HTTP_USER_AGENT} DavClnt
      RewriteRule ^$ https://example.org/remote.php/webdav/ [L,R=302]
      RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
      RewriteRule ^\.well-known/carddav https://example.org/remote.php/dav/ [R=301,L]
      RewriteRule ^\.well-known/caldav https://example.org/remote.php/dav/ [R=301,L]
      RewriteRule ^remote/(.*) remote.php [QSA,L]
      RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
      RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
      RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

@qudiqudi
Copy link

qudiqudi commented Dec 7, 2022

This tip did not work for me in nextcloud.conf. I had to change this in the .htaccess file to work properly. Here the configuration is similar.

Before:

<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/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]
      RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
      RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

After:

<IfModule mod_rewrite.c>
      RewriteEngine on
      RewriteCond %{HTTP_USER_AGENT} DavClnt
      RewriteRule ^$ https://example.org/remote.php/webdav/ [L,R=302]
      RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
      RewriteRule ^\.well-known/carddav https://example.org/remote.php/dav/ [R=301,L]
      RewriteRule ^\.well-known/caldav https://example.org/remote.php/dav/ [R=301,L]
      RewriteRule ^remote/(.*) remote.php [QSA,L]
      RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
      RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
      RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

Did you explicitly use example.org in .htaccess? Or is this just a placeholder for your domain? Which would mean nextcloud is sitting behind subfolder of example.org? Because this wouldn't work with a subdomain like cloud.example.org.
I also have a setup without a nextcloud.conf, so .htaccess is my only way of telling nextcloud it is well served behind traefik 2 with well-known working properly, it is just bugging me that it isn't in the admin settings.

@JuliusWiedemann
Copy link

This tip did not work for me in nextcloud.conf. I had to change this in the .htaccess file to work properly. Here the configuration is similar.
Before:

<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/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]
      RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
      RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

After:

<IfModule mod_rewrite.c>
      RewriteEngine on
      RewriteCond %{HTTP_USER_AGENT} DavClnt
      RewriteRule ^$ https://example.org/remote.php/webdav/ [L,R=302]
      RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
      RewriteRule ^\.well-known/carddav https://example.org/remote.php/dav/ [R=301,L]
      RewriteRule ^\.well-known/caldav https://example.org/remote.php/dav/ [R=301,L]
      RewriteRule ^remote/(.*) remote.php [QSA,L]
      RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
      RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
      RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

Did you explicitly use example.org in .htaccess? Or is this just a placeholder for your domain? Which would mean nextcloud is sitting behind subfolder of example.org? Because this wouldn't work with a subdomain like cloud.example.org. I also have a setup without a nextcloud.conf, so .htaccess is my only way of telling nextcloud it is well served behind traefik 2 with well-known working properly, it is just bugging me that it isn't in the admin settings.

example.org is just a placeholder for my domain. And I am using a subdomain for my instance (nextcloud.example.com). My nextcloud does not sit behind a subfolder of example.org

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests