-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
[Bug]: NC29 .well-known URLs, failed on: /.well-known/caldav #45033
[Bug]: NC29 .well-known URLs, failed on: /.well-known/caldav #45033
Comments
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
|
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. |
I can confirm after MUCH grief since NC 28 broke this that the patch beginning this thread (1) won't apply as written (rejected), but (2) manually applying the changes DOES FIX the webfinger problem! This is on Archlinux, Nextcloud Hub 8 (29.0.6) with:
|
It is fixed for the upcoming point releases of NC29 and NC30, scheduled for upcoming week :) . |
If you still see the issue with the upcoming 29.0.7 or 30.0.0, we already have a follow-up for 29.0.8 and 30.0.1 in the queue to resolve the problem for more cases. |
I love you 🤟 |
I'm just the messenger, Ferdinand did the work ;) |
This is depressing. Just updated to Hub 8 29.0.7 and after fixing the well-known web-finger warning with the patch in this thread, now it's back in a different form. Among other new warnings in 29.0.7 that didn't exist in 29.0.6, we now get:
In addition to now claiming it "Could not check that your web server serves
None of which were shown in Ver. 29.0.6. I'm not sure whether progress was made or not given the new related warnings that are shown. Nothing else changed, just updated and ran |
Same Problem as you… |
I had exactly the same many warnings after updating to 29.0.7 I could fix it by checking all entries in trusted_domains AND overwrite.cli.url. I had a mistake in overwrite.cli.url. I had a subdirectory at the end of my overwrite.cli.url (www.domain.com/nextcloud). After removing this and only pointing to the real domain (www.domain.com) ALL of these warning were gone. //EDIT: Do not follow this "solution". According to the posts below this is not a suitable solution! Please also refer to #45033 (comment) |
Thank You! My install is in I don't know why that issue hadn't surfaced until now -- but I guess 29.0.7 finally got around to adding checks that disclosed the issue (or something else changed...) My warnings are gone now removing Whew, I hate having warning... |
I solved all but one warning with this redirect:
Apparently the check for .well-known is now missing the domain in the testURL... |
See #45033 (comment) , the issue actually got worse because of a mistake in the fix we merged in the last releases. It should be fixed in the next one, the PR is in the work. Please do not remove the webroot from the |
Pardon me for my confusion here, but before I install 29.0.8, I'm supposed to re-add the install subdirectory (more a statement than a questions, but correct me if I am wrong...) Understanding these things happen ... it reminds us we are human ... it will get much worse once humans are removed from the development chain ... then when it happens there will be no human left that retains the institutional knowledge to know where the problem hides... |
You should actually put back the subdirectory right now, and ignore the warning. Note that I did not check if anything actually fails if overwrite.cli.url is missing the subdir, but I know that it’s supposed to be there. |
Many thanks, Done! note: the nextcloud install showed no difference in operation regardless of whether the statement was appended or not -- other than the warnings. |
This URL is used by background/cron jobs and |
Fixed in next maintenance releases with |
FYI, the bug is still present in |
The patch didn't make it into 29.0.8 🙈 |
Fixed for Nextcloud 30 (starting with 30.0.1), for 29 the backport is still in review: #47943 |
I still have this issue with 30.0.0. Did I misconfigure something or will it be fixed in 30.0.1? |
Sorry, that was a typo. |
💪💪💪💪💪💪💪💪 |
This fixed it for me as well. Ubuntu 24.04, nginx, php-8.3, NC 29 / 30 Adding the / at the end of the overwrite.cli.url |
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
List of activated Apps
No response
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: