i try to install a new nextcloud instance on a debian vm in kvm behind an opnsense firewall.
the vm is reachable via one-to-one NAT in opnsense (so it has its own external ip), 80 & 443 is open to the public. itself can access http/https outgoing.
docker is installed via apt & the docker repos.
the first thing i stumble upon is that port 8080 - right after installation - is not http at all, its https:
Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Apache/2.4.57 (Unix) Server at localhost Port 8080
when i try on port 8443 i get the aio password (or better “got” - because all my tries resulted me running into LEs " Duplicate Certificate Limit" - will again try tomorrow).
i then can proceed to install the instance with $FQDN as domain and it seems to start up but nextcloud and (depending on that) apache will stay “Starting” forever (>1h).
The container must be able to talk to itself. So it is normal that it tries to do so. Possibly allowing these requests in your firewall will speed up the initial startup.
indeed, i misunderstood and overlooked that 8080 is ssl with a self-signed cert. thx for pointing that out. i can reach the aio UI now even without a valid LE-cert.
the second part - container try to talk with its own ip to the net - i should have formulated more carefully.
this line from the firewall log (without all that fancy html etc) …
tells me that the container wants to reach 104.154.207.153 which is not the external ip of the nextcloud VM but some address of google (153.207.154.104.bc.googleusercontent.com.)
the firewall (this is another machine) blocks this as all of 172.18… is unknown to him.
i guess the traffic should be masqueraded over the nextcloud VMs ip.
just to be clear: the VM itself has no problem at all reaching this and other adresses that 172.18… wanted to reach. also, the vm can reach itself via internal and external ip.
so i’m not sure what you mean by:
The container must be able to talk to itself. So it is normal that it tries to do so. Possibly allowing these requests in your firewall will speed up the initial startup.
do you mean the container must be able to talk to itself inside the containers host (the VM) or via the outside i.e. the internet ?
hmm i still think we miss each other - pls bear with me.
1st:
172.18.xxx is a private lan address so the container itself with its 172.18.xxx address could not possibly contact itself via the “internet” - at least not without masquerading on the outbound of the host (=where the containers run) and port-fowarding/DNAT on the inbound of the host (=where the containers run).
surely we could agree on that ?
2nd:
there should be never any instance of traffic from the containers un-masqueraded going outbound from the host - am i right or did i miss the usual workings of docker ?
If it cannot contact itself is something incorrectly configured in your network as this must work in order to make Nextcloud Office and Nextcloud Talk work correctly.
its your statement that the container has to talk to itself:
The container must be able to talk to itself. So it is normal that it tries to do so. Possibly allowing these requests in your firewall will speed up the initial startup.
my reasoning is that - if that would be the error - then it makes no sense that it trys to talk itself via messages to private lan addresses routed via the external interface.
from my point of view these messages are obviously in error and should be debugged - but this is a completely different issue and only came up as i debugged “that the container had to be able to talk to itself”.
lets make a step back:
aio is installed on a plain debian vm with nothing else on it
… enter my domain, check all boxes except “Nextcloud Talk”, hit start and after some time the web page shows that all is running except apache and nextcloud which stay “Starting”.
viewing the logs of nextcloud-aio-nextcloud gives …
I can only tell that I cannot reproduce your problem. Everything works perfectly on my test instance. So I dont know what is causing this on your side.
I’m getting this as well. Nextcloud AIO v5.1.0 running on Synology DSM 7.2 via a “Project” docker compose file. Hangs on Installing imagemagick via apk... just like tja’s example. All the other containers are up, and waiting for the nextcloud-aio-nextcloud container to do something. I’m wondering if maybe the imagemagick repository is down or such? Would it not time out? Can somebody tell me this repository so I can check connectivity?
I have all the IP v6 stuff commented out in the docker compose file.
I am using SKIP_DOMAIN_VALIDATION=true the same as @tja as I am expecting the reverse proxy will do all the certificate stuff. Not sure this would have any impact on it installing imagemagick though. Only commonality I can think of as we are on different platforms etc.
I went in and deleted all the Imagemagick environment variables reference and now it is running through the install, so there is definitely an issue with the installer connecting to the Imagemagick repository I think. Not sure how it’s going to run without it, but I’m treating this as a test system for now.
I did notice that both Apache and the domain validation container were trying to use port 11000 for some reason. The domain one died but I have it bypassed anyway.
Here is the netstat output though: