Skip to content

Nextcloud 21 - Web Server is not properly set up to resolve "./well-known/..." #185

New issue
New issue
Closed
Closed
Nextcloud 21 - Web Server is not properly set up to resolve "./well-known/..."#185

Description

@HannesJo0139
HannesJo0139
opened on Feb 23, 2021

linuxserver.io

Nextcloud 21 - Warning:
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.

  • Your web server is not properly set up to resolve "/.well-known/nodeinfo". Further information can be found in the documentation.

Expected Behavior

Nextcloud Security & Setup Warnings should pass all checks.

Current Behavior

Nextcloud Security & Setup Warnings throws a warning that "/.well-known/..." is not solved properly by web server.

Steps to Reproduce

  1. Update Nextcloud instance to v. 21.
  2. Go to Admin -> Settings -> Administration Overview

Steps to Solve the Issue

  1. Edit nginx config file /nginx/site-confs/default
  2. Around line 45, find and delete:
    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/webfinger {
      return 301 $scheme://$host:$server_port/public.php?service=webfinger;
    }
    location = /.well-known/host-meta {
      return 301 $scheme://$host:$server_port/public.php?service=host-meta;
    }
    location = /.well-known/host-meta.json {
      return 301 $scheme://$host:$server_port/public.php?service=host-meta-json;
    }
  1. According to Nextcloud Docs NGINX config, insert the following:
    # Rule borrowed from `.htaccess` to handle Microsoft DAV clients
    location = / {
        if ( $http_user_agent ~ ^DavClnt ) {
            return 302 /remote.php/webdav/$is_args$args;
        }
    }
    # 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;
    }
  1. Save and close file
  2. Restart container

A pull request has been created: #186

Activity

  1. github-actions commented on Feb 23, 2021

    @github-actions
    github-actionsBot
    on Feb 23, 2021

    Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

  2. EVOTk commented on Feb 23, 2021

    @EVOTk
    EVOTk
    on Feb 23, 2021

    It's okay for me ! Thx

  3. aptalca commented on Feb 25, 2021

    @aptalca
    aptalca
    on Feb 25, 2021
    Member

    #188

  4. aptalca
    closed this as completedon Feb 25, 2021

  5. reloxx13 commented on May 23, 2023

    @reloxx13
    reloxx13
    on May 23, 2023

    this does not respect another mapped port in docker eg 8888:80
    mydomain.com:8888/.well-known/carddav will redirect to mydomain.com/remote.php/dav/

    to fix it, u have to use $scheme://$http_host, $http_host will include the port.

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

    this is missing everywhere in the nginx config with redirects.
    i dont use a reverse proxy, someone should test and confirm that this is still working with a reverse proxy.

    @aptalca just closed the other post a few weeks ago, but its not resolved. this is from the latest version (

    docker-nextcloud/root/defaults/nginx/site-confs/default.conf.sample

    Line 95 in 3d3039d

    location = /.well-known/carddav { return 301 /remote.php/dav/; }
    ) and a from a fresh installation.

  6. aptalca commented on May 23, 2023

    @aptalca
    aptalca
    on May 23, 2023
    Member

    this does not respect

    What is this you're referring to? It's a 3 year old issue report. Much has changed in the confs since then

  7. reloxx13 commented on May 23, 2023

    @reloxx13
    reloxx13
    on May 23, 2023

    this does not respect

    What is this you're referring to? It's a 3 year old issue report. Much has changed in the confs since then

    the linked pullrequest #186 , the redirects are still the same in the site conf (i edited my top post).

    i came here after longer researching while the links do not work just like in the other issue which got closed 3 week ago.

  8. j0nnymoe commented on May 23, 2023

    @j0nnymoe
    j0nnymoe
    on May 23, 2023
    Member

    This isn't an issue, many of us run this with this without the error. If you're experiencing this, please open a new issue and provide the requested information.

  9. reloxx13 commented on May 23, 2023

    @reloxx13
    reloxx13
    on May 23, 2023

    of course its an issue if the mapped port is getting lost and this issue and pull request here from years ago caused it, as you can see the port was repected before.
    many are not changing the port and if you use the search function just like me youll find enough issues with it.

    you have all informations you need in this issue here. i dont create duplicate issues.

    ill just ask gpt to fix your bugged file for me and add the scheme and port variables.

  10. djodars89 commented on Sep 11, 2023

    @djodars89
    djodars89
    on Sep 11, 2023

    @reloxx13 was right, this is still an issue (1,2,3) and fixed by adding the missing "$scheme://$http_host" to lines 95, 96 and 103 of the default.conf (3,4,5)

    BEFORE:
    (1)
    image

    (2)
    image

    (3)
    image

    AFTER:
    (4)
    image

    (5)
    image

    (6)
    image

  11. sgtcoder commented on Jan 10, 2024

    @sgtcoder
    sgtcoder
    on Jan 10, 2024

    This modification fixed it for me, it was a bit of changes, but it's working now

        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 https://$http_host/remote.php/dav; }
        location = /.well-known/caldav  { return 301 https://$http_host/remote.php/dav; }

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

        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 https://$http_host/index.php$request_uri;
    }

  12. procoprobocop commented on Apr 25, 2024

    @procoprobocop
    procoprobocop
    on Apr 25, 2024

    Эта модификация исправила это для меня, было немного изменений, но теперь все работает

        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 https://$http_host/remote.php/dav; }
        location = /.well-known/caldav  { return 301 https://$http_host/remote.php/dav; }

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

        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 https://$http_host/index.php$request_uri;
    }

    Thank you very much! Only this could solve my problem!

  13. unknown-error-maker commented on Aug 25, 2025

    @unknown-error-maker
    unknown-error-maker
    on Aug 25, 2025

    adding https://$http_host fixed the problem

  14. unknown-error-maker commented on Aug 25, 2025

    @unknown-error-maker
    unknown-error-maker
    on Aug 25, 2025

    The problem is this:

    curl -i https://my.public.domain/.well-known/webfinger
  ✔  at 07:15:27 PM  
HTTP/2 301 
access-control-allow-headers: authorization,content-type access-control-allow-methods: GET,OPTIONS,PUT access-control-allow-origin: * alt-svc: h3=":443"; ma=2592000 content-type: text/html 
date: Mon, 25 Aug 2025 16:15:28 GMT 
location: http://my.public.domain/index.php/.well-known/webfinger 
referrer-policy: no-referrer 
server: nginx strict-transport-security: max-age=31536000; includeSubDomains; preload x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-permitted-cross-domain-policies: none x-robots-tag: noindex, nofollow x-xss-protection: 1; mode=block 
content-length: 162 
<html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html>

    It redirects to HTTP instead of HTTPS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions