Nextcloud mail docker dovecot


I am running mailcow in Docker and this features the possibility of running Nextcloud inside the Mailcow docker network.
I have Nextcloud sitting in the Nginx container, installed following the Mailcow documentation. In an extra docker container Collabora is running and that functions well with Nextcloud, cool btw.

Nextcloud mail either it tries to talk directly to Dovecot, or it does this using another container. Failure message is as follows, using the same settings I tried with Thunderbird (servername tried full dns name, single name, internal docker IP and LAN IP of the machine): "IMAP server is not reachable¨

Dovecot has the following port config (copied from the Portainer interface):

Port configuration 110/tcp
:::110 110/tcp 12345/tcp 143/tcp
:::143 143/tcp 4190/tcp
:::4190 4190/tcp 993/tcp
:::993 993/tcp 995/tcp
:::995 995/tcp

I can´t see if the above is blocking containers to access Dovecot (I am using all default IP adresses btw, and don´t understand the ::: rules in the above).
From within the ngynx container there is access over port 993, same for the PHP container (looking at some tips I found concerning running nexcloud mail with PHP).
Nextcloud mail is able to communicate with imap servers on the internet (so it works when talking outside).
I am also able to setup thunderbird email using imap to Dovecot from a laptop in the LAN.

I already found the following settings for Nextcloud, they had no effect when toggling:

‘allow_local_remote_servers’ => true,
‘app.mail.transport’ => ‘php-mail’,
‘app.mail.verify-tls-peer’ => ‘false’,

My questions:

  • Does anyone know how Nextcloud mail sitting in the ngynx container is trying to talk to dovecot?
  • How to open the correct ports for this to function in docker?
  • Is there something else to configure in Nextcloud mail in config.php or elsewhere what might help?


ummm… just for my better understanding: Why are you running NC in your NGINX-Container and not in an extra container by itself?

1 Like


Yes, the domain certs are auquired using the mailcow solution (letsencrypt). They made an integration for these parts, so it looked the most logical. Also all is accessed from the outside using the same set of ports, also resulting in potential conflicts.

I agree housing in nginx of mailcow also has challenges, maybe (but hopefully not) including this one.

Anyone any suggestion?
There must be something I could do to resolve or test this.

Not enough data delivered?

Please tell!

Pity, should expect there will be more small setups experiencing these symptoms.

I will stick with half the experience, without the mail client.

welcome to the community @roelofz :handshake:

your system is very “custom” :wink: this is a reason why you can’t expect many responses.

I’m wondering anybody is familiar with this docs… and I recommend you to stop using containers inside containers. the idea of containers is to have throw-away immutable objects which definitely doesn’t match with an approach to install additional stuff inside of the container.

this might look logical but results is issues nobody is willing to troubleshoot.

AFAIK the most common technology to run multiple services using same user-facing IP address/port combination is reverseproxy …many of them exist and work well with Nextcloud like apache nginx traefik caddy and you can choose the one you know or for any other reason.

The problem to differentiate different systems behind reverse proxy remains and you can choose different technologies - in my eyes using unique DNS name for every system is the best approach. Today when you get tls certificates from letsencrypt there is no additional requirement rather some additional DNS records (which you can add as CNAMEs for you existing DNS A-record pointing to your public-facing IP address). The reverse proxy in trun takes care of the TLS certificates and routes incoming traefik to the backend system according to the ruleset you define…

1 Like

It is not container in container, it is using Nextcloud inside the Nginx container as hostcontainer for the website Nextcloud. For me, I am no docker specialist, this looked as the most simple solution for allready having a acme client, acquiring certs and fitting it into a running environment. I also used more multi container setups, as this is also more common in docker (applicationcontainer connecting to database container for instance).

But looking at the answers, I am convinced this is a dead end as knowledge on this subject is missing here (no complaint btw, it is what it is, maybe have to look at more docker forums for inter container support).

If a proxy could help above the containers (so nginx rerouting to multiple web servers), maybe, but I am expecting more inter container traffix what is going wrong…

Puzzling and I will do some more testing…

Regarding testing I wonder if a Nextcloud setup is possible without external certs, as that is blocking good testing for me, being able to forward a port only once and not again to a testing vm…

Difficult to realize (port hussle), but I will start thinking about setting up a reverse proxy.

Thanks for the tip!

1 Like

I separated Nextcloud from Mailcow, using Traefik and thanks to my stubbornness I got it working (very bumpy ride ánd learning Traefik ánd learning that Nextcloud AIO works with one master container, spinning up siblings (beautifull concept, but I had to learn Traefik twice in notation)).

So if you need to split applications with Traefik up front, you need to focus on traffic rules in stead of container rules (big difference in Traefik).