Web server can connect to itself.

[ztaylor100]

Hello--

I have been self-hosting Nextcloud servers for about 5 years now but this is the first time trying out the AIO using docker on Ubuntu 24.04 LTS. The deployment went fine following the official guide here however, I have a ton of warnings all related to the web server not being able to connect to itself. Here's what I did to troubleshoot:

• curl -I https://nc2.mydomain.com from server and outside of docker --Succeeded
• curl -I https://nc2.mydomain.com from inside of docker --Failed
• curl -l https://www.google.com (or any other server besides this one) from inside of docker succeeds
• Ping and nslookup of nc2.mydomain.com from inside of docker both succeeded
• Disabled the ufw on server to test and same results

This all indicates that there is no issue with my DNS, NAT or firewall from the server perspective, but rather that something is blocking the url on 80 and 443 from inside of docker. I do have a hairpin NAT rule set up on my main firewall as mentioned in another post regarding the same issue. If it wasn't working, I would not be able to curl from outside of docker.

Any help figuring this out would be greatly appreciated. I searched for a few hours and found a lot of people with the same issue but no resolution so far.

Regards,
Zach

Here are the current warnings:
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 Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its trusted_domains or the overwrite.cli.url. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
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.
Unable to run check for JavaScript support. Please remedy or confirm 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 Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its trusted_domains or the overwrite.cli.url. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
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 Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its trusted_domains or the overwrite.cli.url. This failure may be the result of a server-side DNS mismatch or outbound firewall rule.
7 errors in the logs since February 19, 2025, 6:01:11 PM
One or more mimetype migrations are available. Occasionally new mimetypes are added to better handle certain file types. Migrating the mimetypes take a long time on larger instances so this is not done automatically during upgrades. Use the command occ maintenance:repair --include-expensive to perform the migrations.
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 Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its trusted_domains or the overwrite.cli.url. This failure may be the result of a server-side DNS mismatch or outbound firewall rule. For more details see the documentation ↗.
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 Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its trusted_domains or the overwrite.cli.url. This failure may be the result of a server-side DNS mismatch or outbound firewall rule. For more details see the documentation ↗.
Could not check for otf loading support. Please check manually if your webserver serves .otf files. To allow this check to run you have to make sure that your Web server can connect to itself. Therefore it must be able to resolve and connect to at least one of its trusted_domains or the overwrite.cli.url. This failure may be the result of a server-side DNS mismatch or outbound firewall rule. For more details see the documentation ↗.
Could not check that your web server serves security headers correctly. Please check manually. For more details see the documentation ↗.

[webkp]

I had a similar problem and for me the issue came from an entry in /etc/hosts (on the host) pointing nc2.mydomain.com to 127.0.0.1
(#1358)

Additionally in my case:
Due to a cloud template, the entry was added again every time I rebooted the VM so additionally I had to adjust the stock template on the VM.

[ztaylor100]

Removing the fqdn from the /etc/hosts file on the server fixed it however, when I went to re-deploy the Docker AIO, it was no longer able to obtain a public certificate. So, I had to put the entry back, deploy the containers, and then remove the entry after deployment. This will obviously cause issues when it comes to renewing the cert or even updating

Anyone have any ideas? Do I need to add an entry in the hosts file that also points to the container IP?

[ztaylor100]

Can someone please provide the contents of /etc/hosts and /etc/hostname on a fully working AIO deployment on Ubuntu?

[ztaylor100]

This has been resolved by editing the following files:

• 127.0.0.1 localhost in the /etc/hosts file
• Remove any hostname and/or 127.0.1.1 entry from the /etc/hosts file
• Have FQDN i.e., nextcloud.myserver.com in the /etc/hostname file