Since updating to 21 or a major issue, I created the following message:
Your web server is not set up correctly to resolve “/.well-known/webfinger”. See the documentation for more information.
*Your web server is not set up correctly to resolve “/.well-known/nodeinfo”. See the documentation for more information.
I am using PHP7.4 andNginx1.14.2 , How can i solve this problem?
# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
# The following rule is only needed for the Social app.
# Uncomment it if you're planning to use this app.
rewrite ^/.well-known/webfinger /public.php?service=webfinger last;
location = /.well-known/webfinger {
return 301 /index.php$uri;
}
location = /.well-known/carddav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
location ^~ /.well-known {
return 301 /index.php$uri;
}
I’m guessing this is because I don’t have the Social app installed. I tried installing it to test that theory, but on installation I get the error:
Could not extract app social: Out-of-path file extraction {/tmp/oc_tmp_8F8hWu-folder/social/vendor/bin/parallel-lint --> ../jakub-onderka/php-parallel-lint/parallel-lint}
If the warnings are really because Social isn’t installed, then this is a bug in the setup warnings as it shouldn’t be testing for the behavior of an app that isn’t installed (or required).
I have this exact same issue. I updated to 21 three days in order to resolve some other issues which are in fact no resolved, however i now get server not setup properly for webfinger and node info. I do not have the social app installed and also received an error when trying to install it. I have modified .htaccess like i did for cal and card dav to no avail, Im nit running nginx, but running apache. Since this update and errors appeared i have also noticed a considerable slow dow on web access through chrome browser but not so much on firefox. I have been scowering threads for days trying to find help or an answer to this issue and have not found one yet.
Once you set up your NC, I assume you took the above referenced config and adopted it to your needs. So did I. I also tried to modify my proven site definition but it turned out it was easier to just take the latest reference config and adopt it again since. That solved the above issue. This is due to the fact that order DOES matter in this file – and it changed quite a lot…
Been running NC since v13 on Ubuntu 16 with Apache not Ngnx. First issue was the caldav and cardav wich was resolved with .htaccess file. Update to Ubuntu 20 when update to NC 20 with no issues. Now still running Ubuntu 20 but after update to NC 21 now get the .well-known/webfinger or .well-known/nodeinfo error and web access super slow but app access is not. Currently still on PHP7.4 not 8. MySQL is on v8.
Its is difficult to adopt the above config as it is for NGNX. However I have tried multiple versions of the redirects in my .htaccess file with luck. Trying to figure out what I’m missing … I’m not sure if its an order thing, or if there is something I’m missing in my .htaccess file. Apache config is very basic with a virtual host and still set up per NC docs.
Here is my .htaccess file:
SetEnvIfNoCase ^Authorization$ “(.+)” XAUTHORIZATION=$1
RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
Header always set Strict-Transport-Security “max-age=15552000; includeSubDomains”
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
SSLEngine on
SSLCertificateFile /location of file
SSLCertificateKeyFile /location of file
Include /location of file
<FilesMatch “.(cgi|shtml|phtml|php)$”>
SSLOptions +StdEnvVars
I have resolved the web access speed issues so that is no longer an issue. However still getting the following erros … Anyone have any luck getting this resolved yet??
Your web server is not properly set up to resolve “/.well-known/webfinger”. Further information can be found in the documentation.
Your web server is not properly set up to resolve “/.well-known/nodeinfo”. Further information can be found in the documentation.
Having the same issue, even with the relevant configurations set up. I am not using the social app which is probably the reason I get {"message":"webfinger not supported"} when trying to access https://cloud.mydomain.com/index.php/.well-known/webfinger. Not sure if this is inteded or a bug, but if it is intended (since I’m not using the social app) it should not add a warning in the admin panel.
There are some warnings regarding your setup.
* Your web server is not properly set up to resolve "/.well-known/webfinger". Further information can be found in the [documentation](https://docs.nextcloud.com/server/21/go.php?to=admin-setup-well-known-URL).
* Your web server is not properly set up to resolve "/.well-known/nodeinfo". Further information can be found in the [documentation](https://docs.nextcloud.com/server/21/go.php?to=admin-setup-well-known-URL).
I am not using the social app. I am using the linuxserver/nextcloud docker container. And this started when I upgraded from 20.0.8 (no warnings reported) to 21.0.1. And I have no entries in my .htaccess regarding nodeinfo or webfinger. (I did try to add “RewriteRule ^.well-known/webfinger /public.php?service=webfinger [QSA,L]” but that did no good and removed it.)
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 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }
# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /index.php$request_uri;
}
And one more update, if you DELETE the default site conf and then recreate the container, it will give you a new default site conf that seems to have the updated well-known criteria. I don’t believe I had done any customization to the default site conf in my setup, so this works for me. ymmv.
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?
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.