Mailcow admin ui (/debug) empty after update #5927
Comments
|
Same .. |
|
Login to the admin panel, show's only a white page on the debug page. i've tried to re-install, no backup. Plain install on arm64 (Oracle) same error. |
DerLinkman
added
support
|
THIS IS A AUTOMATED MESSAGE! It seems your issue is not a bug. You can get support either by:
This issue will be closed. If you think your reported issue is not a support case feel free to comment above and if so the issue will reopened. |
|
"It seems your issue is not a bug." I had a perfectly working mailcow, did an update this morning and it stopped working. Is that not a bug? It's not like I tried to add some extra feature or something else; I am not asking for "support". I see other people have the same problem, so obviously not a lone case. Try to install it new on an Oracle ARM64 VM and report back if it works? You can get a free account, so you don't need to spend anything. |
|
I don't get it, it was working fine on 24.04 but it's broken on 24.06 I've installed it on a complete new vn on oracle no reverse proxy. Still same error. Arm is broken |
|
I have the same issue on one of my machines after update to the latest stable version. |
|
I narrowed it down a bit: After switching on DEV_MODE for php_fpm_mailcow in docker-compose.yml I get the following error after login: With adding a echo in debug.php I receive the following hint: So, connecting to the dockerapi container fails. Currently I have no idea why that happens. A workaround is to comment the whole container block (line 26-54) in data/web/debug.php. @DerLinkman I like to ask you to reevaluate your opinion regarding bug/support. |
|
That sounds for me that something that was hot-fixed in 2024-06 broke the dockerapi integration: |
|
After the june update, when you visit https://mailcow.url, it redirects you to https://mailcow.url/debug, which displays a blank page. However, if you manually replace /debug with /admin, you gain access to the configuration settings but not the desired information page. |
|
In my case I was able to resolve the issue by removing the "search" option in /etc/resolv.conf |
|
Removing "search" in /etc/resolv.conf is not working for me. trying multiple refresh of https://mailcow.url/debug, then replace debug by admin I see this: An unknown error occured: TypeError Object( [message:protected] => Cannot access offset of type string on string [string:Error:private] => [code:protected] => 0 [file:protected] => /web/debug.php [line:protected] => 32 [trace:Error:private] => Array ( ) [previous:Error:private] => ) |
|
same here after udate to 2024-06a |
|
I have the same situation on an ARM machine on Oracle Cloud. Same blank page and error message. I temporarily moved to an x86 machine and it's working fine there. |
|
Same here on ARM machine on Oracle Cloud If I add in debug.php: I get: "Container Info: Could not resolve host: dockerapi" |
|
Worked perfectly fine on v2023-12 but I am getting the exact same issue when I upgrade to 2024-06a |
|
In docker-compose.yml changed from image: mailcow/phpfpm:1.88 to image: mailcow/phpfpm:1.87 in php-fpm-mailcow service, than run docker compose up -d --no-deps --build and page is working again. |
DerLinkman
added
bug
and removed
support
Still with the new 1.88 php-fpm image? A repull (docker compose pull) and a restart (docker compose up -d) is needed. |
|
@SwissOS Did your installation use IPv6? If not: Properly disabled like described here: https://docs.mailcow.email/post_installation/firststeps-disable_ipv6 |
|
Yes, it uses IPv6 |
|
Disabled : IPv6 --> Not Solved |
|
Sooo... i've rebuild the php container on Debian 12 instead of Alpine 3.20 and reopened the ticket at Alpines Aport repo: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15690 If some one could test if this issue is fixed on phpfpm:1.89 it would be muchly appreciated :) |
|
phpfpm:1.87 works. thx. |
|
@DerLinkman i've testet et with phpfpm:1.89 on oracle with ubuntu a total clean install. |
Hi, i think i am facing the same issue. how do i revert to that version? thanks a lot! |
|
Closin it here as duplicate of #5928 |
|
@pcace the quick and dirty way is here: index 563144af..41d541b2 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -110,7 +110,7 @@ services:
- rspamd
php-fpm-mailcow:
- image: mailcow/phpfpm:1.88
+ image: mailcow/phpfpm:1.87
command: "php-fpm -d date.timezone=${TZ} -d expose_php=0"
depends_on:
- redis-mailcow``` |
|
Exactly same behaviour after updating to 2024-11. it works as normal... |
It works for me |
Replacing phpfpm:1.91 with phpfpm:1.90 is working for me too. |
|
I just upgraded my 2 instances to 2024-11 and didn't have any issue and no need to make the php-fpm modifications as suggested here. Maybe you have un underlying OS that doesn't support this? It shouldn't of course and even writing this I don't see how this can affect the U/G from working correctly... Anyway, for me, 1 instance on Ubuntu 22.04 and another on 24.04 upgraded just fine without any glitches. |
|
It was working for me for some time, then it broke when I restarted to get new certificates and never came back no matter what I tried, on Ubuntu 24.04. Brand new install of Mailcow on a brand new 24.04 VM. I had to revert the php-fpm version too, but I'm still not sure what caused it in the first place. |
Hi, now we are a few updates later, we are at phpfpm:1.91: The error '/debug' empty after update after executing "update.sh" is still not fixed. Does anyone have recommandations on this? |
|
Editing /opt/mailcow-dockerized/docker-compose.yml and changing line: then saving the file and running ./update.sh again fixed the issue for me. |
|
Only a workaround, we need to see what is causing this in the longrun. We cannot keep that forever as we miss os updates inside the container then. The plan is to release a bug fix update today which may fix this. As we cannot repro this anywere it is again, hard to debug.... |
|
Thanks for your response! Then I'll wait... If I can help with my hetzner VPS machine, on which this has happened today morning, please let me know. |
|
@DerLinkman Is there anything in particular which we can provide you with to get the root cause of that issue? |
|
Nope i'm afraid not. We still don't know what is wrong there. Maybe something dns related? Can you confirm that the 2024-11a is not fixing the issue for you? Ideally is, that all running docker containers in some kind allocated to mailcow are displayed in the debug page. |
|
just tested 2024-11a and it fixed the issue for me, running phpfpm:1.91.1 now. |
I can confirm the opposite.
same for me here... 🎉 I've executed -- update.sh console output |
Thanks... nothing new to me but i think it's because of the curl-dns module fix introduced in 1.91.1. Does your dashboard looks normal now again? |
yes!
|
|
No i mean the lower half where all containers are presented. |
also, yes!
|
|
Huh ok. Then it's fixed. |
For me the update to 11a fixed it, and I can see all the containers. Good for me, bad for the root cause analysis :/ |
and others
Contribution guidelines
I've found a bug and checked that ...
Description
This seems like a PHP error from my googling. I don't know where to look further though.
Any pointers?
Steps to reproduce:
Which branch are you using?
master
Which architecture are you using?
ARM64 (aarch64)
Operating System:
Ubuntu 22.04
Server/VM specifications:
24GB/4 cores
Is Apparmor, SELinux or similar active?
no
Virtualization technology:
none
Docker version:
27.02
docker-compose version or docker compose version:
2.28.1
mailcow version:
2024-06a
Reverse proxy:
Nginx (proxy_pass http://mailcowdockerized-nginx-mailcow-1:8080)
Logs of git diff:
Logs of iptables -L -vn:
Logs of ip6tables -L -vn:
Logs of iptables -L -vn -t nat:
Logs of ip6tables -L -vn -t nat:
DNS check:
The text was updated successfully, but these errors were encountered: