Description
openedon Sep 13, 2024
⚠️ This issue respects the following points: ⚠️
- This is a bug, not a question or a configuration/webserver/proxy issue.
- This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
- Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
- I agree to follow Nextcloud's Code of Conduct.
Bug description
Not withstanding https://docs.nextcloud.com/server/latest/admin_manual/release_notes/upgrade_to_28.html#setup-checks, Nextcloud Hub 8 (29.0.7) is ignoring overwrite.cli.url being defined as a subdirectory when doing system and security checks. I receive the following errors because my installation is in a subdirectory (e.g., nextcloud.mydomain.com/nextcloud_dir):
There are some warnings regarding your setup.
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`.
5 errors in the logs since September 6, 2024, 2:40:39 PM
Could not check that your web server serves security headers correctly, unable to query `/nextcloud_dir/index.php/heartbeat` For more details see the documentation ↗.
`check_for_working_wellknown_setup` is set to false in your configuration, so this check was skipped.
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.
See also many help requests at https://help.nextcloud.com/t/many-could-not-check-on-security-and-setup-warnings/201840/6.
UPDATE: I should clarify the root directory properly returns a 403 as intended:
root@my_ip ~ $ curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com/
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access this resource.</p>
</body></html>
root@my_ip ~ $ curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com/nextcloud_dir
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://nextcloud.mydomain.com/nextcloud_dir/">here</a>.</p>
</body></html>
root@my_ip ~ $ curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com/nextcloud_dir/
UPDATE 2: I should also mention that updating /etc/hosts (per #44114 (comment)) to include:
127.0.0.1 nextcloud.mydomain.com
...responds with "It works" content but does not resolve the Nextcloud errors.
curl -H 'Cache-Control: no-cache, no-store' nextcloud.mydomain.com
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Apache2 Debian Default Page: It works</title>
<style type="text/css" media="screen">
Steps to reproduce
- Setup Nextcloud within subdirectory
- Upgrade to 29.0.7
- Check for system and security issues (https://nextcloud.mydomain.com/nextcloud_dir/index.php/settings/admin/overview)
Expected behavior
When checking for system and security issues (https://nextcloud.mydomain.com/nextcloud_dir/index.php/settings/admin/overview), Nextcloud should use/take into account that overwrite.cli.url is defined as a subdirectory.
Nextcloud Server version
29
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.3
Web server
Apache (supported)
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Updated from a MINOR version (ex. 28.0.1 to 28.0.2)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
No response
List of activated Apps
No response
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response