- Edited
Probably you updated from a much older release? Could be that the MariaDB upgrade did not go through properly.
See this issue and the linked one regarding MariaDB:
mailcow/mailcow-dockerized6429
English
Probably you updated from a much older release? Could be that the MariaDB upgrade did not go through properly.
See this issue and the linked one regarding MariaDB:
mailcow/mailcow-dockerized6429
I updated from the most recent release, as i always keep Mailcow up to date. Usually i do not update at the forst day but after a week or so.
What i did is export the database (with Adminer), stopped the mysql container, removed the contet fo the mysql volume, started the mysql container and imported the database export with Adminer. Everything went smooth, the Mariadb log reported nothing unusal. I cannot see a relation to the database why my Mailcow UI does not work anymore in the browser. E-Mail flows are still working. Nothing suspect in any logs.
How would i debug this animal further?
kingfisher What i did is export the database (with Adminer), stopped the mysql container, removed the contet fo the mysql volume, started the mysql container and imported the database export with Adminer.
Why did you do that?
I also always updated my mailcow on the same day when it shows it has a new update. So in my case also it was recent fresh update too. I also did not see any unusual in logs so I just rolled back it to legacy update. it’s good to know that I am not alone with this issue as @kingfisher user is also have the same setup like mine and having the same issue. If you get any solution to this issue please share the same with me too bro.
@esackbauer mentioned mailcow/mailcow-dockerized6429
I looked into index.php and have added this line at the beginning:
var_dump($_SERVER['DOCUMENT_ROOT']);
/web
was printed
until i added it under the line
require_once $_SERVER['DOCUMENT_ROOT'] . '/inc/header.inc.php';
After that it was not printed anymore.
I looked into index.php and have added this line at the beginning:
var_dump($_SERVER['DOCUMENT_ROOT']);
/web
was printed
until i added it under the line
require_once $_SERVER['DOCUMENT_ROOT'] . '/inc/header.inc.php';
From that line on /web
was not printed anymore.
kingfisher Did not get you here. Did it solved the issue?
No, it was just a message to describe that i try to solve the thing :-) index.php is “producing” the white page, because no content is beeing generated. I wanted to understand why. Better a Mailcow developer should have a look.
kingfisher mailcow/mailcow-dockerized6429 this was closed as completed but did not get anything out of it. Do we have to create a new volume for SQL and revert back?
mailcow-helper Do we have to create a new volume for SQL and revert back?
I don’t think so tbh
A pitty, Revision B did not solve our (my) problem.
mailcow/mailcow-dockerizedreleases/tag/2025-03b
kingfisher … haha thanks for the update. I will not try to update it now. Was just thinking to update it and your message came. Thanks a lot.
I am wondering how to debug this. I have another Mailcow with the same version which updated fine. The problematic one is from 2022. The good one from Mid 2024.
I compared a lot of settings, including database contents, with no obvious signs of a problematic source. I tried to understand what index.php does, but without a deeper understanding of the architecture, how everything is connected, I’m not very comfortable going in that direction. A bit out of ideas now.
I do not want to go back to legacy …
kingfisher I guess the problem with the installation from 2022 could be that you upgraded it in one single step instead of running the update jumping from version to version. This may have broken things.
Do you have a backup from before upgrading it?
DocFraggle I would not agree with my case here. I always upgraded my mailcow on the same night as soon as I see a new update. I have never missed any single update of mailcow.
@‘DocFraggle’#p23818 Ah, that’s a misunderstanding. It’s not the 2022 version, I’ve made every update since then. The database, all files are from 2022, and compared to the relatively new instance that has been well updated, that may be the source of the problem. Some kind of artefact from the ‘old days’.
I found out what the problem is/was.
In /opt/mailcow-dockerized/data/web/inc/
was a file called vars.local.inc.php
with this content
<?php
// mailcow Apps - buttons on login screen
$MAILCOW_APPS = "";
// Change theme (default: lumen)
// Needs to be one of those: cerulean, cosmo, cyborg, darkly, flatly, journal, lumen, paper, readable, sandstone,
// simplex, slate, spacelab, superhero, united, yeti
// See https://bootswatch.com/
// WARNING: Only lumen is loaded locally. Enabling any other theme, will download external sources.
$DEFAULT_THEME = 'lumen';
// Rows until pagination begins
$PAGINATION_SIZE = 100;
// Mailbox has POP3 access by default
$MAILBOX_DEFAULT_ATTRIBUTES['pop3_access'] = false;
Removing it solved the problem with blank page. I found it by comparing a working environment and and narrowing down everything with diff -r.
What is this file about?
kingfisher so you mean by removing the file blank page issue gone? Will have to figure out other causes of removal of the file that may come as well as the next update will bring back the file.
The file is not present on a fresh install on a separate computer. I think it’s an artefact from versions long ago.
kingfisher so if I remove the file and update it to the latest Moo update, will it start working fine?
Try it out!
It is an option to override web/inc/vars.inc.php
.
mailcow/mailcow-dockerizedblob/master/data/web/inc/vars.inc.php
Obviously i created it at 22.4.2022 :-)
-rw-r--r-- 1 root root 571 Apr 16 2022 vars.local.inc.php