Warning "/.well-known/webfinger" "/.well-known/nodeinfo" "/.well-known/caldav" "/.well-known/carddav"

Support intro

Sorry to hear you’re facing problems :slightly_frowning_face:

help.nextcloud.com is for home/non-enterprise users. If you’re running a business, paid support can be accessed via portal.nextcloud.com where we can ensure your business keeps running smoothly.

In order to help you as quickly as possible, before clicking Create Topic please provide as much of the below as you can. Feel free to use a pastebin service for logs, otherwise either indent short log examples with four spaces:

example

Or for longer, use three backticks above and below the code snippet:

longer
example
here

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can :heart:

Nextcloud version (eg, 20.0.5): 21.0.7
Operating system and version (eg, Ubuntu 20.04): Alpine Linux
Apache or nginx version (eg, Apache 2.4.25): Nginx 1.20.2
PHP version (eg, 7.4): 8.0.14

The issue you are facing:
I have successfully patched from Nextcloud 17 to Nextcloud 21.0.7.
In the administration page I find this security warning:

* 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).
* Your web server is not properly set up to resolve "/.well-known/caldav". 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/carddav". Further information can be found in the [documentation](https://docs.nextcloud.com/server/21/go.php?to=admin-setup-well-known-URL).

This server is running behind a forward proxy; I don’t know if this is related to the issue.

Is this the first time you’ve seen this error? (Y/N):
No

Steps to replicate it:

  1. Settings
  2. Administration > Overview

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'passwordsalt' => '<passwordsalt>,
  'secret' => '<secret>',
  'trusted_domains' => 
  array (
    0 => '<cloud.mydomain.com>',
  ),
  'apps_paths' => 
  array (
    0 => 
    array (
      'path' => '/var/www/nextcloud/apps',
      'url' => '/apps',
      'writable' => true,
    ),
  ),
  'datadirectory' => '/var/lib/nextcloud/data',
  'skeletondirectory' => '/var/lib/nextcloud/default_files',
  'logfile' => '/var/log/nextcloud/nextcloud.log',
  'loglevel' => 2,
  'logtimezone' => 'Europe/Berlin',
  'knowledgebaseenabled' => true,
  'check_for_working_htaccess' => false,
  'dbtype' => 'mysql',
  'version' => '21.0.7.0',
  'overwrite.cli.url' => 'https://<cloud.mydomain.com>',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'nc',
  'dbpassword' => '<dbpassword>',
  'installed' => true,
  'integrity.check.disabled' => false,
  'default_phone_region' => 'DE',
  'instanceid' => 'ochentz7kvhd',
  'maintenance' => false,
  'filelocking.enabled' => 'true',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => '/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0.0,
  ),
  'theme' => '',
  'twofactor_enforced' => 'true',
  'twofactor_enforced_groups' => 
  array (
  ),
  'twofactor_enforced_excluded_groups' => 
  array (
  ),
  'app_install_overwrite' => 
  array (
    0 => 'files_texteditor',
  ),
  'encryption.legacy_format_support' => false,
  'updater.secret' => '<updater.secret>',
);

The output of your Apache/nginx/system log in /var/log/____:

2021/12/26 20:10:37 [error] 657#657: *11 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "GET /status.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"
2021/12/26 20:10:37 [error] 657#657: *13 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "GET /nextcloud/status.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"
2021/12/26 20:11:39 [error] 657#657: *15 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "GET /status.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"
2021/12/26 20:11:39 [error] 657#657: *17 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "GET /nextcloud/status.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"
2021/12/26 20:12:41 [error] 657#657: *19 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "GET /status.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"

2021/12/26 20:12:41 [error] 657#657: *21 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "GET /nextcloud/status.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"
2021/12/26 20:12:44 [error] 657#657: *23 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "PROPFIND /remote.php/dav/calendars/user/personal_shared_by_thomas/ HTTP/1.1", upstream: "fastcgi://
127.0.0.1:9000", host: "cloud.mydomain.com"
2021/12/26 20:12:44 [error] 657#657: *25 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.10
0, server: cloud.mydomain.com, request: "PROPFIND /remote.php/dav/calendars/user/personal/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", 
host: "cloud.mydomain.com"
2021/12/26 20:22:46 [error] 643#643: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.100, server: cloud.mydomain.com, request: "GET /settings/admin HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"
2021/12/26 20:22:47 [error] 643#643: *3 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.100, server: cloud.mydomain.com, request: "PROPFIND /remote.php/dav/files/name/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "cloud.mydomain.com"

Fix your Nginx configuration. Details: https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html

Specifically:

    # 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 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;
    }

I know the Nginx config changed (I think with 21), so it might be worth checking over the rest of the example config.

Actually I have just copy & pasted this NGINX config.

What happens when you try to navigate to one of those URLs? What type of status code do you get?

Might be worth looking at the Nginx logs to see what it thinks, too.

Would Nginx factor in for a Docker installation? Looked at these issues trying to fix another issue, hoping it’s possibly related.

Is your nextloud running in the root? Or in a subfolder? Could you post your nginx config?

I will be redirected to /remote.php/dav/.

And there’s no issue with this because I can use DAVx5 for contact- and calendar-synchronisation w/o issues.

I’m running nextcloud in root.
Here’s my nginx-config:

upstream php-handler {
    server 127.0.0.1:9000;
    #server unix:/var/run/php/php7.4-fpm.sock;
}

server {
    listen 80;
    listen [::]:80;
    server_name cloud.mydomain.com;
#    # enforce https
#    return 301 https://$server_name$request_uri;
#}
#
#server {
#    listen 443 ssl http2;
#    listen [::]:443 ssl http2;
#    server_name cloud.mydomain.com;
#
#    # Use Mozilla's guidelines for SSL/TLS settings
#    # https://mozilla.github.io/server-side-tls/ssl-config-generator/
#    # NOTE: some settings below might be redundant
#    ssl_certificate /etc/ssl/nginx/cloud.mydomain.com;
#    ssl_certificate_key /etc/ssl/nginx/cloud.mydomain.com;

    # HSTS settings
    # WARNING: Only add the preload option once you read about
    # the consequences in https://hstspreload.org/. This option
    # will add the domain to a hardcoded list that is shipped
    # in all major browsers and getting removed from this list
    # could take several months.
    #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;

    # set max upload size
    client_max_body_size 512M;
    fastcgi_buffers 64 4K;

    # Enable gzip but do not remove ETag headers
    gzip on;
    gzip_vary on;
    gzip_comp_level 4;
    gzip_min_length 256;
    gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
    gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.ge
o+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp im
age/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

    # Pagespeed is not supported by Nextcloud, so if your server is built
    # with the `ngx_pagespeed` module, uncomment this line to disable it.
    #pagespeed off;

    # HTTP response headers borrowed from Nextcloud `.htaccess`
    add_header Referrer-Policy                      "no-referrer"   always;
    add_header X-Content-Type-Options               "nosniff"       always;
    add_header X-Download-Options                   "noopen"        always;
    add_header X-Frame-Options                      "SAMEORIGIN"    always;
    add_header X-Permitted-Cross-Domain-Policies    "none"          always;
    add_header X-Robots-Tag                         "none"          always;
    add_header X-XSS-Protection                     "1; mode=block" always;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;

    # Path to the root of your installation
    root /var/www/nextcloud;

    # Specify how to handle directories -- specifying `/index.php$request_uri`
    # here as the fallback means that Nginx always exhibits the desired behaviour
    # when a client requests a path that corresponds to a directory that exists
    # on the server. In particular, if that directory contains an index.php file,
    # that file is correctly served; if it doesn't, then the request is passed to
    # the front-end controller. This consistent behaviour means that we don't need
    # to specify custom rules for certain paths (e.g. images and other assets,
    # `/updater`, `/ocm-provider`, `/ocs-provider`), and thus
    # `try_files $uri $uri/ /index.php$request_uri`
    # always provides the desired behaviour.
    index index.php index.html /index.php$request_uri;

    # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
    location = / {
        if ( $http_user_agent ~ ^DavClnt ) {
            return 302 /remote.php/webdav/$is_args$args;
        }
    }

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    # 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 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;
    }

    # Rules borrowed from `.htaccess` to hide certain paths from clients
    location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/)  { return 404; }
    location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console)                { return 404; }

    # Ensure this block, which passes PHP files to the PHP process, is above the blocks
    # which handle static assets (as seen below). If this block is not declared first,
    # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
    # to the URI, resulting in a HTTP 500 error response.
    location ~ \.php(?:$|/) {
        # Required for legacy support
        rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|oc[ms]-provider\/.+|.+\/richdocumentscode\/proxy) /index.php$requ
est_uri;

        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        set $path_info $fastcgi_path_info;

        try_files $fastcgi_script_name =404;

        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $path_info;
        fastcgi_param HTTPS on;
        fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
        fastcgi_param front_controller_active true;     # Enable pretty urls
        fastcgi_pass php-handler;

        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
    }

    location ~ \.(?:css|js|svg|gif)$ {
        try_files $uri /index.php$request_uri;
        expires 6M;         # Cache-Control policy borrowed from `.htaccess`
        access_log off;     # Optional: Don't log access to assets
    }

    location ~ \.woff2?$ {
        try_files $uri /index.php$request_uri;
        expires 7d;         # Cache-Control policy borrowed from `.htaccess`
        access_log off;     # Optional: Don't log access to assets
    }

    # Rule borrowed from `.htaccess`
    location /remote {
        return 301 /remote.php$request_uri;
    }

    location / {
        try_files $uri $uri/ /index.php$request_uri;
    }
}

I don’t think this is a configuration issue with Nginx or Nextcloud in general.

The warning in Nextcloud is pointing to some resolving issues, and I think this is related to the setup Nextcloud server is running behind a forward proxy (HAproxy).