Better `Setup and Security warnings` UX
Is your feature request related to a problem? Please describe.
After NC29, loopback access to the NC server instance is required for Setup and Security warnings. In the absense of this, many warnings are shown that could not check ... and also the upgrade documentation lacks more details on how to get it properly working.
Describe the solution you'd like Based on the discussion on the forum, two improvements can be done:
- there could 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 (or having a fallback, see alternative solutions).
- he 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 could be an issue with the container/VM network or internal firewall or even some external firewall denying or dropping the request.
Describe alternatives you've considered Any way to make the experience less frustrating and confusing to the server admin. Another way could be a fallback to previous checks without loopback connectivity like it worked previous to NC29 with a warning that the checks are not 100% reliable.
Additional context More details on the discussion on the forum.
I'm wondering about the first point there could be a pre-check if the domain is reachable.
Indeed, curling myself does return 200 with for example curl -I https://www.domain.tld/subfolder/apps/settings/js/map-test.js.map
Yet I do get the following warning (among a batch of others):
Could not check for JavaScript support via any of your
trusted_domainsnoroverwrite.cli.url. This may be the result of a server-side DNS mismatch or outbound firewall rule. Please check manually if your webserver serves.mjsfiles 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 itstrusted_domainsor theoverwrite.cli.url.
Running on apache, no proxy, nextcloud installed in a subfolder My config.php contains:
'trusted_domains' => array ( 0 => 'www.domain.tld', 1 => 'domain.tld', ), 'overwrite.cli.url' => 'https://www.domain.tld/subfolder', 'overwritehost' => 'domain.tld', 'overwriteprotocol' => 'https', 'overwritewebroot' => '/subfolder',
I'm following this for the (apparently false-positive) warnings on the admin page, but am suspecting a linked issue granting access to Password Android app that has started hanging at about the same time
@shining-cat Can confirm, the issues (EDIT: with make sure that your webserver can connect to itself) also appeared on my side after upgrading from Nextcloud 28 to Nextcloud 29 without any changes related to networking, firewall or DNS.
I am also running in a subfolder, curl on itself via ssh also works with all trusted_domains and overwrite.cli.url.
However, I am using nginx, not Apache.
I suspect this is a regression in Nextcloud 29.
Was bored and did a bit of debugging: Adding a log to runRequest in CheckServerResponseTrait seems to indicate, that the subpath Nextcloud is running in is present twice for some checks. I.e. I see the following being used:
https://my.domain.tld/nextcloud/remote.php/webdav
https://my.domain.tld/nextcloud/nextcloud//storage/nextcloud/data/.ocdata
https://my.domain.tld/nextcloud/nextcloud/apps/settings/js/map-test.js.map
https://my.domain.tld/nextcloud/nextcloud/apps/settings/js/esm-test.mjs
https://my.domain.tld/nextcloud/ocm-provider/
https://my.domain.tld/nextcloud/ocs-provider/
https://my.domain.tld/nextcloud/nextcloud/heartbeat
/nextcloud/.well-known/webfinger
https://my.domain.tld/nextcloud/nextcloud/apps/theming/fonts/OpenDyslexic-Regular.otf
I'm also a bit suspicious about the double / in data/.ocdata check. ~And for the webfinger, which seems to lack the host part alltogether.~
EDIT: Just realized: the webfinger thingy may be fine after all and I just grabbed the wrong log line.
@shining-cat & @j-be Subfolder matter is different. Fixed in #47943 (and elsewhere, depending on major version, but same difference).
there could 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 (or having a fallback, see alternative solutions).
There could be and I get what you're saying (it'd be a bit cleaner), but:
a) This would require maintaining a lot more state data across the setup checks and various apps and adding a lot of logic to maintain and keep bug-free (keep in mind that even third-party apps can add setup checks) b) This immediately goes away when the core problem (connectivity or DNS) is fixed c) It's a one-time event
The documentation Upgrade to Nextcloud 28 — Nextcloud latest Administration Manual latest documentation could have more details on the point
Any specific suggestions?
Feel free to suggest something or - better yet - pop over there and click the Edit button at the top of the page. Though I'm not sure myself what else is needed. Troubleshooting DNS and connectivity is highly specific to each environment and more a general system administration activity.
This could be an issue with the container/VM network or internal firewall or even some external firewall denying or dropping the request.
The referenced docs call out firewalling as something to check a few lines down.
This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.