The Basics
- Nextcloud Server version (e.g., 29.x.x):
32.0.5
- Operating system and version (e.g., Ubuntu 24.04):
cat /etc/debian_versiongives: 12.11
- Web server and version (e.g, Apache 2.4.25):
apache2 -vgives: Apache/2.4.62 (Debian)
- PHP version (e.g, 8.3):
php -vgives: PHP 8.2.28
Log entries
Nextcloud
The downloaded log from Administration settings->Logging screen is HUGE. Essentially there are several
cURL error Could not resolve host:
and then followed by some
cURL error Failed to connect
Web server
Debian with apache2, Nextcloud installed natively. (No docker etc)
Server in a DMZ, behind a firewall (IPfire with the NC local IP in the hosts file); NAT configured to forward HTTP and HTTPS to the server in the DMZ. WebAccess, WebDAV, Bookmark sync, Desktop clients in various PCs, etc. all working just fine from the Internet and LAN (Green network in IPfire terms). No known problems from the user-side.
Nextcloud
The output of sudo -u www-data php occ config:list system :
{
"system": {
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"www.myserver.com",
"192.168.1.1"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "32.0.5.0",
"overwrite.cli.url": "https:\/\/www.myserver.com",
"overwriteprotocol": "https",
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"installed": true,
"maintenance_window_start": 1,
"default_phone_region": "ch",
"maintenance": false,
"mail_smtpmode": "smtp",
"mail_sendmailmode": "smtp",
"mail_from_address": "***REMOVED SENSITIVE VALUE***",
"mail_domain": "***REMOVED SENSITIVE VALUE***",
"mail_smtpauthtype": "LOGIN",
"mail_smtpauth": true,
"mail_smtphost": "***REMOVED SENSITIVE VALUE***",
"mail_smtpport": "587",
"mail_smtpname": "***REMOVED SENSITIVE VALUE***",
"mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
"theme": "",
"auth.webauthn.enabled": false,
"loglevel": 0,
"memcache.local": "\\OC\\Memcache\\APCu",
"updater.release.channel": "stable",
"app_install_overwrite": [],
"mail_smtpsecure": "ssl"
}
}
Summary of the issue:
Not sure whether it appeared earlier, but I noticed it during the update 31.0.5 > 31.0.13 > 32.0.5.
In the admin interface > Administrative Settings > Overview. When the “Checking your server …" is done I get several warnings/errors that the “Web server can connect to itself”.
So I tried to investigate what is wrong. Somehow it seems that the server cannot always reach itself, so I setup a watch command on the servers CMD-line to see whats going on:
watch “curl -I https://www.server.com/nextcloud/index.php/heartbeat”
Now, after I open the Overview (which triggers the server “to check itself", the above curl command - reproducibly - suddenly gives a “Failed to connect" (basically a 404).
However, after a while (~10minutes ?) the curl command again works fine (I get code 200 and the header).
So, then it looks again all good. The server can reach itself using its FQDN, and one may assume that the “selfcheck" should also work just fine. BUT, as soon as I open the Overview again, which triggers the selfcheck again, the curl command suddenly gives a “Failed to connect" (= 404) again. Which then obviously leads to the self-check giving several errors/warnings due to being unable to reach itself via its FQDN.
So. First I though there’s something wrong with my firewall, or the NAT setup. But observing the situation, I get the feeling that the Nextcloud might be doing something odd. Maybe flooding the firewall, or some odd request? Because: How come, that the curl -I command is just fine (=the server can reach itself via its FQDN giving code 200), until the selfcheck is triggered???
Somehow the selfcheck leads to a situation where the server suddenly cannot reach itself anymore via its FQDN. And subsequently the self-check generates quite some output…
Hence, before I start to use wireshark an reverse engineer the whole procedure, I wonder if someone has in-depth-knowledge of the “self-check" and can tell me what exactly is happening there. I am pretty lost here, and I am afraid that the firewall-support says “that’s a nextcloud problem”, while the nextcould side may say “that’s a problem with your firewall”.
Hence, I try to understand both sides better to find out what it the actual root cause.
Any help would be greatly appreciated. If further infos are required, just ask (ideally let me know where or how to obtain).