[Bug]: There are some warnings regarding your setup (v29)

⚠️ 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

TEST Uprade from NC 28.0.3 to 29.0.0. BETA:

There are some warnings regarding your setup.
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. 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.
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 ↗.
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 ↗.
Please double check the installation guides ↗, and check for any errors or warnings in the log.

Steps to reproduce

run GUI "OVERVIEW

Expected behavior

no warnings or errors

Installation method

Community Manual installation with Archive

Nextcloud Server version

28

Operating system

RHEL/CentOS

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database engine version

MariaDB

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?

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 errors has been found

Nextcloud Logs

No response

using self singed cert. (Nextcloud vm test instance)

No response

We also have the same problem after updating to Nextcloud Hub 8 version (29.0.0 beta 1) from version 28.0.3. The same messages after update vía GUI web interface.

Well done :-)

Security & setup warnings
It's important for the security and performance of your instance that everything is configured correctly. To help you with that we are doing some automatic checks. Please see the linked documentation for more information.

All checks passed.
Check the security of your Nextcloud over our security scan ↗.

Version
Nextcloud Hub 8 (29.0.0 beta 2)

Update
Your version is up to date.

btw - what did you do with 29.x - it runs much faster than ever - wough - what a difference !

@Githopp192

Thanks for the report @Githopp192. Going to close this out since it seems fixed. :)

Therefor it must be able to resolve and connect to at least one its ...

should be

... one of it's ...

e.g. line

server/apps/settings/l10n/en_GB.json

Line 131 in cb27fbc

    
           "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`." : "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 still have this issue, after updating to NC 29.0.0 yesterday:

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`.

    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`. Weitere Informationen findest du in der [Dokumentation ↗](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`. Weitere Informationen findest du in der [Dokumentation ↗](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`. Weitere Informationen findest du in der [Dokumentation ↗](https://docs.nextcloud.com/server/29/go.php?to=admin-nginx).

I am running NC in a docker-container in a VM behind a proxy on another VM on th same host. I installed with this docker-compose:


version: '3'

services:
  db:
    image: mariadb
    #?command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW --skip-innodb-read-only-compressed --innodb_read_only_compressed=OFF
    restart: "no"
    volumes:
      - /var/kunden/docker-services/next.example.de/volumes/mysql:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=***
      - MYSQL_PASSWORD=***
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MARIADB_AUTO_UPGRADE=1
      - MARIADB_DISABLE_UPGRADE_BACKUP=1
    #?env_file:
    #?  - db.env

  redis:
    image: redis:alpine
    restart: always

  # https://github.com/nextcloud/docker/blob/master/14.0/apache/Dockerfile
  #
  app:
    image: nextcloud:29.0.0
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - 8083:80
    links:
      - db
      - redis
    depends_on:
      - db
      - redis
    volumes:
      - /nextcloud/next.example.de/html:/var/www/html
    restart: always
    environment:
      - MYSQL_HOST=db
      - REDIS_HOST=redis

maybe, because I linked the volume to another partition?

- /nextcloud/next.example.de/html:/var/www/html

mountpoint

/dev/xvda3 on /nextcloud type ext4 (rw,relatime)

I tried

chown www-data:www-data /nextcloud/next.example.de -Rf

but the messages are still there

I have the same issue after upgrading. Nextcloud 29.0.0 is installed directly on arch linux. No docker is involved.
Also the check takes a long time to complete. I had to increase the timeout as it takes over 1 minute.

Where does nextcloud take the domain from for checking?
I just realized that the link behind "Nextcloud 8 (29.0.0)" in the version section below the security warnings points to an old domain that I do not use anymore. This domain is also in none of the config files.

@joshtrichards

@joshtrichards Yes, for me the issue was that the server was not able to reach itself via the domain name. I added an entry in /etc/hosts to use 127.0.0.1. Now it works. Thanks for your help.

Can you please show your hosts file?
I already have 127.0.0.1 in the file but it still do not work

$ cat /etc/hosts
# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1 localhost
::1 localhost
127.0.0.1 my.nextcloud.domain

Replace my.nextcloud.domain with your domain

Afterwards, if you ping the domain from your server, it should ping 127.0.0.1

With the recommended nginx configuration. w3m https://cloud.mydomain results in "Redirect loop detected (w3m https://cloud.mydomain/login ). I think this is the root cause. NextCloud version is 28.0.6. Tried suggested /etc/hosts changes, but it is always going to redirect loop.

w3m https://cloud.mydomain/login works (though with JavaScript disabled)

I'm not a GitHub user, so please have patience!

I looked through this thread and it indicates that this "bug" is fixed. I just upgraded my NC to Hub 8 and I get all of the indicated error messages at the head of this, yet a scan of the headers from the system shows that all is well with an A+ rating.

I took each error one by one, and my configuration files seem to be fine!

Any clues where I should start? TIA

As someone also seeing this, I'm hoping to add a useful "data point".

If I try wget https://<hostname>/ from the command line on the server, I get:

--2024-06-27 14:24:56--  https://<hostname>/
Resolving <hostname> (<hostname>)... <IPv6#>, <IPv4#>
Connecting to <hostname> (<hostname>)|<IPv6#>|:443... connected.
The certificate's owner does not match hostname ‘<hostname>’

The same command from my desktop succeeds (with the <IPv6#> and <IPv4#> here matching those shown in the above):

--2024-06-27 14:37:56--  https://<hostname>/
Resolving <hostname> (<hostname>)... <IPv6#>, <IPv4#>
Connecting to <hostname> (<hostname>)|<IPv6#>|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.1’

index.html.1 [ <=> ]   2.77K  --.-KB/s    in 0s      

2024-06-27 14:37:57 (57.9 MB/s) - ‘index.html.1’ saved [2840]

So I assume I have some other server configuration problem here, and its not a NextCloud problem itself. But not obvious to me what I need to do to fix it. (My server is cPanel-based for what it's worth.)

I'm not a GitHub user, so please have patience!

I looked through this thread and it indicates that this "bug" is fixed. I just upgraded my NC to Hub 8 and I get all of the indicated error messages at the head of this, yet a scan of the headers from the system shows that all is well with an A+ rating.

I took each error one by one, and my configuration files seem to be fine!

Any clues where I should start? TIA

Update: The https server couldn't communicate properly because... of a slight misconfiguration in my hosts file. Yeah. Please disregard my posts, thx.

Perhaps as an "on the other hand", I looked at the apache logs after a check, and found the following:

In the access_log, the initial PROPFIND lacked the <dir> subdirectory in which my NextCloud instance is installed:

... "PROPFIND /remote.php/webdav HTTP/1.1" 404 10086 "-" "Nextcloud Server Crawler"
... "HEAD /<dir>//home/<user>/ncdata/.ocdata HTTP/1.1" 404 - "-" "Nextcloud Server Crawler"
... "HEAD /<dir>/apps/settings/js/map-test.js.map HTTP/1.1" 404 - "-" "Nextcloud Server Crawler"
... "HEAD /<dir>/apps/settings/js/esm-test.mjs HTTP/1.1" 404 - "-" "Nextcloud Server Crawler"
... "HEAD /<dir>/ocm-provider/ HTTP/1.1" 404 - "-" "Nextcloud Server Crawler"
... "HEAD /<dir>/ocs-provider/ HTTP/1.1" 404 - "-" "Nextcloud Server Crawler"
... "GET /.well-known/webfinger HTTP/1.1" 404 10094 "-" "Nextcloud Server Crawler"
... "HEAD /<dir>/core/fonts/NotoSans-Regular-latin.woff2 HTTP/1.1" 404 - "-" "Nextcloud Server Crawler"

Also, fwiw, is the following in Apache's error_log:

[proxy_fcgi:error] [pid ...] [client <serverIP#>:54070] AH01071: Got error 'Primary script unknown'

If you land here, please take troubleshooting queries to the help forum: https://help.nextcloud.com

EDIT: Some clarifications added to the Release Notes which some may find helpful: https://docs.nextcloud.com/server/latest/admin_manual/release_notes/upgrade_to_28.html#setup-checks

Well done :-)

Security & setup warnings It's important for the security and performance of your instance that everything is configured correctly. To help you with that we are doing some automatic checks. Please see the linked documentation for more information.

All checks passed. Check the security of your Nextcloud over our security scan ↗.

Version Nextcloud Hub 8 (29.0.0 beta 2)

Update Your version is up to date.

What did you do to solve the warnings?

In my case, based on the comment by SomeGuyInSandy above, I checked my /etc/hosts file. In my case, it had a mapping for the correct IPv4 address, but the IPv6 address mapping was wrong. So I fixed it.

My VPS is managed by cPanel. I don't recall having looked at my /etc/hosts before, although I'm sure I did when I was setting it up a decade ago. My best memory is that the errors started appearing with the previous NextCloud Hub release ... or perhaps the one before? I don't know if a cPanel update had made that /etc/hosts change to trigger the issue. Or it was a "sleeping" problem that surfaced when a change to NextCloud or some other system component made IPv6 usage more likely. Or it was actually wrong from Day One. Or some combination ...

My entries map to the public IP#s, not 127.0.0.1/::1. My NextCloud config.php refers only to the hostname in its trusted_domains setting.

Hope this helps.

I have my Nextcloud instance running on Docker. Recently, after a sudden server restart (hosted on-premise), the application is not resolving to the correct internal IP address.

Steps Taken:

Modified /etc/hosts to map the Nextcloud domain to the internal IP.
Adjusted netplan configurations.
Checked and allowed necessary firewall rules for Docker and the server.
Attempted to flush DNS caches using resolvectl flush-caches.

Despite these efforts, the issue persists. When pinging the Nextcloud domain from inside the server, it resolves to an incorrect external IP address.

Question: Could the incorrect resolution to the external IP address instead of the internal IP be causing the issue?

Additional Information:

The server is running on-premise.
The issue began after an unexpected server restart.
Modifications to /etc/hosts and netplan configurations did not resolve the issue.
Firewall rules have been reviewed and adjusted without success.
Environment:

Nextcloud version: 29.0.3 (Nextcloud Hub 8)
Operating system: Ubuntu Server 22.04
Docker version: 27.0.3

Any assistance in resolving this issue would be greatly appreciated.

Thank you.

@arioberek

@arioberek Please post your query on the help forum - https://help.nextcloud.com

This channel is for bug reports. Every time someone posts here it notifies all the developers, which isn't a good use for everyone's limited time and energy. :-) The Community Help Forum is a good spot for this sort of thing. Thanks!

I think this is related to server configuration, and not necessarily a bug. But it is a bit complex.

Since Docker was mentioned, I know these warnings can be caused by running Nextcloud inside a container without internet access — or, if you have specifically configured your container with a non-standard port, maybe because you have a proxy like Treafik handle actual 80 and 443 traffic externally. That is, if you get to see them at all, because ProxyTimeout (Apache) or proxy_read_timeout (Nginx) might kick in before PHP-FPM gets to even process all the checks! Probably due to silent HTTP timeouts, which the code might not check for or show an error message for.

I noticed the problem by manually requesting /.well-known/caldav in my browser, resulting in the request getting redirected to the non-standard port in the URI. e.g. :4000/remote.php/dav/ which is only used for internal communication between services. No wonder it was unable to resolve .well-known, because only port 80 and 443 is actually exposed to the internet via Traefik.

So, if that is a problem for you as well, then simply use the standard ports internally. It is perfectly possible to run your web server on the standard ports, if they are only exposed on the internal network, and still have another service like Traefik handle 443 and 80 traffic on the WAN.

For Docker, I think it is a good idea to have two networks configured in docker-compose.yml. E.g. One that is exposed to the internet, and another that's marked "internal". The internal one is only used for services that do not need internet access. Alternatively you could use expose instead of ports when configuring the service, as that would only expose the port internally. Or, maybe even a combination?

- expose:
  - "80"
  - "443"

Instead of:

- ports:
  - "80:80"
  - "443:443"

Long story short. Nextcloud needs internet for updates and to perform its checks. This means that your PHP-FPM container should at least have internet access, still while carefully making sure not to accidentally expose port 9000 directly to the internet. E.g. use expose instead of ports in docker-compose.yml afaik.

Navigation Menu

Repository navigation

[Bug]: There are some warnings regarding your setup (v29) #44114

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Installation method

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

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

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

using self singed cert. (Nextcloud vm test instance)

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: There are some warnings regarding your setup (v29) #44114

Description

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Installation method

Nextcloud Server version

Operating system

PHP engine version

Web server

Database engine version

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

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

using self singed cert. (Nextcloud vm test instance)

Activity

rchaconmolero commented on Mar 12, 2024

Githopp192 commented on Mar 13, 2024

Githopp192 commented on Mar 13, 2024

joshtrichards commented on Apr 2, 2024

rubo77 commented on Apr 30, 2024

rubo77 commented on Apr 30, 2024

t-h-e commented on May 14, 2024

4 remaining items

t-h-e commented on May 14, 2024

Ikestev commented on May 14, 2024

t-h-e commented on May 14, 2024

pravi commented on Jun 7, 2024

SomeGuyInSandy commented on Jun 20, 2024

bj-github commented on Jun 27, 2024

SomeGuyInSandy commented on Jun 27, 2024

bj-github commented on Jul 9, 2024

joshtrichards commented on Jul 10, 2024

arioberek commented on Jul 22, 2024

bj-github commented on Jul 23, 2024

arioberek commented on Jul 30, 2024

joshtrichards commented on Jul 30, 2024

Turbulentarius commented on Aug 19, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions