[Bug]: NC29 .well-known URLs, failed on: /.well-known/caldav #45033
Comments
cvandesande
added
0. Needs triage
|
I have the same problem and noticed my |
|
@meldarionqeusse I have the 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. |
|
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. |
|
I have this with 28.0.4. |
|
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. |
|
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. With the above lines of code enabled, Nextcloud reports a "/.well-known/caldav" 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 |
|
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. |
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. |
|
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. 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 |
|
Trailing slash was the solution for me as well. Thank you! @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: or |
|
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. |
This causes problem for subfolder installations because this will be checking for I have a workaround for nginx/swag in linuxserver/reverse-proxy-confs#673 if anyone is facing the same problem as I do |
If The check also takes the 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. |
Did you try to update the caddy redirect rules so they redirect to |
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' => I hope this helps any one else who is struggling. |
Sadly didn't work on my end either. With or without the trailing |
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. |
This is a 29 issue. |
|
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. KR |
@kesselb: this doesn't seem to work in my case. Nextcloud: 29.0.0 (located in a subdir of webroot) This is a fresh installation only for testing this, with no extra configuration, hence $CONFIG = array (
'passwordsalt' => '****',
'secret' => '****',
'trusted_domains' =>
array (
0 => 'subdir.webroot.de',
),
'datadirectory' => '/path/to/subdir.webroot.de/nextcloud/data',
'dbtype' => 'sqlite3',
'version' => '29.0.0.19',
'overwrite.cli.url' => 'https://subdir.webroot.de/nextcloud',
'installed' => true,
'instanceid' => '****',
);
The redirect is configured properly and works as it should: root@server:/# curl -IL https://subdir.webroot.de/.well-known/webfinger HTTP/2 301 server: nginx date: Sun, 05 May 2024 06:35:27 GMT content-type: text/html content-length: 162 location: https://subdir.webroot.de/nextcloud/index.php/.well-known/webfinger referrer-policy: no-referrer x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-permitted-cross-domain-policies: none x-xss-protection: 1; mode=block strict-transport-security: max-age=15768000; includeSubDomains; preload x-robots-tag: noindex, nofollow HTTP/2 404 server: nginx date: Sun, 05 May 2024 06:35:27 GMT content-type: application/json; charset=utf-8 content-length: 37 set-cookie: oc_sessionPassphrase=jno%2FSH6iYwVKsyRwVYw9UQlGEh8CYvu6VW9sDAnVQNJHSRAcaqEM86G%2BDW2cWjZZNqSxCRG5YWeFmevBNOJWvt1lGlqqvq4zLe7EQHaWblTjoOwIBq9JfnUTWmkQjKqs; path=/nextcloud; secure; HttpOnly; SameSite=Lax set-cookie: nc_sameSiteCookielax=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax set-cookie: nc_sameSiteCookiestrict=true; path=/nextcloud; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict set-cookie: ocpe2vl716a4=qgon0iqhe10k2pfq31thdqq3r6; path=/nextcloud; secure; HttpOnly; SameSite=Lax expires: Thu, 19 Nov 1981 08:52:00 GMT pragma: no-cache x-request-id: MceyZE07GX8qfHsxfVIH cache-control: no-cache, no-store, must-revalidate content-security-policy: default-src 'none';base-uri 'none';manifest-src 'self';frame-ancestors 'none' feature-policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none' x-robots-tag: noindex, nofollow x-nextcloud-well-known: 1 referrer-policy: no-referrer x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-permitted-cross-domain-policies: none x-robots-tag: noindex, nofollow x-xss-protection: 1; mode=block root@server:/# curl -L https://subdir.webroot.de/.well-known/webfinger
{"message":"webfinger not supported"}
But the redirect from the webroot is not being tested as you can see in the nginx access log when visiting 1.2.3.4 - - [05/May/2024:08:21:18 +0200] "PROPFIND /nextcloud/remote.php/webdav HTTP/1.1" 401 426 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:19 +0200] "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:19 +0200] "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:19 +0200] "HEAD /nextcloud/nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:20 +0200] "HEAD /nextcloud/ocm-provider/ HTTP/1.1" 200 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:20 +0200] "HEAD /nextcloud/ocs-provider/ HTTP/1.1" 200 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:21 +0200] "GET /nextcloud/ HTTP/1.1" 302 5 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:21 +0200] "GET /nextcloud/login HTTP/1.1" 200 5818 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:21 +0200] "GET /nextcloud/.well-known/webfinger HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [05/May/2024:08:21:21 +0200] "GET /nextcloud/.well-known/webfinger HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" |
What happens if you curl this uri? The curl output from above shows a 301 to |
root@server:~# curl -i https://subdir.webroot.de/nextcloud/.well-known/webfinger HTTP/2 404 server: nginx date: Sun, 05 May 2024 09:48:31 GMT content-type: text/html content-length: 146 referrer-policy: no-referrer x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-permitted-cross-domain-policies: none x-robots-tag: noindex, nofollow x-xss-protection: 1; mode=block <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html> |
|
That's the nginx 404 page which misses the x-nextcloud-well-known: 1 header and therefore the check fails. I guess you have to find out why this request is not forwarded to Nextcloud but handled directly by nginx. |
|
@BernieO I'm a bit confused by your configuration. Aren't pretty urls enabled by default when using nginx? I think the reason for the request without index.php is that we don't factor in setups without pretty urls here. Edit: The request for /nextcloud/.well-known/webfinger is supposed to fail and therefore the 404 from nginx okay. I guess the request is initiated from overwrite.cli.url (the last case in test urls). The more important question is why the previous request for the trusted domains does not succeed. Is there no request for |
No, there is not. I just double checked. Only requests for uris within EDIT (06.05.2024):
I changed the 'trusted_domains' =>
array (
0 => 'subdir.webroot.de',
),
'overwrite.cli.url' => 'https://overwritecliurl.webroot.de/nextcloud',
Your guess was correct: the second request for 1.2.3.4 - - [06/May/2024:07:35:08 +0200] "subdir.webroot.de" "PROPFIND /nextcloud/remote.php/webdav HTTP/1.1" 401 426 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:10 +0200] "subdir.webroot.de" "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:10 +0200] "subdir.webroot.de" "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:10 +0200] "overwritecliurl.webroot.de" "HEAD /nextcloud/nextcloud/data/.ocdata HTTP/1.1" 400 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:11 +0200] "subdir.webroot.de" "HEAD /nextcloud/ocm-provider/ HTTP/1.1" 200 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:12 +0200] "subdir.webroot.de" "HEAD /nextcloud/ocs-provider/ HTTP/1.1" 200 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:12 +0200] "subdir.webroot.de" "GET /nextcloud/ HTTP/1.1" 302 5 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:12 +0200] "subdir.webroot.de" "GET /nextcloud/login HTTP/1.1" 200 5821 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:13 +0200] "subdir.webroot.de" "GET /nextcloud/.well-known/webfinger HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:07:35:13 +0200] "overwritecliurl.webroot.de" "GET /nextcloud/.well-known/webfinger HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" Is there anything else I can do to help debugging? |
|
I noticed two things:
|
|
That worked for my testing instance in a subdirectory. The warning in the admin panel disappeared. 1.2.3.4 - - [06/May/2024:15:26:35 +0200] "subdir.webroot.de" "PROPFIND /nextcloud/remote.php/webdav HTTP/1.1" 401 426 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:36 +0200] "subdir.webroot.de" "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:36 +0200] "subdir.webroot.de" "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:36 +0200] "subdir.webroot.de" "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:36 +0200] "overwritecliurl.webroot.de" "HEAD /nextcloud/data/.ocdata HTTP/1.1" 404 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:37 +0200] "subdir.webroot.de" "HEAD /nextcloud/ocm-provider/ HTTP/1.1" 200 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:37 +0200] "subdir.webroot.de" "HEAD /nextcloud/ocs-provider/ HTTP/1.1" 200 0 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "subdir.webroot.de" "GET /nextcloud/ HTTP/1.1" 302 5 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "subdir.webroot.de" "GET /nextcloud/login HTTP/1.1" 200 5816 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "subdir.webroot.de" "GET /nextcloud/.well-known/webfinger HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "overwritecliurl.webroot.de" "GET /.well-known/webfinger HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "overwritecliurl.webroot.de" "GET /nextcloud/index.php/.well-known/webfinger HTTP/1.1" 404 37 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "subdir.webroot.de" "GET /nextcloud/.well-known/nodeinfo HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "overwritecliurl.webroot.de" "GET /.well-known/nodeinfo HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "overwritecliurl.webroot.de" "GET /nextcloud/index.php/.well-known/nodeinfo HTTP/1.1" 404 36 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "subdir.webroot.de" "PROPFIND /nextcloud/.well-known/caldav HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:38 +0200] "overwritecliurl.webroot.de" "PROPFIND /.well-known/caldav HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:39 +0200] "overwritecliurl.webroot.de" "GET /nextcloud/remote.php/dav/ HTTP/1.1" 401 569 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:40 +0200] "subdir.webroot.de" "PROPFIND /nextcloud/.well-known/carddav HTTP/1.1" 404 146 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:40 +0200] "overwritecliurl.webroot.de" "PROPFIND /.well-known/carddav HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler" 1.2.3.4 - - [06/May/2024:15:26:40 +0200] "overwritecliurl.webroot.de" "GET /nextcloud/remote.php/dav/ HTTP/1.1" 401 569 "-" "Nextcloud Server Crawler" It also works in a production instance (also located in a subdirectory).Thanks a lot! |
|
@kesselb how do we proceed? |
|
Pull Request to update the documentation for Caddy: nextcloud/documentation#11799
The code is used by multiple setup checks, and thus I don't know if it's good to strip the webroot for every case. |
I see.
No, not regarding |
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:
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
There is an error in Nextcloud.log that appears relevant:
Steps to reproduce
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?
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
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
The text was updated successfully, but these errors were encountered: