Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: NC29 .well-known URLs, failed on: /.well-known/caldav #45033

Closed
5 of 8 tasks
cvandesande opened this issue Apr 25, 2024 · 101 comments · Fixed by #46079, #46255, #47943 or #47883
Closed
5 of 8 tasks

[Bug]: NC29 .well-known URLs, failed on: /.well-known/caldav #45033

cvandesande opened this issue Apr 25, 2024 · 101 comments · Fixed by #46079, #46255, #47943 or #47883
Labels
4. to release Ready to be released and/or waiting for tests to finish 29-feedback bug feature: settings

Comments

@cvandesande
Copy link

⚠️ This issue respects the following points: ⚠️

Bug description

With NC28 I had no well-known URL errors, and no change to the NGINX configuration. After upgrading to NC29, I now have the following message:
Your web server is not properly set up to resolve .well-known URLs, failed on: /.well-known/caldav For more details see the [documentation ↗](https://docs.nextcloud.com/server/29/go.php?to=admin-setup-well-known-URL).

In the NGINX logs, I see a 401 errors:

192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "PROPFIND /.well-known/caldav HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler"
192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "GET /remote.php/dav HTTP/1.1" 401 569 "-" "Nextcloud Server Crawler"
192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "GET /.well-known/caldav HTTP/1.1" 301 162 "-" "Nextcloud Server Crawler"
192.168.9.6 - - [25/Apr/2024:13:02:21 +0000] "GET /remote.php/dav HTTP/1.1" 401 569 "-" "Nextcloud Server Crawler"

My Android DAVx5 client doesn't seem to have any issues and continues to work well.

A curl test, shows the 301 redirect working, followed by a 401, but I'm assume that's expected with an unauthenticated request

curl -IL https://nextcloud.mydomain.com/.well-known/caldav

HTTP/2 301 
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:12:51 GMT
content-type: text/html
content-length: 162
location: https://nextcloud.mydomain.com/remote.php/dav
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;

HTTP/2 401 
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:12:51 GMT
content-type: application/xml; charset=utf-8
set-cookie: oc_sessionPassphrase=NoBfvCYLv%2B7Hzw7eRoiL4VWZNyADXzcx2k5fgbu4FerYYBJjgl%2Fq8xLrTWscFxu3ithDlInkdabcfGg0nbL0wrG3B%2BPRkOCYjtibS4QvsluoWlkgrT5DdSWiQGUwHxi9; path=/; secure; HttpOnly; SameSite=Lax
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
set-cookie: oc2a3d1f7bcc=6eadda8dbfe0995012c16997240ee6b0; path=/; secure; HttpOnly; SameSite=Lax
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
content-security-policy: default-src 'none';
www-authenticate: Basic realm="MyDomain, charset="UTF-8"
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;

There is an error in Nextcloud.log that appears relevant:

    "File": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php",
    "Line": 152,
    "message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured"

Steps to reproduce

  1. Upgrade from NC28 to NC29
  2. well-known message in admin settings

Expected behavior

No well-known errors

Installation method

Community Manual installation with Archive

Nextcloud Server version

29

Operating system

Other

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

PostgreSQL

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 22 to 23)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

  • Default user-backend (database)
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "nextcloud.mydomain.com",
            "nextcloud"
        ],
        "apps_paths": [
            {
                "path": "\/usr\/share\/nginx\/html\/nextcloud\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/usr\/share\/nginx\/html\/nextcloud\/custom-apps",
                "url": "\/custom-apps",
                "writable": true
            }
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "pgsql",
        "version": "29.0.0.19",
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "forwarded_for_headers": [
            "HTTP_X_FORWARDED_FOR",
            "HTTP_X_FORWARDED",
            "HTTP_FORWARDED_FOR"
        ],
        "overwriteprotocol": "https",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "installed": true,
        "mail_smtpmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "loglevel": 0,
        "maintenance": false,
        "enable_previews": true,
        "secret": "***REMOVED SENSITIVE VALUE***",
        "filesystem_check_changes": 0,
        "filelocking.enabled": "true",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "timeout": 1.5,
            "read_timeout": 1.5,
            "dbindex": 0
        },
        "trashbin_retention_obligation": "auto",
        "overwrite.cli.url": "https:\/\/nextcloud.mydomain.com",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpsecure": "ssl",
        "theme": "",
        "app_install_overwrite": [
            "joplin"
        ],
        "encryption.legacy_format_support": false,
        "encryption.key_storage_migrated": false,
        "default_language": "en",
        "default_phone_region": "CA",
        "maintenance_window_start": 1,
        "memories.db.triggers.fcu": true,
        "memories.exiftool": "\/usr\/share\/nginx\/html\/nextcloud\/custom-apps\/memories\/bin-ext\/exiftool-amd64-glibc",
        "memories.vod.path": "\/usr\/share\/nginx\/html\/nextcloud\/custom-apps\/memories\/bin-ext\/go-vod-amd64",
        "memories.gis_type": 2,
        "enabledPreviewProviders": [
            "OC\\Preview\\Image",
            "OC\\Preview\\HEIC",
            "OC\\Preview\\Movie",
            "OC\\Preview\\TIFF"
        ]
    }
}

List of activated Apps

No response

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

{
  "reqId": "6jDGw0WbOAAarIrEpjXS",
  "level": 0,
  "time": "2024-04-25T13:21:06+00:00",
  "remoteAddr": "192.168.9.6",
  "user": "--",
  "app": "webdav",
  "method": "GET",
  "url": "/remote.php/dav",
  "message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured",
  "userAgent": "Nextcloud Server Crawler",
  "version": "29.0.0.19",
  "exception": {
    "Exception": "Sabre\\DAV\\Exception\\NotAuthenticated",
    "Message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured",
    "Code": 0,
    "Trace": [
      {
        "file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php",
        "line": 89,
        "function": "beforeMethod",
        "class": "Sabre\\DAV\\Auth\\Plugin",
        "type": "->",
        "args": [
          [
            "Sabre\\HTTP\\Request"
          ],
          [
            "Sabre\\HTTP\\Response"
          ]
        ]
      },
      {
        "file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
        "line": 456,
        "function": "emit",
        "class": "Sabre\\DAV\\Server",
        "type": "->",
        "args": [
          "beforeMethod:GET",
          [
            [
              "Sabre\\HTTP\\Request"
            ],
            [
              "Sabre\\HTTP\\Response"
            ]
          ]
        ]
      },
      {
        "file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
        "line": 253,
        "function": "invokeMethod",
        "class": "Sabre\\DAV\\Server",
        "type": "->",
        "args": [
          [
            "Sabre\\HTTP\\Request"
          ],
          [
            "Sabre\\HTTP\\Response"
          ]
        ]
      },
      {
        "file": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php",
        "line": 321,
        "function": "start",
        "class": "Sabre\\DAV\\Server",
        "type": "->",
        "args": []
      },
      {
        "file": "/usr/share/nginx/html/nextcloud/apps/dav/lib/Server.php",
        "line": 374,
        "function": "exec",
        "class": "Sabre\\DAV\\Server",
        "type": "->",
        "args": []
      },
      {
        "file": "/usr/share/nginx/html/nextcloud/apps/dav/appinfo/v2/remote.php",
        "line": 35,
        "function": "exec",
        "class": "OCA\\DAV\\Server",
        "type": "->",
        "args": []
      },
      {
        "file": "/usr/share/nginx/html/nextcloud/remote.php",
        "line": 172,
        "args": [
          "/usr/share/nginx/html/nextcloud/apps/dav/appinfo/v2/remote.php"
        ],
        "function": "require_once"
      }
    ],
    "File": "/usr/share/nginx/html/nextcloud/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php",
    "Line": 152,
    "message": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured",
    "exception": {},
    "CustomMessage": "No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured"
  }
}

Additional info

No response

@cvandesande cvandesande added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Apr 25, 2024
@meldarionqeusse
Copy link

I have the same problem and noticed my .htaccess file was changed with the update are you also getting a warning that .htaccess is not working?

@cvandesande
Copy link
Author

@meldarionqeusse I have the .htaccess file but as I'm using NGINX for the web server I think NGINX ignores it?

I think the well-known URLs are working. I created a new app password and passed the credentials with curl, the redirect works and I get a valid response. So I think the well-known redirects are working, but something has gone wrong with the test in admin settings and no authentication is passed.

