In my fresh install, the nextcloud and welcome sites can’t send email.
They come preconfigured to send via mail.$DOMAIN, and are preset to resolve that name to the server’s external IP.
I am no docker expert, but as far as I can tell from much web searching, it’s actually impossible for a docker container to contact another container via the public IP; they have to use the docker internal network.
This is at least partially true, since running nc in the containers’ namespace fails to connect.
When I change /etc/hosts to point that name to the internal IP, nc connects but the nextcloud email test times out (rather than failing immediately, as it does in the default setup) as does the welcome site.
This isn’t a huge deal, since I changed nextcloud to relay through my prexisting mail server and I don’t want self-registration anyway, but maybe welcome needs to send email when the user accepts a shell-generated invite?
Is the out-of-the-box install really working for everyone else?
You can use docker network ls to check that you’re using the “bridge” driver, docker network inspect repo-base_default to check Docker networking.
Also, did you install your self-hosted on a brand new server as advised, or an existing one? Does your server have a public, non-residential, dedicated IP address, with reverse PTR to it? Do you by any chance have some kind of filtering (iptables, ufw, …) enabled?
It’s a freshly-built VM, running Ubuntu 22 (fully updated before the Murena install). I made no additions other than snmp for my LibreNMS to monitor it. I’ll look at my snmp setup script; it does touch firewall settings.
The IP is clean; it’s allocated directly from ARIN, not assigned by an ISP. No one else has ever had this netblock, and I’m even pretty sure I’ve never assigned this particular IP to a machine before.
All the DNS records are as described in the install doc and as output by the install script.
The containers can all get out fine and can talk to each other on the docker bridge network (barring what seem to be certificate errors when they try to use SSL there); it’s only accessing the other containers via host’s IP that’s problematic.
And to not be able to talk to each other via the host’s IP seems to be the expected thing anyway, as far as I can tell but the install script has set them up that way.
I’ll read some more on docker’s networking and see if I can get them to talk on the internal network correctly.
I think that there is something wrong with your VM . Would you mind sharing how it is hosted, especially the provider?
Some providers may block some traffic by default, see for example Linode.
Using a freshly installed self-hosted at Hetzner (CX21), I can confirm that access from a Docker container to mailserver container using the public IPv4 address is working fine.
I used nc -v mail.DOMAIN 587, replacing DOMAIN with the actual value), and could “talk” to my self-hosted ESMTP service. Nc did resolve the name to the public IPv4 address.
Please make sure with your ISP that there is no filtering…
Also, even if you make it to work, the address range you use may be flagged as “residential” and cause problems with emails.
It’s strange… Normally, Docker adds iptables rules automatically when starting containers (ufw also relies on iptables, it’s just some kind of extra layer on top of it).
In other words, unless something added an explicit deny in your ufw rules, it shouldn’t have any effect on Docker networking.
. Would you mind sharing how it is hosted, especially the provider?