Your web server is not properly set up to resolve "/.well-known/webfinger".

[stavros-k]

Continuing from #185, the #188 PR has fixed the warning about nodeinfo but not webfinger.

---

Expected Behavior

Checks pass all tests

Current Behavior

Checks return warning
Your web server is not properly set up to resolve "/.well-known/webfinger".

Steps to Reproduce

1. Updated nextcloud docker
2. Deleted /config/nginx/site-confs/default
3. Restarted container
4. Warnings still present.

Environment

OS: Unraid 6.9.0 rc2
CPU architecture: x86_64
How docker service was installed: Installed from Community apps

Command used to create docker container (run/create/compose/screenshot)

Docker logs

[j0nnymoe]

Could you do a couple things please:

1. Post output of: docker inspect -f '{{ index .Config.Labels "build_version" }}' nextcloud
2. delete the default file again from your nextcloud appdata
3. post the contents of the new default file once you've restarted the container.

[aptalca]

Can't reproduce. Works fine here.

$ docker run -d --rm --name test -p 443:443 ghcr.io/linuxserver/nextcloud
Unable to find image 'ghcr.io/linuxserver/nextcloud:latest' locally
latest: Pulling from linuxserver/nextcloud
26d217c1d6b6: Already exists 
b3b5aff7a1c9: Already exists 
605e5412b5b9: Already exists 
10e194571c25: Already exists 
6855c87954e9: Already exists 
d6a6d9a9c2d6: Already exists 
a1fc532bec49: Already exists 
dcd99db6a9f2: Already exists 
6ede6d2a0a13: Pull complete 
a45c62f481a7: Pull complete 
Digest: sha256:87f0dafd864c3c2b8da827b1efbac880df61bafdaa3863729d18acdc6881e3da
Status: Downloaded newer image for ghcr.io/linuxserver/nextcloud:latest
c98fc6259be532defced5e090eb7d206ed18e1a3f1c96f539caf7c5b98f1edce

Browse to https://192.168.X.X

[stavros-k]

1. docker inspect -f '{{ index .Config.Labels "build_version" }}' nextcloud

Linuxserver.io version:- 21.0.0-ls124 Build-date:- 2021-02-25T19:56:09+00:00

3. post the contents of the new default file once you've restarted the container.

upstream php-handler {
    server 127.0.0.1:9000;
}
server {
    listen 80;
    listen [::]:80;
    server_name _;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name _;
    ssl_certificate /config/keys/cert.crt;
    ssl_certificate_key /config/keys/cert.key;

    # Add headers to serve security related headers
    # Before enabling Strict-Transport-Security headers please read into this
    # topic first.
    #add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" always;
    #
    # 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.

    # 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.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/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;

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

    root /config/www/nextcloud/;

    # display real ip in nginx logs when connected through reverse proxy via docker network
    set_real_ip_from 172.0.0.0/8;
    real_ip_header X-Forwarded-For;

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

    # 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(?:$|/) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        set $path_info $fastcgi_path_info;

        try_files $fastcgi_script_name =404;

        include /etc/nginx/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
    }

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

}

[stavros-k]

Tried from another device (mobile) and from pc (incognito) and the checks pass.

Tried to clean storage from F12 > Application > Storage > Clear site data. Also ipconfig /flushdns
on the pc i get the warning , but the warning remains. On the same machine incognito passes test.
At this point i don't think it has something to do with the site-confs.
Any idea what else i should clean and try again?

Also tried disabling all extensions
On browser i get those 2 errors

It says 404 on both nodeinfo and webfinger, but warning only for webfinger

On incognito i get the same errors but checks pass.

[stavros-k]

On Chrome test.domain.me/.well-known/webfinger redirects to https://test.domain.me/public.php?service=webfinger
On Incognito test.domain.me/.well-known/webfinger redirects to https://test.stavrosk.me/index.php/.well-known/webfinger

One redirects to public.php and the other to index.php

[aptalca]

redirects are 301 (permanent), which are cached by the browser. You need to clear your browser cache for it to redirect to the new urls that nextcloud v21 expects to see

[stavros-k]

redirects are 301 (permanent), which are cached by the browser. You need to clear your browser cache for it to redirect to the new urls that nextcloud v21 expects to see

I had tried cleaning everything from cache to storage for this domain, even cleaned windows dns and firewalls dns.
but the only thing that worked was
Open Dev Tools (F12), and while this is open right click on refresh button and select Empty cache and hard reload.
This worked.
Leaving it here, in case someone have the same problem.

Thanks for your time.

[edrohler]

Clearing the cache doesn't work for all scenarios and this should be re-opened and investigated more thoroughly. For example, I am using the swag container as a reverse proxy to my nextcloud container and this still happens. It happens even if I change the nextcloud configuration like here

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

[tobbenb]

Are you using subfolder? Then that's the reason.

[edrohler]

I am not using subfolder. That is why it needs to be investigated more thoroughly.

[tobbenb]

We don't see the issue when setting up a new container and all of our existing ones updated to latest doesn't have it either. So it's hard to troubleshoot more when we don't have the issue.

[edrohler]

Dang it. My apologies, I missed this thread

For anyone still having issues, change the default nginx config for the container if you've been using the same container for a long time.

[tobbenb]

Lol. It's even in this issue.

[edrohler]

Ya, maybe you should make it more clear or perhaps create some documentation for changing the configuration. LOL

[aptalca]

I honestly don't know how to make it any clearer? https://github.com/linuxserver/docker-nextcloud#versions

It says:

25.02.21: - Nginx default site config updated for v21 (existing users should delete /config/nginx/site-confs/default and restart the container).

[edrohler]

Ah, I see. You would expect me to go searching all over the repo for the answer and skip the issue all together. Great. But I don't understand how you can't see that as unclear. In this case, viewing an issue with many comments is not practical BECAUSE it leaves the read to miss things.

To make it more clear, once a workaround for the issue is discovered it should be linked in the initial issue. This keeps a person researching the error from having to sift through a bunch of investigative posts. Because, the thread that updates the config looks like someone providing the configuration for investigation. I believe it is common practice to update the initial issue with the workaround if one is found too.

Additionally, I apologized for my mistake in assuming that the configuration followed the application's direct documentation. It would make it more helpful for people asking for clarity to not reply with with LOL's and sarcastic assumptions. Instead, reply with a direct link to the release notes that articulate this information.

Wouldn't you agree?

[stavros-k]

Well, before you update ANY software, you should read the changelog. If you didn't and this caused problems, it's not developers fault, it's the administrator that did the update.

The changelog was there BEFORE the release. So, no it's not a workaround it's an info provided along with the release.

And no, they can't just put a script to delete the old config and replace with the new. Some people have custom configs in there.

Just a friendly reminder to read changes before updating something :)

PS. I have nothing to do with the LSIO team.

[edrohler]

That's not at all what I was expecting. I would never expect them to create a script to delete the old config in a docker environment. Docker environments are supposed to be immutable and since the updates happen outside of the docker environment I assumed that the container just used the default configuration.

However, I was asked how to make it more clear. In my opinion, to make it more clear, elaborate the fix in the original issue thread. That's all I am saying. Arguing about who is at fault or responsible is not what I am talking about. I already apologized and assumed partial responsibility for not reading the whole thread.

Don't get me wrong. I understand that open source is hard and I am not expecting that everything be handed to us. I am just saying that it could have been documented better. Accept the feedback or don't and make adjustments or don't. Simple as that.

In either case, next time I update your containers, I will make sure to do it very cautiously.

[stavros-k]

your containers,

Just to avoid any misunderstandings.
I have nothing to do with the creation of LSIO's container :) I'm just another consumer of this image.

[Loader23]

Are you using subfolder? Then that's the reason.

@tobbenb: Iam using SWAG + NC subfolder and I still have this problem. Deleted the configs and also tested with a PC that never opened nextcloud before. So is this error normal with subfolder and is there a way to fix it?

[tobbenb]

You have to edit the proxy conf and add the fixes from the subdomain conf. I'll see if I find the fix I posted on Discord.

[tobbenb]

Found it.

Can you try to replace the below in your nextcloud.subfolder.conf

# Redirects for DAV clients
location = /.well-known/carddav {
    return 301 $scheme://$host/nextcloud/remote.php/dav;
}

location = /.well-known/caldav {
    return 301 $scheme://$host/nextcloud/remote.php/dav;
}

location /nextcloud {
    return 301 $scheme://$host/nextcloud/;
}

Change it to:

location ^~ /.well-known {
        # The rules in this block are an adaptation of the rules
        # in the Nextcloud `.htaccess` that concern `/.well-known`.

        location = /.well-known/carddav { return 301 /nextcloud/remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /nextcloud/remote.php/dav/; }

        # Let Nextcloud's API for `/.well-known` URIs handle all other
        # requests by passing them to the front-end controller.
        return 301 /nextcloud/index.php$request_uri;
    }

[Loader23]

Yes, its working now, thanks alot :-)

[tobbenb]

I'll update the subfolder conf then.

[realies]

Bump

[CanonCan]

Hey everyone came across this post which clears up subfolder use...what about subdomain?

I am using Nginx Proxy Manager

when i added the following to my custom nginxconfig

location ^~ /.well-known {
        # The rules in this block are an adaptation of the rules
        # in the Nextcloud .htaccess that concern /.well-known.

        location = /.well-known/carddav { return 301 /nextcloud/remote.php/dav/; }
        location = /.well-known/caldav  { return 301 /nextcloud/remote.php/dav/; }

        # Let Nextcloud's API for `/.well-known` URIs handle all other
        # requests by passing them to the front-end controller.
        return 301 /nextcloud/index.php$request_uri;
    }

i get more warnings than just the webfinger and nodeinfo b ut also for the carddev and caldev

When i rename the default.conf file in /appdata/nextcloud/nginx/site-confs/ the site becomes no longer available

I am using HSTS and all the security trimming that are free at Cloudflare

anyone got a fix while using Cloudflare proxied DNS CNAMES and a subfolder with nginx proxy manager

[CanonCan]

found a fix here

added

location = /.well-known/host-meta {
return 301 $scheme://$http_hostpublic.php?service=host-meta;
}

location = /.well-known/host-meta.json {
return 301 $scheme://$http_host/public.php?service=host-meta-json;
}

location = /.well-known/carddav {
return 301 $scheme://$http_host/remote.php/dav;
}

location = /.well-known/caldav {
return 301 $scheme://$http_host/remote.php/dav;
}

location = /.well-known/webfinger{
return 301 $scheme://$http_host/index.php/.well-known/webfinger;
}

location = /.well-known/nodeinfo{
return 301 $scheme://$http_host/index.php/.well-known/nodeinfo;
}

all to my NPM custom config and did a force refresh in chrome with crtl reload button and all checks pass now

[monochromec]

Unfortunately none of the above fixes this in NC version 25.0.6. nginx version is 1.18, php-fpm is 7.4.
It seems that the nginx location directive
location = /.well-known/webfinger { return 301 /nextcloud/index.php$request_uri; }
resulting in curl https://host/nextcloud/index.php/.well-known/webfinger gives a 404:

<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

A similar setup with Apache using
Redirect 301 /.well-known/webfinger /nextcloud/index.php/.well-known/webfinger
works as expected.

Please let me know if more information is required.

[aptalca]

This is a 2 year old post. The webfinger stuff went through so many iterations during that time. The setting in the nextcloud image's default site conf is correct and is sufficient.

You don't have to change anything manually. Just make sure NC is using the latest site conf. Check the container log to see if that's the case.

You can open a new issue or visit our discord if you're still having issues.

Locking this issue