curl -iL --location-trusted -u validuser:validpassword https://nextcloud.mydomain.com/.well-known/caldav

HTTP/2 301 
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:55:24 GMT
content-type: text/html
content-length: 162
location: https://nextcloud.mydomain.com/remote.php/dav
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;

HTTP/2 200 
server: nginx/1.25.4
date: Thu, 25 Apr 2024 13:55:25 GMT
content-type: text/html; charset=UTF-8
set-cookie: oc_sessionPassphrase=BYDq5MblWFD0ccawoP0IeYzmlmUteNvFJ%2FaUKJIEZhRdAc4hkrKkA9NPlui%2FaI9QfbW%2F1MmckdtmPRfrlg4oIm8XeaMXLECM0NqBOwdhhf1oeQyeNd5ixn7h%2FkkIY5QA; path=/; secure; HttpOnly; SameSite=Lax
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
content-security-policy: default-src 'none';
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
set-cookie: oc2a3d1f7bcc=7c4296af03227b5fa1a1eb6b2036acf1; path=/; secure; HttpOnly; SameSite=Lax
x-request-id: W9r66ZwhVZCA74Qr6dkT
x-debug-token: W9r66ZwhVZCA74Qr6dkT
referrer-policy: no-referrer
x-content-type-options: nosniff
x-download-options: noopen
x-frame-options: SAMEORIGIN
x-permitted-cross-domain-policies: none
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
strict-transport-security: max-age=15768000; includeSubDomains; preload;

This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client

@H5N1v2
Copy link

H5N1v2 commented Apr 25, 2024

I have the same problem after upgrading to NC29, using apache2, php8.2-fpm and nginx proxy manager. But everything seems to be working fine for now.

@ne20002
Copy link

ne20002 commented Apr 25, 2024

I have this with 28.0.4.
Community Docker image (fpm).

@kesselb
Copy link
Contributor

kesselb commented Apr 25, 2024

Starting with 29 the check is done via php and no longer by your browser. We are using the overwrite.cli.url for it.

Here is the code: https://github.com/nextcloud/server/blob/master/apps/settings/lib/SetupChecks/WellKnownUrls.php

To debug it further please check the redirect on the server with curl and use the overwrite url.

@cvandesande
Copy link
Author

@kesselb overwrite URL is the public facing domain

grep overwrite config.php 
  'overwriteprotocol' => 'https',
  'overwrite.cli.url' => 'https://nextcloud.mydomain.com',
  'app_install_overwrite' => 

It's the same URL I used in my successful curl test should it be something different?

@GrahamTolhurst
Copy link

I'm getting the same problem after upgrading to NC29.0.0. The error must be inaccurately reported as both my calendar and contacts are redirecting properly and syncing to my mobile device.
A bit of testing:
./nextcloud/apps/settings/lib/SetupChecks/WellKnownUrls.php has the following lines of code:

['propfind', '/.well-known/carddav', [207], false],
['propfind', '/.well-known/caldav', [207], false],

With the above lines of code enabled, Nextcloud reports a "/.well-known/caldav" error.
If I comment out the carddav line, Nextcloud reports the same caldav error.
But if I comment out the caldav line and uncomment the carddav line, Nextcloud now reports a carddav error.

It's looking like it's reporting the last test as an error even though it's not.

If I comment out both lines, there's no error reported.

(NC29.0.0 with Apache2, behind Reverse Proxy (Nginx) Server)

@akn01
Copy link

akn01 commented Apr 25, 2024

Same problem here. I use 'overwrite.cli.url' => 'https://nextcloud.mydomain.com', and curl -L -u validuser:validpassword https://nextcloud.mydomain.com/.well-known/caldav outputs the WebDAV message of the interface correctly.

@grogg
Copy link

grogg commented Apr 26, 2024

Same problem after upgrade to Nextcloud 29.0.0 on Apache2. The install documentation has the redirects set to "301" in .htaccess and the error occurs even though the redirects have been verified as functioning properly. Changing the .htaccess redirects from "301" to "207" has resolved the errors on my end.

@kesselb
Copy link
Contributor

kesselb commented Apr 26, 2024

Changing the .htaccess redirects from "301" to "207" has resolved the errors on my end.

Does the redirect still work? ;)

We are looking into the problem and if you are certain that the redirects are okay, then please ignore the setup check for now. Please don't change the response code to 207, that's just wrong.

@kesselb
Copy link
Contributor

kesselb commented Apr 26, 2024

@cvandesande

The setup check expects a redirect to /remote.php/dav/.1

Your redirect goes to /remote.php/dav without a trailing slash.

Please double-check your configuration if the redirects are configured with a trailing slash.2

Footnotes

  1. https://github.com/nextcloud/server/blob/10af08736e9094dd3f7240ec517cea9a0061d5b4/apps/settings/lib/SetupChecks/WellKnownUrls.php#L84

  2. https://github.com/nextcloud/documentation/blob/master/admin_manual/installation/nginx-root.conf.sample#L124-L125

@KopfKrieg
Copy link

KopfKrieg commented Apr 26, 2024

Seems like the documentation isn't really clear about that :/

For apache, there are no trailing slashes mentioned: https://docs.nextcloud.com/server/latest/admin_manual/issues/general_troubleshooting.html#service-discovery-label

Also, for reverse proxies there are some with, some without trailing slashes: https://docs.nextcloud.com/server/29/admin_manual/configuration_server/reverse_proxy_configuration.html#service-discovery

(Also, my Gnome Online Account [Fedora 40, Gnome 46] still doesn't work after adding trailing slashes, DAVx5 works fine though, and the error in the web ui is also gone)

@kesselb
Copy link
Contributor

kesselb commented Apr 26, 2024

I think for the functionality - the service discovery - the trailing slash is not that important.
The check, that works different since 29 than before, is rather strict and tests for the trailing slash.

In any case, the documentation should be updated. The service discovery is usually a topic if you are using a reverse proxy (without it should work out of the box) and therefore it's a part of that documentation. For the other cases, we have the article in the general troubleshooting section. It should be fine to move the service discovery to an own page in configuration_server and merge the articles.

@akn01
Copy link

akn01 commented Apr 26, 2024

Solution for me: Redirection to /remote.php/dav/ with trailing slash at the end in Nginx Proxy Manager makes the error message disappear.

@cvandesande
Copy link
Author

Trailing slash was the solution for me as well. Thank you!
Agree with @KopfKrieg trailing slashes are missing from the NGINX reverse proxy docs: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#nginx

@kesselb should we keep this issue open, or close it and open a documentation issue?

@janusn
Copy link

janusn commented Apr 26, 2024

Unfortunately, a trailing slash does not help my nc 29 instance. It still complain with either the following lines:

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

or

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

        rewrite ^/\.well-known/carddav https://$server_name/remote.php/dav/ redirect;
        rewrite ^/\.well-known/caldav https://$server_name/remote.php/dav/ redirect;
    }

@blaine07
Copy link

Came here to confirm, changing THIS:
orig-cal-nc29

To THIS:
image

Fixed THIS issue when upgrading to v29.0.0:
image png 183e5a6dc8a50c2c2694ffd3ef6cf707

I also restarted Nextcloud instance and my NPM Proxy it was going through :-)

@sn0n
Copy link

sn0n commented Apr 28, 2024

having this issue as well.

Caddy setup as reverse proxy, nextcloud manual install on its own VM.
Caddy rewrite is working, returning a 401 result, resulting warning in Admin Overview.

@h9419
Copy link

h9419 commented May 1, 2024

./nextcloud/apps/settings/lib/SetupChecks/WellKnownUrls.php has the following lines of code:

['propfind', '/.well-known/carddav', [207], false],
['propfind', '/.well-known/caldav', [207], false],

(NC29.0.0 with Apache2, behind Reverse Proxy (Nginx) Server)

This causes problem for subfolder installations because this will be checking for /subfolder/.well-known/carddav instead of /.well-known/carddav whereas applications using WebDAV will be querying for /.well-known/carddav without the subfolder.

I have a workaround for nginx/swag in linuxserver/reverse-proxy-confs#673 if anyone is facing the same problem as I do

@kesselb
Copy link
Contributor

kesselb commented May 2, 2024

@h9419

This causes problem for subfolder installations because this will be checking for /subfolder/.well-known/carddav instead of /.well-known/carddav whereas applications using WebDAV will be querying for /.well-known/carddav without the subfolder.

If overwrite.cli.url is yourhost.com/subfolder, then it will indeed check for yourhost.com/subfolder/.well-known/carddav.

The check also takes the trusted_domains into account, which should be declared without a subfolder and make the check pass.

Mind to take a look at your trusted_domains and share them with us?

@sn0n
Copy link

sn0n commented May 2, 2024

My trusted domains array cloud.domain.com, overwritecli has the same domain with https://

Not using a subfolder.

@kesselb
Copy link
Contributor

kesselb commented May 2, 2024

My trusted domains array cloud.domain.com, overwritecli has the same domain with https://

Did you try to update the caddy redirect rules so they redirect to /remote.php/dav/ rather than /remote.php/dav (note the additional trailing slash)?

@sn0n
Copy link

sn0n commented May 2, 2024

Did you try to update the caddy redirect rules so they redirect to /remote.php/dav/ rather than /remote.php/dav (note the additional trailing slash)?

Yes, that wasn't the fix.

@cruzmanny
Copy link

I struggled with this issue for the past 48 hours. I am using Nextcloud 29. At first I thought it was an issue with upgrading to Ubuntu Server 24.04. However, adding 'localhost' to config/config.php file fixed it for me. I updated my file to this;

'trusted_domains' =>
array (
0 => 'nextcloud.mydomain.com',
1 => 'localhost'
),

I hope this helps any one else who is struggling.

@sn0n
Copy link

sn0n commented May 2, 2024

I struggled with this issue for the past 48 hours. I am using Nextcloud 29. At first I thought it was an issue with upgrading to Ubuntu Server 24.04. However, adding 'localhost' to config/config.php file fixed it for me. I updated my file to this;

'trusted_domains' => array ( 0 => 'nextcloud.mydomain.com', 1 => 'localhost' ),

I hope this helps any one else who is struggling.

Sadly didn't work on my end either. With or without the trailing / on the redirect.

@cruzmanny
Copy link

I struggled with this issue for the past 48 hours. I am using Nextcloud 29. At first I thought it was an issue with upgrading to Ubuntu Server 24.04. However, adding 'localhost' to config/config.php file fixed it for me. I updated my file to this;
'trusted_domains' => array ( 0 => 'nextcloud.mydomain.com', 1 => 'localhost' ),
I hope this helps any one else who is struggling.

Sadly didn't work on my end either. With or without the trailing / on the redirect.

The other thing I added when it started working was 'htaccess.RewriteBase' => '/', but I am not sure if that will work.

@Virsacer
Copy link

Virsacer commented Sep 4, 2024

Yesterday I spent some time to analyze why Nextcloud was complaining about webfinger but not the other redirects.
I found that the test-urls are not beeing properly built - so I "fixed" it by just adding more redirects:

Redirect 301 /nextcloud/.well-known/caldav /nextcloud/remote.php/dav
Redirect 301 /nextcloud/.well-known/carddav /nextcloud/remote.php/dav
Redirect 301 /nextcloud/.well-known/nodeinfo /nextcloud/index.php/.well-known/nodeinfo
Redirect 301 /nextcloud/.well-known/webfinger /nextcloud/index.php/.well-known/webfinger

Today I wanted to file a bug report and found this issue :D
So until the patch is included in the stable release, you can use this simple trick...

@drankinatty
Copy link

drankinatty commented Sep 7, 2024

I can confirm after MUCH grief since NC 28 broke this that the patch beginning this thread (1) won't apply as written (rejected), but (2) manually applying the changes DOES FIX the webfinger problem! This is on Archlinux, Nextcloud Hub 8 (29.0.6) with:

  kernel:   6.10.8-arch1-1
  Apache:   2.4.62 (Unix)
  OpenSSL:  3.3.1
  PHP:      8.2.23 

@MichaIng MichaIng added 4. to release Ready to be released and/or waiting for tests to finish and removed 2. developing Work in progress labels Sep 8, 2024
@MichaIng
Copy link
Member

MichaIng commented Sep 8, 2024

It is fixed for the upcoming point releases of NC29 and NC30, scheduled for upcoming week :) .

@kesselb
Copy link
Contributor

kesselb commented Sep 11, 2024

If you still see the issue with the upcoming 29.0.7 or 30.0.0, we already have a follow-up for 29.0.8 and 30.0.1 in the queue to resolve the problem for more cases.

@andrewheeler82
Copy link

I love you 🤟

@kesselb
Copy link
Contributor

kesselb commented Sep 11, 2024

I'm just the messenger, Ferdinand did the work ;)

#47883

@drankinatty
Copy link

drankinatty commented Sep 13, 2024

This is depressing. Just updated to Hub 8 29.0.7 and after fixing the well-known web-finger warning with the patch in this thread, now it's back in a different form. Among other new warnings in 29.0.7 that didn't exist in 29.0.6, we now get:

  • Could not check that your web server serves .well-known correctly. Please check manually. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its trusted_domains or the overwrite.cli.url. For more details see the documentation ↗.

In addition to now claiming it "Could not check that your web server serves .well-known correctly.", the following are also shown:

  • Your webserver is not set up to serve .js.map files. Without these files, JavaScript Source Maps won't function properly, making it more challenging to troubleshoot and debug any issues that may arise.
  • Could not check for JavaScript support via any of your trusted_domains nor overwrite.cli.url. This may be the result of a server-side DNS mismatch or outbound firewall rule. Please check manually if your webserver serves .mjs files using the JavaScript MIME type. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its trusted_domains or the overwrite.cli.url.
  • Could not check for WOFF2 loading support. Please check manually if your webserver serves .woff2 files. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its trusted_domains or the overwrite.cli.url. For more details see the documentation ↗.

None of which were shown in Ver. 29.0.6.

I'm not sure whether progress was made or not given the new related warnings that are shown. Nothing else changed, just updated and ran occ upgrade -- all of which completed happily.

@andrewheeler82
Copy link

This is depressing. Just updated to Hub 8 29.0.7 and after fixing the well-known web-finger warning with the patch in this thread, now it's back in a different form. Among other new warnings in 29.0.7 that didn't exist in 29.0.6, we now get:

  • Could not check that your web server serves .well-known correctly. Please check manually. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its trusted_domains or the overwrite.cli.url. For more details see the documentation ↗.

In addition to now claiming it "Could not check that your web server serves .well-known correctly.", the following are also shown:

  • Your webserver is not set up to serve .js.map files. Without these files, JavaScript Source Maps won't function properly, making it more challenging to troubleshoot and debug any issues that may arise.
  • Could not check for JavaScript support via any of your trusted_domains nor overwrite.cli.url. This may be the result of a server-side DNS mismatch or outbound firewall rule. Please check manually if your webserver serves .mjs files using the JavaScript MIME type. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its trusted_domains or the overwrite.cli.url.
  • Could not check for WOFF2 loading support. Please check manually if your webserver serves .woff2 files. To allow this check to run you have to make sure that your webserver can connect to itself. Therefor it must be able to resolve and connect to at least one its trusted_domains or the overwrite.cli.url. For more details see the documentation ↗.

None of which were shown in Ver. 29.0.6.

I'm not sure whether progress was made or not given the new related warnings that are shown. Nothing else changed, just updated and ran occ upgrade -- all of which completed happily.

Same Problem as you…

@khlschrnk
Copy link

khlschrnk commented Sep 13, 2024

I had exactly the same many warnings after updating to 29.0.7

I could fix it by checking all entries in trusted_domains AND overwrite.cli.url.

I had a mistake in overwrite.cli.url. I had a subdirectory at the end of my overwrite.cli.url (www.domain.com/nextcloud). After removing this and only pointing to the real domain (www.domain.com) ALL of these warning were gone.

//EDIT: Do not follow this "solution". According to the posts below this is not a suitable solution! Please also refer to #45033 (comment)

@drankinatty
Copy link

I had exactly the same many warnings after updating to 29.0.7

I could fix it by checking all entries in trusted_domains AND overwrite.cli.url.

I had a mistake in overwrite.cli.url. I had a subdirectory at the end of my overwrite.cli.url (www.domain.com/nextcloud). After removing this and only pointing to the real domain (www.domain.com) ALL of these warning were gone.

Thank You!

My install is in /nextcloud so I included that at the end of overwrite.cli.url. It was as the Arch wiki recommended when I installed nextcloud (somewhere around Ver. 24 or 25), and it had been that way since. It had been that way in the configs I've posted here and to the nextcloud forums no less than 10 times and nothing was ever said.

I don't know why that issue hadn't surfaced until now -- but I guess 29.0.7 finally got around to adding checks that disclosed the issue (or something else changed...)

My warnings are gone now removing /nextcloud from the end.

Whew, I hate having warning...

@come-nc come-nc reopened this Sep 13, 2024
@Virsacer
Copy link

I had a mistake in overwrite.cli.url. I had a subdirectory at the end of my overwrite.cli.url (www.domain.com/nextcloud). After removing this and only pointing to the real domain (www.domain.com) ALL of these warning were gone.

overwrite.cli.url is supposed to include the subdir (see #45033 (comment))

I solved all but one warning with this redirect:

Redirect 301 /nextcloud/nextcloud /nextcloud

Apparently the check for .well-known is now missing the domain in the testURL...

@come-nc
Copy link
Contributor

come-nc commented Sep 13, 2024

See #45033 (comment) , the issue actually got worse because of a mistake in the fix we merged in the last releases. It should be fixed in the next one, the PR is in the work.

Please do not remove the webroot from the overwrite.cli.url, it should be included! These server warnings are simply broken for installations in a subdirectory for this version, sorry about this.

@drankinatty
Copy link

Pardon me for my confusion here, but before I install 29.0.8, I'm supposed to re-add the install subdirectory /nextcloud back to the end of my overwrite.cli.url option from which I had to remove it to get rid of the warnings after the 29.0.6 -> 29.0.7 update?

(more a statement than a questions, but correct me if I am wrong...)

Understanding these things happen ... it reminds us we are human ... it will get much worse once humans are removed from the development chain ... then when it happens there will be no human left that retains the institutional knowledge to know where the problem hides...

@come-nc
Copy link
Contributor

come-nc commented Sep 13, 2024

You should actually put back the subdirectory right now, and ignore the warning.

Note that I did not check if anything actually fails if overwrite.cli.url is missing the subdir, but I know that it’s supposed to be there.

@drankinatty
Copy link

drankinatty commented Sep 13, 2024

You should actually put back the subdirectory right now, and ignore the warning.

Note that I did not check if anything actually fails if overwrite.cli.url is missing the subdir, but I know that it’s supposed to be there.

Many thanks,

Done!

note: the nextcloud install showed no difference in operation regardless of whether the statement was appended or not -- other than the warnings.

@MichaIng
Copy link
Member

note: the nextcloud install showed no difference in operation regardless of whether the statement was appended or not -- other than the warnings.

This URL is used by background/cron jobs and occ CLI calls to communicate with the backend. Missing or failing background jobs might not show an immediate effect on operation, but can degrade performance over time, grow memory usage and such, since it implies a bunch of cleanup jobs.

@susnux
Copy link
Contributor

susnux commented Sep 15, 2024

Fixed in next maintenance releases with
#47883

@susnux susnux closed this as completed Sep 15, 2024
@remyd1
Copy link

remyd1 commented Oct 11, 2024

FYI, the bug is still present in 29.0.8 release .

@kesselb
Copy link
Contributor

kesselb commented Oct 11, 2024

The patch didn't make it into 29.0.8 🙈

@susnux
Copy link
Contributor

susnux commented Oct 11, 2024

Fixed for Nextcloud 30 (starting with 30.0.1), for 29 the backport is still in review: #47943

@martinjgrunwald
Copy link

martinjgrunwald commented Oct 11, 2024

Fixed for Nextcloud 30, for 29 the backport is still in review: #47943

I still have this issue with 30.0.0. Did I misconfigure something or will it be fixed in 30.0.1?

@MichaIng MichaIng linked a pull request Oct 11, 2024 that will close this issue
2 tasks
@kesselb
Copy link
Contributor

kesselb commented Oct 11, 2024

Fixed for Nextcloud 30, for 29 the backport is still in review: #47943

I still have this issue with 30.0.0. Did I misconfigure something or will it be fixed in 30.0.1?

Sorry, that was a typo.
It's 30.0.1.

@MichaIng MichaIng linked a pull request Oct 11, 2024 that will close this issue
4 tasks
@andrewheeler82
Copy link

💪💪💪💪💪💪💪💪

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