Niroda
commented
4 months ago Same ..
Closed SwissOS closed 4 months ago
Niroda
commented
4 months ago Same ..
MrBridgefarm
commented
4 months ago Login to the admin panel, show's only a white page on the debug page.
Then you change the link to /admin it shows errors..
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] => )
i've tried to re-install, no backup. Plain install on arm64 (Oracle) same error.
milkmaker
commented
4 months ago THIS IS A AUTOMATED MESSAGE!
It seems your issue is not a bug. Therefore we highly advise you to get support!
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.
SwissOS
commented
4 months ago "It seems your issue is not a bug." If it's not a bug, then what is it?
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.
MrBridgefarm
commented
4 months ago I don't get it, it was working fine on 24.04 but it's broken on 24.06 So it's clearly a big. As SWISSOS says try to install it on a arm64
I've installed it on a complete new vn on oracle no reverse proxy. Still same error. Arm is broken
psonntag1
commented
4 months ago I have the same issue on one of my machines after update to the latest stable version. Logging in with an admin account, the /debug page is empty and /admin shows the array error. If I login with a normal user account the GUI works just fine.
psonntag1
commented
4 months ago 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:
Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /web/debug.php:32 Stack trace: #0 {main} thrown in /web/debug.php on line 32
With adding a echo in debug.php
date_default_timezone_set('UTC'); -->> echo $container_info; $StartedAt = date_parse($container_info['State']['StartedAt']);
I receive the following hint:
Failed to connect to dockerapi port 443 after 14 ms: Couldn't connect to server Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /web/debug.php:33 Stack trace: #0 {main} thrown in /web/debug.php on line 33
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.
esackbauer
commented
4 months ago That sounds for me that something that was hot-fixed in 2024-06 broke the dockerapi integration: https://github.com/mailcow/mailcow-dockerized/issues/5924#issuecomment-2195095580 Maybe containers for ARM and x86 are a little different?
Magelo
commented
4 months ago 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.
psonntag1
commented
4 months ago In my case I was able to resolve the issue by removing the "search" option in /etc/resolv.conf
Magelo
commented
4 months ago 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] => )
Callahan78
commented
4 months ago same here after udate to 2024-06a I´ve rolled back for now and hope that a solution can be found
mendozal
commented
4 months ago I have the same situation on an ARM machine on Oracle Cloud. Same blank page and error message. It only started to happened after the 2024-06 update.
I temporarily moved to an x86 machine and it's working fine there.
sergedc
commented
4 months ago Same here on ARM machine on Oracle Cloud
If I add in debug.php: echo “Container Info: ”; print_r($container_info); // Print the entire container_info array for debugging
I get: "Container Info: Could not resolve host: dockerapi"
lpwoodhouse
commented
4 months ago Worked perfectly fine on v2023-12 but I am getting the exact same issue when I upgrade to 2024-06a OS Dist: x86 RHEL 8.10
webdev4u
commented
4 months ago 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
commented
4 months ago I get: "Container Info: Could not resolve host: dockerapi"
Still with the new 1.88 php-fpm image? A repull (docker compose pull) and a restart (docker compose up -d) is needed.
DerLinkman
commented
4 months ago @SwissOS Did your installation use IPv6? If not: Properly disabled like described here: https://docs.mailcow.email/post_installation/firststeps-disable_ipv6
SwissOS
commented
4 months ago Yes, it uses IPv6
vineethmn
commented
4 months ago Disabled : IPv6 --> Not Solved
Disabled: Search option in resolve.conf --> Not Solved
Revert the phpfpm version from phpfpm:1.88 to phpfpm:1.87 --> fixed the issue
DerLinkman
commented
4 months ago 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 :)
rbrunka
commented
4 months ago phpfpm:1.87 works. thx.
MrBridgefarm
commented
4 months ago @DerLinkman i've testet et with phpfpm:1.89 on oracle with ubuntu a total clean install. and it works.
pcace
commented
4 months ago Disabled : IPv6 --> Not Solved Disabled: Search option in resolve.conf --> Not Solved Revert the
phpfpmversion fromphpfpm:1.88tophpfpm:1.87--> fixed the issue
Hi, i think i am facing the same issue. how do i revert to that version?
thanks a lot!
DerLinkman
commented
4 months ago Closin it here as duplicate of https://github.com/mailcow/mailcow-dockerized/issues/5928
rbrunka
commented
4 months ago @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```
Green2Matter
commented
1 week ago Exactly same behaviour after updating to 2024-11. After changing 1.91 to:
php-fpm-mailcow:
image: mailcow/phpfpm:1.90it works as normal...
wrcno1
commented
5 days ago Exactly same behaviour after updating to 2024-11. After changing 1.91 to:
php-fpm-mailcow: image: mailcow/phpfpm:1.90it works as normal...
It works for me
Magelo
commented
5 days ago Exactly same behaviour after updating to 2024-11. After changing 1.91 to:
php-fpm-mailcow: image: mailcow/phpfpm:1.90it works as normal...
Replacing phpfpm:1.91 with phpfpm:1.90 is working for me too.
apio-sys
commented
5 days ago 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.
PseudoResonance
commented
5 days ago 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.
henningsieh
commented
5 days ago 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.
Hi, now we are a few updates later, we are at phpfpm:1.91:
php-fpm-mailcow:
image: mailcow/phpfpm:1.91
command: "php-fpm -d date.timezone=${TZ} -d expose_php=0"
depends_on:
- redis-mailcow
volumes:
- ./data/hooks/phpfpm:/hooks:Z
- ./data/web:/web:z
...The error '/debug' empty after update after executing "update.sh" is still not fixed.
Does anyone have recommandations on this?
ajnadox
commented
4 days ago Editing /opt/mailcow-dockerized/docker-compose.yml and changing line:
php-fpm-mailcow: image: mailcow/phpfpm:1.91
to
php-fpm-mailcow: image: mailcow/phpfpm:1.90
then saving the file and running ./update.sh again fixed the issue for me.
DerLinkman
commented
4 days ago 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....
henningsieh
commented
4 days ago 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.
EinPinsel
commented
3 days ago @DerLinkman Is there anything in particular which we can provide you with to get the root cause of that issue?
DerLinkman
commented
2 days ago 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.
ajnadox
commented
2 days ago just tested 2024-11a and it fixed the issue for me, running phpfpm:1.91.1 now. Thanks!
henningsieh
commented
1 day ago Can you confirm that the 2024-11a is not fixing the issue for you?
I can confirm the opposite.
just tested 2024-11a and it fixed the issue for me, running phpfpm:1.91.1 now. Thanks!
same for me here... 🎉
I've executed /opt/mailcow-dockerized/update.sh today morning and everything is back working just fine!
-- Just in case anyone wants to dig into this... here is my output, the solution must be included somewhere in any of the updated images. But anyway... many thanks @DerLinkman 🙏
DerLinkman
commented
1 day ago Just in case anyone wants to dig into this... here is my output, the solution must be included somewhere in any of the updates images.
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?
henningsieh
commented
1 day ago dashboard looks normal now again?
yes!
DerLinkman
commented
1 day ago No i mean the lower half where all containers are presented.
henningsieh
commented
1 day ago the lower half where all containers are presented
also, yes!
DerLinkman
commented
1 day ago Huh ok. Then it's fixed.
EinPinsel
commented
18 hours ago 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.
For me the update to 11a fixed it, and I can see all the containers. Good for me, bad for the root cause analysis :/
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: