Zammad can’t communicate with external systems (Univention Docker-App)

  • Used Zammad version: Univention Docker-App (3.0.0-9)
  • Used Zammad installation source: (source, package, …)
  • Operating system: Univention Corporate Server 4.4-1 errata196.
  • Browser + version: Firefox 68.0.1 on Windows 10 (1809) x64

Expected behavior:

Connect Kopano Mailserver on a different machine on the same subnet and send some test-mails.
I use Port 587 as I want to use tls.
I tried using DNS and IP-address also using port 25. the same connection works on OTRS.

Actual behavior:

“Host not reachable”
there is an entry on this error but the “fix” (restart docker-app) isnt’ working for me:

Steps to reproduce the behavior:

Install two UCS. one with Kopano, one with Zammad, try to add mail-sending kopano-account to Zammad.

Additional Info:

I’m able to replicate LDAP-users when connecting directly to the host where the docker lives… but I don’t want to install Kopano on the same host…

As I really want to try it I installed it on my mail-server now.

We have the same problem (cross-post from UCS forum).

We installed Zammad on an UCS master. It start properly, but it can’t connect to external systems. It can neither connect to the UCS LDAP server (on the same machine), nor to an external mailserver. The error message is:

An error occurred: Can't connect to '' on port '7389', getaddrinfo: Temporary failure in name resolution

For the mailserver it’s also getaddrinfo: Temporary failure in name resolution.

It is mentioned here that this may happen, but for us a restart of the app does not help.

No idea if this is the correct way to check it on the command line, but it also fails:

root@univention:~# docker exec zammad_zammad-railsserver_1 ping
ping: Temporary failure in name resolution

That’s odd. I had this issue exactly once during my test phase and never experienced it again. :frowning:

You can lookup the hostname on the host the container runs on, right?
(Please also note that ping uses /etc/hosts first for resolution which might backfire)

We had two problems with our UCS / Zammad installation:

  1. We chose a zone that is managed by another nameserver, disabled the nameserver on the UCS machine and deleted the zone (this UCS master is only for Apps and user management). The name resolution worked again after re-adding the zone and starting the nameserver.

  2. Since Zammad is a multi-container App, it uses docker-compose and creates a new bridge for its networking. For some reason the bridge did not masquerade the source IP, so packets were only sent, but the recipient didn’t know the right IP address for replying. The following command fixes this until the next reboot:
    iptables -t nat -A POSTROUTING -s ! -o br-dc172dbdd5ba -j SNAT --to-source
    I think this is also fixed now via


thank you very much for the follow up!
Great that UCS handles it directly instead of us forcing it onto. I think that’s the better approach. :slight_smile:

Okay, would you agree that your first point is an edge case?
Or is this a common option? If so, I’d need to test this completely through.

I mean it’s possible I simply don’t see all valid use cases. :slight_smile:

Yes, the first point is an edge case that is not recommended by UCS. So in my opinion there is no need to test this through completely.

Thank you very much for your Feedback and clarification. :slight_smile:

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.