nextcloud
[Bug]: NC29 .well-known URLs, failed on: /.well-known/caldav
⚠️ This issue respects the following points: ⚠️
- [X] This is a bug, not a question or a configuration/webserver/proxy issue.
- [X] This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- [X] I agree to follow Nextcloud's Code of Conduct.
Bug description
With NC28 I had no well-known URL errors, and no change to the NGINX configuration. After upgrading to NC29, I now have the following message:
Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/caldav For more details see the [documentation ↗](https://docs.nextcloud.com/server/29/go.php?to=admin-setup-well-known-URL).
In the NGINX logs, I see a 401 errors:
192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "PROPFIND /.well-known/caldav HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler"
192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "GET /remote.php/dav HTTP/1.1" 401 569 "-" "Nextcloud Server Crawler"
192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "GET /.well-known/caldav HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler"
192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "GET /remote.php/dav HTTP/1.1" 401 569 "-" "Nextcloud Server Crawler"
My Android DAVx5 client doesn't seem to have any issues and continues to work well.
A curl test, shows the 301 redirect working, followed by a 401, but I'm assume that's expected with an unauthenticated request
curl -IL https://nextcloud.mydomain.com/.well-known/caldav
HTTP/2 301
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:12:51 GMT
content-type: text/html
content-length: 162
location: https://nextcloud.mydomain.com/remote.php/dav
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;
HTTP/2 401
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:12:51 GMT
content-type: application/xml; charset=utf-8
set-cookie: oc_sessionPassphrase=NoBfvCYLv%2B7Hzw7eRoiL4VWZNyADXzcx2k5fgbu4FerYYBJjgl%2Fq8xLrTWscFxu3ithDlInkdabcfGg0nbL0wrG3B%2BPRkOCYjtibS4QvsluoWlkgrT5DdSWiQGUwHxi9; path=/; secure; HttpOnly; SameSite=Lax
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
set-cookie: oc2a3d1f7bcc=6eadda8dbfe0995012c16997240ee6b0; path=/; secure; HttpOnly; SameSite=Lax
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
content-security-policy: default-src 'none';
www-authenticate: Basic realm="MyDomain, charset="UTF-8"
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;
There is an error in Nextcloud.log that appears relevant:
"File": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php",
"Line": 152,
"message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured"
Steps to reproduce
- Upgrade from NC28 to NC29
- well-known message in admin settings
Expected behavior
No well-known errors
Installation method
Community Manual installation with Archive
Nextcloud Server version
29
Operating system
Other
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
- [X] Default user-backend (database)
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Configuration report
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"nextcloud.mydomain.com",
"nextcloud"
],
"apps_paths": [
{
"path": "\/usr\/share\/nginx\/html\/nextcloud\/apps",
"url": "\/apps",
"writable": false
},
{
"path": "\/usr\/share\/nginx\/html\/nextcloud\/custom-apps",
"url": "\/custom-apps",
"writable": true
}
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "pgsql",
"version": "29.0.0.19",
"trusted_proxies": "***REMOVED SENSITIVE VALUE***",
"forwarded_for_headers": [
"HTTP_X_FORWARDED_FOR",
"HTTP_X_FORWARDED",
"HTTP_FORWARDED_FOR"
],
"overwriteprotocol": "https",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbtableprefix": "oc_",
"installed": true,
"mail_smtpmode": "smtp",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "465",
"loglevel": 0,
"maintenance": false,
"enable_previews": true,
"secret": "***REMOVED SENSITIVE VALUE***",
"filesystem_check_changes": 0,
"filelocking.enabled": "true",
"memcache.local": "\\OC\\Memcache\\APCu",
"memcache.locking": "\\OC\\Memcache\\Redis",
"redis": {
"host": "***REMOVED SENSITIVE VALUE***",
"port": 6379,
"timeout": 1.5,
"read_timeout": 1.5,
"dbindex": 0
},
"trashbin_retention_obligation": "auto",
"overwrite.cli.url": "https:\/\/nextcloud.mydomain.com",
"mail_smtpauthtype": "LOGIN",
"mail_smtpsecure": "ssl",
"theme": "",
"app_install_overwrite": [
"joplin"
],
"encryption.legacy_format_support": false,
"encryption.key_storage_migrated": false,
"default_language": "en",
"default_phone_region": "CA",
"maintenance_window_start": 1,
"memories.db.triggers.fcu": true,
"memories.exiftool": "\/usr\/share\/nginx\/html\/nextcloud\/custom-apps\/memories\/bin-ext\/exiftool-amd64-glibc",
"memories.vod.path": "\/usr\/share\/nginx\/html\/nextcloud\/custom-apps\/memories\/bin-ext\/go-vod-amd64",
"memories.gis_type": 2,
"enabledPreviewProviders": [
"OC\\Preview\\Image",
"OC\\Preview\\HEIC",
"OC\\Preview\\Movie",
"OC\\Preview\\TIFF"
]
}
}
List of activated Apps
No response
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
{
"reqId": "6jDGw0WbOAAarIrEpjXS",
"level": 0,
"time": "2024-04-25T13:21:06+00:00",
"remoteAddr": "192.168.9.6",
"user": "--",
"app": "webdav",
"method": "GET",
"url": "/remote.php/dav",
"message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured",
"userAgent": "Nextcloud Server Crawler",
"version": "29.0.0.19",
"exception": {
"Exception": "Sabre\\DAV\\Exception\\NotAuthenticated",
"Message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured",
"Code": 0,
"Trace": [
{
"file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
"line": 89,
"function": "beforeMethod",
"class": "Sabre\\DAV\\Auth\\Plugin",
"type": "->",
"args": [
[
"Sabre\\HTTP\\Request"
],
[
"Sabre\\HTTP\\Response"
]
]
},
{
"file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 456,
"function": "emit",
"class": "Sabre\\DAV\\Server",
"type": "->",
"args": [
"beforeMethod:GET",
[
[
"Sabre\\HTTP\\Request"
],
[
"Sabre\\HTTP\\Response"
]
]
]
},
{
"file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 253,
"function": "invokeMethod",
"class": "Sabre\\DAV\\Server",
"type": "->",
"args": [
[
"Sabre\\HTTP\\Request"
],
[
"Sabre\\HTTP\\Response"
]
]
},
{
"file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
"line": 321,
"function": "start",
"class": "Sabre\\DAV\\Server",
"type": "->",
"args": []
},
{
"file": "/usr/share/nginx/html/nextcloud/apps/dav/lib/Server.php",
"line": 374,
"function": "exec",
"class": "Sabre\\DAV\\Server",
"type": "->",
"args": []
},
{
"file": "/usr/share/nginx/html/nextcloud/apps/dav/appinfo/v2/remote.php",
"line": 35,
"function": "exec",
"class": "OCA\\DAV\\Server",
"type": "->",
"args": []
},
{
"file": "/usr/share/nginx/html/nextcloud/remote.php",
"line": 172,
"args": [
"/usr/share/nginx/html/nextcloud/apps/dav/appinfo/v2/remote.php"
],
"function": "require_once"
}
],
"File": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php",
"Line": 152,
"message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured",
"exception": {},
"CustomMessage": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured"
}
}
Additional info
No response
I have the same problem and noticed my .htaccess file was changed with the update are you also getting a warning that .htaccess is not working?
@meldarionqeusse I have the .htaccess file but as I'm using NGINX for the web server I think NGINX ignores it?
I think the well-known URLs are working. I created a new app password and passed the credentials with curl, the redirect works and I get a valid response. So I think the well-known redirects are working, but something has gone wrong with the test in admin settings and no authentication is passed.
curl -iL --location-trusted -u validuser:validpassword https://nextcloud.mydomain.com/.well-known/caldav
HTTP/2 301
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:55:24 GMT
content-type: text/html
content-length: 162
location: https://nextcloud.mydomain.com/remote.php/dav
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;
HTTP/2 200
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:55:25 GMT
content-type: text/html; charset=UTF-8
set-cookie: oc_sessionPassphrase=BYDq5MblWFD0ccawoP0IeYzmlmUteNvFJ%2FaUKJIEZhRdAc4hkrKkA9NPlui%2FaI9QfbW%2F1MmckdtmPRfrlg4oIm8XeaMXLECM0NqBOwdhhf1oeQyeNd5ixn7h%2FkkIY5QA; path=/; secure; HttpOnly; SameSite=Lax
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
content-security-policy: default-src 'none';
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
set-cookie: oc2a3d1f7bcc=7c4296af03227b5fa1a1eb6b2036acf1; path=/; secure; HttpOnly; SameSite=Lax
x-request-id: W9r66ZwhVZCA74Qr6dkT
x-debug-token: W9r66ZwhVZCA74Qr6dkT
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;
This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client
I have the same problem after upgrading to NC29, using apache2, php8.2-fpm and nginx proxy manager. But everything seems to be working fine for now.
Starting with 29 the check is done via php and no longer by your browser. We are using the overwrite.cli.url for it.
Here is the code: https://github.com/nextcloud/server/blob/master/apps/settings/lib/SetupChecks/WellKnownUrls.php
To debug it further please check the redirect on the server with curl and use the overwrite url.
@kesselb overwrite URL is the public facing domain
grep overwrite config.php
'overwriteprotocol' => 'https',
'overwrite.cli.url' => 'https://nextcloud.mydomain.com',
'app_install_overwrite' =>
It's the same URL I used in my successful curl test should it be something different?
I'm getting the same problem after upgrading to NC29.0.0. The error must be inaccurately reported as both my calendar and contacts are redirecting properly and syncing to my mobile device. A bit of testing: ./nextcloud/apps/settings/lib/SetupChecks/WellKnownUrls.php has the following lines of code:
['propfind', '/.well-known/carddav', [207], false],
['propfind', '/.well-known/caldav', [207], false],
With the above lines of code enabled, Nextcloud reports a "/.well-known/caldav" error. If I comment out the carddav line, Nextcloud reports the same caldav error. But if I comment out the caldav line and uncomment the carddav line, Nextcloud now reports a carddav error.
It's looking like it's reporting the last test as an error even though it's not.
If I comment out both lines, there's no error reported.
(NC29.0.0 with Apache2, behind Reverse Proxy (Nginx) Server)
Same problem here. I use 'overwrite.cli.url' => 'https://nextcloud.mydomain.com', and curl -L -u validuser:validpassword https://nextcloud.mydomain.com/.well-known/caldav outputs the WebDAV message of the interface correctly.
Same problem after upgrade to Nextcloud 29.0.0 on Apache2. The install documentation has the redirects set to "301" in .htaccess and the error occurs even though the redirects have been verified as functioning properly. Changing the .htaccess redirects from "301" to "207" has resolved the errors on my end.
Changing the .htaccess redirects from "301" to "207" has resolved the errors on my end.
Does the redirect still work? ;)
We are looking into the problem and if you are certain that the redirects are okay, then please ignore the setup check for now. Please don't change the response code to 207, that's just wrong.
@cvandesande
The setup check expects a redirect to /remote.php/dav/.^1
Your redirect goes to /remote.php/dav without a trailing slash.
Please double-check your configuration if the redirects are configured with a trailing slash.^2
Seems like the documentation isn't really clear about that :/
For apache, there are no trailing slashes mentioned: https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#service-discovery-label
Also, for reverse proxies there are some with, some without trailing slashes: https://docs.nextcloud.com/server/29/admin_manual/configuration_server/reverse_proxy_configuration.html#service-discovery
(Also, my Gnome Online Account [Fedora 40, Gnome 46] still doesn't work after adding trailing slashes, DAVx5 works fine though, and the error in the web ui is also gone)
I think for the functionality - the service discovery - the trailing slash is not that important. The check, that works different since 29 than before, is rather strict and tests for the trailing slash.
In any case, the documentation should be updated. The service discovery is usually a topic if you are using a reverse proxy (without it should work out of the box) and therefore it's a part of that documentation. For the other cases, we have the article in the general troubleshooting section. It should be fine to move the service discovery to an own page in configuration_server and merge the articles.
Solution for me: Redirection to /remote.php/dav/ with trailing slash at the end in Nginx Proxy Manager makes the error message disappear.
Trailing slash was the solution for me as well. Thank you! Agree with @KopfKrieg trailing slashes are missing from the NGINX reverse proxy docs: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#nginx
@kesselb should we keep this issue open, or close it and open a documentation issue?
Unfortunately, a trailing slash does not help my nc 29 instance. It still complain with either the following lines:
location ^~ /.well-known {
# The rules in this block are an adaptation of the rules
# in `.htaccess` that concern `/.well-known`.
location = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav/; }
location = /.well-known/caldav { return 301 $scheme://$host/remote.php/dav/; }
}
or
location ^~ /.well-known {
# The rules in this block are an adaptation of the rules
# in `.htaccess` that concern `/.well-known`.
rewrite ^/\.well-known/carddav https://$server_name/remote.php/dav/ redirect;
rewrite ^/\.well-known/caldav https://$server_name/remote.php/dav/ redirect;
}
Came here to confirm, changing THIS:
To THIS:
Fixed THIS issue when upgrading to v29.0.0:
I also restarted Nextcloud instance and my NPM Proxy it was going through :-)
having this issue as well.
Caddy setup as reverse proxy, nextcloud manual install on its own VM. Caddy rewrite is working, returning a 401 result, resulting warning in Admin Overview.
./nextcloud/apps/settings/lib/SetupChecks/WellKnownUrls.php has the following lines of code:
['propfind', '/.well-known/carddav', [207], false], ['propfind', '/.well-known/caldav', [207], false],(NC29.0.0 with Apache2, behind Reverse Proxy (Nginx) Server)
This causes problem for subfolder installations because this will be checking for /subfolder/.well-known/carddav instead of /.well-known/carddav whereas applications using WebDAV will be querying for /.well-known/carddav without the subfolder.
I have a workaround for nginx/swag in https://github.com/linuxserver/reverse-proxy-confs/pull/673 if anyone is facing the same problem as I do
@h9419
This causes problem for subfolder installations because this will be checking for /subfolder/.well-known/carddav instead of /.well-known/carddav whereas applications using WebDAV will be querying for /.well-known/carddav without the subfolder.
If overwrite.cli.url is yourhost.com/subfolder, then it will indeed check for yourhost.com/subfolder/.well-known/carddav.
The check also takes the trusted_domains into account, which should be declared without a subfolder and make the check pass.
Mind to take a look at your trusted_domains and share them with us?
My trusted domains array cloud.domain.com, overwritecli has the same domain with https://
Not using a subfolder.
My trusted domains array cloud.domain.com, overwritecli has the same domain with https://
Did you try to update the caddy redirect rules so they redirect to /remote.php/dav/ rather than /remote.php/dav (note the additional trailing slash)?
Did you try to update the caddy redirect rules so they redirect to
/remote.php/dav/rather than/remote.php/dav(note the additional trailing slash)?
Yes, that wasn't the fix.
I struggled with this issue for the past 48 hours. I am using Nextcloud 29. At first I thought it was an issue with upgrading to Ubuntu Server 24.04. However, adding 'localhost' to config/config.php file fixed it for me. I updated my file to this;
'trusted_domains' => array ( 0 => 'nextcloud.mydomain.com', 1 => 'localhost' ),
I hope this helps any one else who is struggling.
I struggled with this issue for the past 48 hours. I am using Nextcloud 29. At first I thought it was an issue with upgrading to Ubuntu Server 24.04. However, adding 'localhost' to config/config.php file fixed it for me. I updated my file to this;
'trusted_domains' => array ( 0 => 'nextcloud.mydomain.com', 1 => 'localhost' ),
I hope this helps any one else who is struggling.
Sadly didn't work on my end either. With or without the trailing / on the redirect.
I struggled with this issue for the past 48 hours. I am using Nextcloud 29. At first I thought it was an issue with upgrading to Ubuntu Server 24.04. However, adding 'localhost' to config/config.php file fixed it for me. I updated my file to this; 'trusted_domains' => array ( 0 => 'nextcloud.mydomain.com', 1 => 'localhost' ), I hope this helps any one else who is struggling.
Sadly didn't work on my end either. With or without the trailing
/on the redirect.
The other thing I added when it started working was 'htaccess.RewriteBase' => '/', but I am not sure if that will work.
The other thing I added when it started working was 'htaccess.RewriteBase' => '/', but I am not sure if that will work.
Was worth a try, but yea, it didn't do anything.
In my 28.0.5 behind a Nginx reverse proxy the checks for /.well-known/carddav and /.well-known/carddav work now after adding the trailing / on the redirect. It still complains about /.well-known/nodeinfo and /.well-known/webfinger where I don't have any redirect and forward as is to the Nextcloud server which is also a Nginx / fpm with the configuration as from the latest manual.
It works with the default setting. I had the problem before and send a solution by changing the number in the redirect statement. The final solution was disabeling all rewrite rules in .htaccess and copy the the content (only the few lines with the rewrites) from git. Works for Apache.
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 ^ocm-provider/?$ index.php [QSA,L]
RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
KR
