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?
Yes, it is working
Every container should have full outgoing Internet access, including external DNS resolution.
Please read here: https://docs.docker.com/network/drivers/bridge/.
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.
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.
It’s on a VMware physical host in my garage, so I can vouch for the details of the entire hosting and network config.
I’m loath to just wipe this one as a test; I’ll set up another one on a different domain and see if it acts differently.
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.
The IPs are fine; they’re allocated directly, not assigned by an ISP, and are routed to my local net via tunnel so the ISP isn’t involved at all.
(Plus, the problem is entirely inside the docker host anyway; getting to stuff outside the host works fine.)
Virtual provider and IP filtering must be a pretty common problem.
It was this; the script that I used to setup snmpd ran ‘ufw enable’ when it was setting up the allows rules for my librenms server to poll it.
ufw allow from 172.16.0.0/16
and mail from welcome.$DOMAIN is working now. I’ll tune that down later once I’ve identified all the local IPs docker is generating.
Now I just have to figure out how to disable the ‘request an invite’ from welcome.$DOMAIN and it shoukd be done.
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.
How did you install LibreNMS?
You may find these projects of interest, at least their README: https://github.com/chaifeng/ufw-docker & https://github.com/shinebayar-g/ufw-docker-automated.