Many `could not check` on Security and setup warnings

Nextcloud version (eg, 29.0.5): 29.0.5
Operating system and version (eg, Ubuntu 24.04): Debian 12 2024-06-01
Apache or nginx version (eg, Apache 2.4.25): 2.4.61
PHP version (eg, 8.3): 8.1.29

The issue you are facing:

After upgrading to NC 29 I started having much more warnings on Security & setup warnings. The problem is that most of them are Could not check something....

A full list:

* Could not check that the data directory is protected. Please check manually that your server does not allow access to the data directory. 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`.
* 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 if your web server properly resolves the OCM and OCS provider URLs. 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`.
* 12 errors in the logs since August 19, 2024, 3:09:13 PM
* Could not check that your web server is properly set up to allow file synchronization over WebDAV. 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 ↗](https://docs.nextcloud.com/server/29/go.php?to=admin-setup-well-known-URL).
* 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 ↗](https://docs.nextcloud.com/server/29/go.php?to=admin-setup-well-known-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 ↗](https://docs.nextcloud.com/server/29/go.php?to=admin-nginx).
* Could not check that your web server serves security headers correctly. Please check manually. For more details see the [documentation ↗](https://docs.nextcloud.com/server/29/go.php?to=admin-security).

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

Steps to replicate it:

  1. Just open Administration → Overview → Wait a bit longer that usual.

The output of your Nextcloud log in Admin > Logging:

Nothing relevant.

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

<?php
$CONFIG = array (
  'passwordsalt' => 'some_salt',
  'secret' => 'some_secret',
  'trusted_domains' => 
  array (
    0 => 'my.domain',
  ),
  'datadirectory' => '/data',
  'dbtype' => 'mysql',
  'version' => '29.0.5.1',
  'overwrite.cli.url' => 'https://my.domain',
  'dbname' => 'nextcloud',
  'dbhost' => '127.0.0.1',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'my_admin',
  'dbpassword' => 'my_password',
  'installed' => true,
  'instanceid' => 'my_instance_id',
  'default_phone_region' => 'BE',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'redis' => 
  array (
    'host' => '/var/run/redis/redis.sock',
    'port' => '0',
  ),
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'maintenance' => false,
  'theme' => '',
  'loglevel' => 2,
  'maintenance_window_start' => 2,
  'updater.release.channel' => 'beta',
);

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

No relevant errors on error.log.

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

Nothing relevant.

See the Critical Changes section of the release notes for 28/29 for likely culprits and solutions related to setup checks: Upgrade to Nextcloud 28 — Nextcloud latest Administration Manual latest documentation

@jtr thanks for your reply. based on this notes I discovered that my nextcloud instance is not able to wget or curl its own domain. But it always worked without that, so now we need to loosen the security of our instance opening firewall rules to have security checks? It sounds a bit bad…

Upgraded to 29.0.7 , my nextcloud is in a subdirectory, I’m getting some of the warnings above. This one in particular:
Could not check that your web server serves security headers correctly, unable to query /nextcloud/index.php/heartbeat

Tried this on the server: curl -I https://www.mynextcloudsite.com/nextcloud/index.php/heartbeat
And it returns: HTTP/2 200

So what’s going on here?

I’m having the same problem. It looks to me like the test code is somehow not taking the subdirectory installation into account. When requesting the heartbeat file, for instance, it is requesting /nextcloud/nextcloud/heartbeat instead of /nextcloud/heartbeat. When I use curl to request it, it works fine.

Here is an example from the logs of a request from the test system and a manual request:

access.log:xxx.xxx.xxx.xxx - - [12/Sep/2024:20:36:21 -0500] "GET /nextcloud/nextcloud/heartbeat HTTP/1.1" 404 10388 "-" "Nextcloud Server Crawler"

access.log:xxx.xxx.xxx.xxx - - [12/Sep/2024:20:53:51 -0500] "GET /nextcloud/heartbeat HTTP/1.1" 200 5101 "-" "curl/7.81.0"

1 Like

I’m having the same issue. I also have NC configured as ‘my.domain/nextcloud’. I’m assuming there is a change in 29.0.7 (I either had 29.0.5 or .6 before updating with no issue) that fails to check on configurations with NC in a subdirectory of the domain. Although, I’d also think that this type of configuration would be checked before a release.

1 Like

Same issue here:
nextcloud in subfolder on ubuntu-Apache, same list of warnings after update.
Curling curl -I https://www.domain.tld/subfolder/apps/settings/js/map-test.js.map returns 200

I also think this has to be related to the login-grant access webflow suddenly stopping to work: I can log and grant access to android nextcloud client app and any android app relying on it for access.
For any other, the flow fails, whether I use App passwords or login form.
I have checked these settings

My Server had no issues or error messages before the update this morning. Since 29.0.6 I have many errors. And not a clue as to how to resolve them

Have to point out that it does indeed look like false positives.
Before updating to 29.0.7 I had the false positive '.well-known’warning although config was checked and correct.
Now this whole new bunch, when config is checked again, and curling myself succeeds …

I do think there’s something with having nextcloud in a subfolder, and am hoping the concomittent failure of access granting in webflows might point the way to what’s actually broken?

I spent a lot of time trying to resolve these before realising they are false positives and coming to this thread. Will be following closely for advice.

Also seeing the same with things like:

179d095bf57a <proxy_ip> - - [17/Sep/2024:08:11:02 +0000] "HEAD /nextcloud/nextcloud/apps/settings/js/esm-test.mjs HTTP/1.1" 404 0 "-" "-" 119350
179d095bf57a <proxy_ip> - - [17/Sep/2024:08:11:03 +0000] "GET /nextcloud/nextcloud/index.php/heartbeat HTTP/1.1" 404 5115 "-" "-" 119357

looks like the fix will come with 29.0.8 / 30.0.0.1

As a user, admin and developer I really value their effort but even with this fix the amount of warnings is not user friendly.

Actually there should be a pre-check if the domain is reachable instead of creating many could not check errors and make just one error to fix the connectivity first.

Also the documentation Upgrade to Nextcloud 28 — Nextcloud latest Administration Manual latest documentation could have more details on the point

  • verifying that the Server can reach its own URL(s)

This can be an issue with the container/VM network or internal firewall or even some external firewall denying or dropping the request.

I am looking forward to install 29.0.8 and as the overview check seems not to work at all at the moment.
Nextcloud is up and running.
Wish there would be an overview after testing with only 1 warning that says how many log errors there are since day month.

When this bug is fixed, could someone please post a working apache httpd.conf on nextcloud server and a working vhost.conf on reverse proxy and a working config.php on config directory? Would be awesome to see these three files of someone else who is running without nginx but only apache and is behind a reverse proxy.
i do not run docker btw :slight_smile: maybe it is kind of outdated to run without docker? what would you say?

I saw there is an issue now https://github.com/nextcloud/server/issues/48150 to even make it less polluted in case some configuration is wrong show just what is wrong instead of many warnings. If you have Github please thumbs up for it.

1 Like

I’d been having the exact same issue for several months myself, it’s like the OP pulled his list from my installation! I never devoted much time to troubleshooting the issue, as everything appeared to work correctly, and the few times I did attempt, I was looking within my NC installation itself… until I saw this:

I am running NC on a Proxmox LXC, reversed proxied as https://nextcloud.redacted.invalid, with an OPNSense firewall running Unbound DNS. When I pinged the URL, it came back to my internal IP, not my external IP. My Unbound DNS override was OK (using nc for the hostname, not nextcloud), but my /etc/hosts, /etc/hostname, and Proxmox LXC DNS was not OK; it was set to nextcloud, causing it to resolve to the internal IP, and thus failing all those checks. Changing the hostname from nextcloud to nc fixed ALL those errors, and I got that beautiful green checkmark once more.

It’s always DNS! :rofl:

1 Like

I’ve had to fight a similar problem those last days… my external requests to my server from my own network failed with reaching my routerlogin-page.

I needed to disenable the (un)bind-setting within my own router for my server-URL to get trough to my server. at the same time all errormessages of the server were gone as well.

So perhaps that might be a little hint and help for someone.

It got even worst for me… I updated to 29.0.7 and now a started having a red error:
Your web server is not yet properly set up to allow file synchronization, because the WebDAV interface seems to be broken. 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.

I checked on config and my trusted_domains and overwrite.cli.url correctly have my domains, also my server can correctly resolve my domain name with the correct IP. Maybe someone from NC team could help us.

try rebooting your machine… where is it hosted? at home?

Yes, it is hosted at home. I rebooted and tried configurations many times. DNS works perfect resolved to my external IP. I just discovered that somehow it complains about my SSL certificate being self-signed when I curl from my NC VM, but when I do it from the internet or even on the browser, it works perfect with a valid certificate. I have no idea how could that happen.