Aparently, you can not just rename the old file, Nextcloud tries to read it anyway, had to also move it up one step in the file structure or delete it. Works now.
Wow there a lot of comments to read through here. I have the webfinger and nodeinfo errors of late. What I’d love to see is a lucid summary of what these things do and what they should do, their purpose not some nginx fix code. What should these URLs produce? For what purpose?
2 Likes
Hi there,
very new to Nextcloud but I seemed to have hit on something with this issue.
running on Apache2 Debian 9 (PHP 7.3) - so a bit different than the original posters setup, but this might give you an idea.
I updated from v15 to v21 and all the while all of the “well-known” errors were visible in the UI. (Cardav, Caldav and the webfinger + nodeinfo as well). In short, I did have a .htaccess file in my document root folder with a lot of rewrites. (I inherited this server, so I don’t know if it was set by the NC installer or someone who knew what he/she was doing.) Despite the redirects set in the file, I got the errors.
There are two funny things to check:
- check if the rewrite module is enabled in apache:
sudo a2enmod rewrite
This said the module was already enabled.
-
in the apache2 config file of the site: /etc/apache2/sites-enabled/name_of_the_site
put in the following just in front of<Virtual host … (for me this is 443, might also be 80)><Directory /var/www/html>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</ Directory>
(take the space out from in front of “directory” - if I wrote it correctly, the line disappeared from the post)
This allows the customized .htaccess files to override the default configuration of Apache. I don’t know about nginx - might be something similar there as well.
After this I restarted apache
service apache2 restart
And the errors were ALL gone. All 4 of them.
I’m not a big linux guru and as I said, I’m a newbie here - so take it as it is, an idea 
I hope it helps someone.
Cheers!
Hi All,
Sorry havn’t been back. I eventually just gave up on the nodeinfo and web finger options, wiped my server and moved back to NC20.09.
I’m not using the social app. Couldn’t get it to install even manually. Even moving back to NC 20 the social app still wouldn’t install. At this point I’m just going to wait until futher updates from 21 are available and the social app install is fixed and then give 21 a try again.
This time around I have installed NC20 as a VM on an ESXi host server so that the next time I’m ready to try and update to 21 I can snap shot first and move back to 20 without the full re-install.
Hi,
thanks you for caring.
Did anything happen on this issue?
I receive the same attention grabbing orange code. I read as much as i could but did not succeed to obtain a green light.
Is there any further development in the making?
Thank you
@Bernd_Wechner I am sure you will love this.
For anybody else beating their heads over this issue:
The issue is caused by that the Nextcloud .well-known checks do not account for relative paths. Yes, a relative path is valid, and will work perfectly well for CardDAV, CalDAV, … The check on the Administration Overview page thinks otherwise, though.
To remove the errors, you can replace the relative paths with absolute paths in your configuration. Look at the following two nginx configuration snippets, which should be easy to adopt to other web server software.
This is a snippet from the original nginx configuration for Nextcloud 21:
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The following 6 rules are borrowed from `.htaccess`
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
}
Make all the redirects absolute URLs (inspired by this page):
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The following 6 rules are borrowed from `.htaccess`
location = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav/; }
location = /.well-known/caldav { return 301 $scheme://$host/remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 $scheme://$host/index.php$uri; }
try_files $uri $uri/ =404;
}
If you use a reverse proxy for TLS offloading, replace $scheme with https!
The result of this is that the “Your web server is not set up correctly to resolve(…)” warnings will be gone.
Consider this a workaround, not a solution. Obviously, the check should be changed so that it also supports relative paths.
3 Likes
Thanks heaps. Alas I tried putting an absolute path there and it still reports the error.
Take note though:
- It reports no error for carddav and caldav only for webfinger and nodeinfo
- It points to a documentation link, but neither is there documented.
- I have them directing to
/public.php?service=webfingerand/public.php?service=nodeinforespectively, but I can’t findpublic.phpnore those two services documented anywhere and if I surf to them I get no response (just a blank page). - The problem, aside from the error message, that remains pertinent is where is this documented, what is it, why does no-one know what it’s about, why is it checked for, what results should webfinger and nodeinfo produce, and why? etc. etc. Questions, questions, questions… I mean I can’t even get any response out of
public.phpand don’t know its API or what it’s for and would love some documentation.
- Can you show me your nginx snippet?
- Nextcloud documentation is often disappointing. This should be fixed as well.
- Nowhere in the documentation I linked does it state that you should do anything with
public.php. See 1. - Based on a known good configuration,
/.well-known/webfinger(which redirects to/index.php/.well-known/webfingerdue to the last catchall nginx redirect rule in my snippet) reponds:{"message":"webfinger not supported"}. This is the correct response for me, since I do not have webfinger enabled. The same is true for nodeinfo:{"message":"nodeinfo not supported"}.
Since you note public.php (which is irrelevant, and probably comes from outdated documentation/configuration examples), your configuration seems flawed. Please try my nginx snippet.
I don’t use nginx ;-). I know it’s the little shining star of web servers out there but for better or for worse because my OpenWRT routers all come with lighttpd bundled and lighttpd is as performant as nginx on fronts (both of which leave apache dead in the water) and unlike nginx is FOSS (so community dependence not vendor dependence is the price which is a matter of taste) I have lighttpd skills not nginx skills.
I can share the config but alas lighttpd is a little niche club methinks and not many use it (as exemplified by endless nginx snippets).
Which is all why I’m not a fan of sharing web server config snippets alone (sure they help for plug and play people) but wish to see them with an explanation of the intended effect (which I can implement in lightttpd).
But for the record here is a lighttpd config snippet:
url.redirect = (
"^/.well-known/carddav$" => "/remote.php/dav",
"^/.well-known/caldav$" => "/remote.php/dav",
"^/.well-known/webfinger$" => "/public.php?service=webfinger",
"^/.well-known/nodeinfo$" => "/public.php?service=nodeinfo"
)
But yes, I was experimenting with this because of 1337omega’s claim to success here:
I haven’t implemented webfinger or nodeinfo explicitly either, in fact know nothing about them, only found these error messages on the settings overview after a Nextcloud upgrade. Wishing indeed, to know why Nextcloud reports:
With no supporting documentation that explains what webfinger and nodeinfo are , why it wants them and how we can provide them if necessary to suppress the message if it’s not.
The success of 1337omega is due to this:
location = /.well-known/webfinger {
return 301 /index.php$uri;
}
(...)
location ^~ /.well-known {
return 301 /index.php$uri;
The public.php stuff does nothing.
Converting my nginx snippets to lighttpd snippets is trivial. All you need are the correct absolute destination redirect URLs. For example (requiring lighttpd 1.4.50+):
url.redirect = (
"^/.well-known/carddav$" => "${url.scheme}://${url.authority}/remote.php/dav",
"^/.well-known/caldav$" => "${url.scheme}://${url.authority}/remote.php/dav",
"^/.well-known/webfinger$" => "${url.scheme}://${url.authority}/index.php${url.path}${qsa}",
"^/.well-known/nodeinfo$" => "${url.scheme}://${url.authority}/index.php${url.path}${qsa}"
)
Again, if you offload TLS, you should replace ${url.scheme} with https. If you use an older lighttpd version, see this for inspiration.
You will not find much documentation or support only Apache is supported and NGINX is tolerated. I do not care about webfinger or nodeinfo. They are apparently disabled by default/on my server anyway, and all I am interested in is getting rid of the errors (which I did, and so can you).
Yes, likewise I don’t care one jot about webfinger and nodeinfo, I just want to understand why Nextcloud complains about them, and how to get rid of the complaint of if they happen to be needed (why else complain about it) to enable them.
I’m not familiar with nginx syntax so not sure how to read $uri. And while I am quite familiar with lighttpd (managing it for some years now on numerous servers) I remain frustrated by it’s lack of documentation on the ${} parameters available in substitutions.
Oddly this snippet works. It gets rid of the errors reported but implements nothing (i.e. redirects to URLs that return 404). I tried earlier with redirects hardcoding the target URL, eg:
"^/.well-known/webfinger$" => "https://mydomain/index.php/webfinger",
And don’t recall finding joy. There are two possible reasons for this (I’ve not diagnosed yet):
-
I didn’t actually test the Nextcloud page. Because I did numerous cycles of testing just testing the URLs to see what I got and interpreted a 404 as fail. But today you have provided me with empirical evidence that a redirect to a URL that returns 404 works nonetheless in ridding us of this error message.
-
It could also be that this redirect does not present the qsa (untested) and that the test that Nextcloud performs is with a query string. This dubious and I suspect reason 1. is at play, mainly because it’s a 404 one way or the other.
I remain further frustrated that no-one seems to know or be willing to report, WTF this is all about? Why does Nextcloud suddenly want webfinger and nodeinfo? And why is it content simply to with a 404 returned?
With the slight possibility existing that the tester provides a query string that turns this into a non 404 result I checked the lighttpd logs will reloading that page and nope:
192.168.0.11 mydomain - [31/May/2021:22:26:35 +1000] "GET /.well-known/webfinger HTTP/1.1" 301 0 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0"
192.168.0.11 mydomain - [31/May/2021:22:26:35 +1000] "GET /.well-known/nodeinfo HTTP/1.1" 301 0 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0"
192.168.0.11 mydomain - [31/May/2021:22:26:36 +1000] "GET /index.php/.well-known/webfinger HTTP/1.1" 404 37 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0"
192.168.0.11 mydomain - [31/May/2021:22:26:36 +1000] "GET /index.php/.well-known/nodeinfo HTTP/1.1" 404 36 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0"
It seems completely content to receive a 404 or maybe it’s the 301 it wants? Aaargh the ridiculous mystery. You’d think at Nextcloud central given the number of admins scratching their heads about these mysterious new messages after an upgrade, there’d be some priority to fixing it or documenting what is up.
As a Nextcloud user without a support contract, I search for information I need myself. That is how I learned about this topic, and how I came up with a solution. This keeps me from becoming frustrated due to a product I use freely, and for which nobody owes me anything.
Searching also brought me to a GitHub discussion, that explains that nodeinfo and webfinger are used or will be used by Nextcloud Social. Nextcloud Social is optional, but whether a Nextcloud instance supports it or not can be made publicly ‘well known’ using the correct options.
My tip:
Instead of venting on a forum, learn to search for yourself. All information is out there, as I have shown multiple times. If you do not like Nextcloud, you are welcome to contribute to it so that one day you might like it, and you are welcome to not use it at all.
Same .well-known problem in my setup. Using apache httpd, I got rid of those annoying messages by redirecting matching URLS to a location returning a 2XX status and adding an header. I prefer to configure things server side, avoiding .htaccess manipulation, so this is my suggestion:
RewriteRule ^/.well-known/caldav https://%{HTTP_HOST}/remote.php/dav/ [R=301,L]
RewriteRule ^/.well-known/carddav https://%{HTTP_HOST}/remote.php/dav/ [R=301,L]
RewriteRule ^/.well-known/(.+)$ https://%{HTTP_HOST}/apps/files [P,L]
<Location /.well-known/>
Header always set X-NEXTCLOUD-WELL-KNOWN 1
Porting it to nginx should be straightforward.
Just in case anyone else is still using apache. This .htaccess fixed the issue for me:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^\.well-known/carddav /owncloud/remote.php/dav [R=301,L]
RewriteRule ^\.well-known/caldav /owncloud/remote.php/dav [R=301,L]
RewriteRule ^\.well-known/nodeinfo /owncloud/index.php/.well-known/nodeinfo [R=301,L]
RewriteRule ^\.well-known/webfinger /owncloud/index.php/.well-known/webfinger [R=301,L]
</IfModule>
maybe this should be added to the documentation page that is mentioned in the error message?
NB: nextcloud is installed in the directory /owncloud/ on my system. Remove (or replace) /owncloud if you have nextcloud in the main directory (or in another subdirectory).
A few items that frustrated me with this issue…
1.) The browser caches redirects. So when you test post changes to proxy server, you have to clear cache or go into incognito / private browsing mode.
2.) index.php/.well-known/webfinger returns nothing (404) when manually entering the URL in the browser. So even if you get the nginix / apache config to correctly redirect, it will only work if the index.php knows how to manage the URI. In this case I am not sure index.php/.well-known/webfinger is the correct redirect path.
3.) Its unclear to my why the dashboard tool even checks for a .well-know/webfinger unless its just a general check based on this specification ForgeRock Access Management 7.0.2 > OpenID Connect 1.0 Guide > /.well-known/webfinger
4.) nodeinfo is in the same boat as above. Why check, redirect, etc…
My Config… I just redirect it to the index.php (unit I know the proper place) and it still fails the Overview security and setup warnings…
location ^~ /.well-known {
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location = /.well-known/webfinger { return 301 /index.php; }
location = /.well-known/nodeinfo { return 301 /index.php; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
}
In the end, I removed the warning message by removing or commenting out the following in my nextcloud nginix config…
#error_page 403 /core/templates/403.php;
#error_page 404 /core/templates/404.php;
but I am not sure if that is a good idea… the 404.php code and 403.php code had some redirects in the that might be important…
Can Nextcloud or the Social app update their documentation please?
This worked for me, and only commenting error page config of 404 will be OK because by doing this the /index.php/.well-known/webfinger could return a JSON but not 404.
I tried a lot but could not get it right until I checked the page in an incognito window in my Chrome-browser. Et voila no errror. I cleared the browsers memory cache (ctrl+F5) and now I had no errors also in ordinary browser window.
2 Likes
If you encounter just Webfinger to be unknown/not set properly, it might be that you just installed Social beta 0.6 which has an issue there – took me a while searching for the general issue with .well-known until I noticed "Exception": "OCA\\**Social**\\… in the log:
{
"reqId": "B7mbg4cEvTPFnBY1e4LL",
"level": 3,
"time": "2023-02-03T18:22:00+01:00",
"remoteAddr": "78.94.68.73",
"user": "nursoda.admin",
"app": "index",
"method": "GET",
"url": "/index.php/.well-known/webfinger",
"message": "Actor not found",
"userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/109.0",
"version": "25.0.3.2",
"exception": {
"Exception": "OCA\\Social\\Exceptions\\ActorDoesNotExistException",
"Message": "Actor not found",
"Code": 0,
…