Hey @pkernstock ,
So I’ve backed up my Mailcow, restored it with a clean installation, and now everything except my SMTP configuration is working. 
Thanks for all the support you gave! Now I need to find out why my messages are not being delivered, but that’s another story.
We can mark this specific issue as solved. 
I’ve checked the “ghcr.io/mailcow/postfix-tlspol:1.0” and it seems it’s running on the amd64 architecture while I’m using an x86_64 Intel CPU.
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: GenuineIntel
BIOS Vendor ID: QEMU
Model name: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
BIOS Model name: pc-q35-7.2 CPU @ 2.0GHz
BIOS CPU family: 1
CPU family: 6
Model: 158
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
Stepping: 9
BogoMIPS: 6815.93Interesting suggestion. Thanks! I’m going to check how to change the architecture for the build and will keep you posted.
Hi all!
I’ve also been updating Mailcow and have encountered the issue of postfix-tls-pol restarting repeatedly. No problem, of course, because there’s a solution for that, which is manually building the postfix-tlspol image.
So I’ve executed these troubleshooting commands suggested by the Mailcow team:
docker build -t ghcr.io/mailcow/postfix-tlspol:1.0 data/Dockerfiles/postfix-tlspol
docker compose up -d
Unfortunately, I have received the following error for that: ERROR: failed to solve: process "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends \tca-certificates \tdirmngr \tdnsutils \tiputils-ping \tsudo \tsupervisor \tredis-tools \tsyslog-ng \tsyslog-ng-core \tsyslog-ng-mod-redis \ttzdata \t&& rm -rf /var/lib/apt/lists/* \t&& touch /etc/default/locale" did not complete successfully: exit code: 255
I’ve tried manually executing the commands Docker wanted to execute, but there’s no problem there. The output I’ve received is enclosed in this thread.
If anyone could help me with this issue, I would greatly appreciate it. 
Hey guys,
So I’ve been nosing a little more in the documentation and the .env file, and I see that the backup/restore directory Mailcow is asking for in their backup/restore script doesn’t really have any effect. It’s the MAILCOW_BACKUP_LOCATION key in the .env file that’s relevant to that script, which is my /tmp/ folder. (
Backup - mailcow: dockerized documentation) docs.mailcow.email
I’ve checked that folder, and all the manual backups I’m performing are being saved there.
So luckily, I’ve got a backup of Mailcow and now can continue. Thanks for all the support here! <3
Thanks for your swift answers!
Did you try running it from the /opt/mailcow-dockerized directory as ./helper-scripts/backup_and_restore.sh backup all?
Or as the full path to the script /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all?
I have just tried it, but unfortunately that didn’t work.
Did you edit the script?
Nope.
Do you run the script as root or using sudo? - Either should work, but unlikely to work as a regular user.
Yes, I ran it as root.
Did you export MAILCOW_BACKUP_LOCATION=“/your/backup/destination” before running the script?
No, I didn’t, but I did tell the script where the backup should be when being asked for it.
Are you checking the correct destination directory?
Yup!
Incorrect permissions on the destination directory?
I’ve created the directory as root and am executing the script as root. I guess that’s fine?
Insufficient space on the destination filesystem?
Nah.
Which log are you consulting? Perhaps you can share it?
I’m executing docker compose logs. This mostly shared the unbound-mailcow logs.
In addition to that: Last time I checked there was a bug in the backup script that demanded nonsensical permissions on the target destination. It wasn’t enough when only the executing user owned it.
IIRC incorrect (or “incorrect”) permissions terminate the script with an according message, though.
I’ll try this soon and will let you know how it went!
Hi all!
I’m using the backup_and_restore.sh script to back up everything my Mailcow server has. (to be precise, I’ve used: ./backup_and_restore.sh backup all)
Now, after the backup process has completed, everything looks fine… until I go to the backup folder, where I find nothing.
What could be the cause of this? I’ve checked the Mailcow log but found nothing of use at the moment.
DocFraggle Yup, with the help of the update.sh script. This unfortunately didn’t change the situation.
DocFraggle Hey DocFraggle! Again, thanks for your swift answer. You definitely deserve that “Moolevel 200”.
Do you have a special setup for you server?
Not that I know. I’m using the Mailcow Docker container, Caddy and Cloudflare for making this entire connection.
Any local firewall running on the host system which may block DNS requests from inside the docker network?
Nope.
The PITA-award-winning selinux enabled?
Yes, SELinux is enabled. Although the state of SELinux is permissive, it doesn’t enforce rules but gives warnings instead.
I do have some more information on this matter. The thing that broke Mailcow for me is my server only giving back an IPv6 address.
I’ve managed to give it an IPv4 address as well now thanks to this thread, but now I’m having that DNS issue: How do I make Ubuntu Server get IPv4 address?
Super User
Tagging @DocFraggle here as well. Maybe you know what I should do to debug this properly? Thank you! <3
It seems I’m also experiencing this issue at the moment after fixing my IPv4 issue: 
Unbound health check and IPv6 mailcow community 
At the moment I have no clue what to do. Maybe someone else has an idea what I can check before I might ruin things? 
For the people experiencing the same issue and being stuck with this issue as well - this is what helped me: How do I make Ubuntu Server get IPv4 address?
Super User
To be precise, the command is dhcpcd eno1 (eno1 is the name of my ethernet adapter)
Now I need to find a way to start this lease by default, because it seems it’s not happening by default at all…
Oh dear, that sounds pretty bad. I’m going to investigate how to have an IPv4 address as well then.
Thank you!
DocFraggle
Thanks for the swift answer!
I could do that, however it’s not recommended at all to do that. I thought maybe there would be a more clean solution.
Hi all,
My server doesn’t ping to IPv4 addresses anymore and only likes IPv6 from now on.
Now the unbound-mailcow healthcheck script only pings to IPv4 addresses at the moment.
Is there a way for me to adjust something within a config file to make sure these health checks are being done through IPv6?
Thanks in advance!