Update of Hestia on a Ubuntu Server 22.04.5 from 1.9.9 straight to last 1.10.4 has somehow done something to webmail/roundcube installation, not working for any domain in server.
Unluckily nothing is logged at error logs of apache2, ngnix and roundcube. Simply nothing recorded, and webpage only shows “Oops… something went wrong!”
“v-sys-add-roundcube” does not proceed as it is in current version 1.7.3 (not sure if there is a way to force a reinstall?)
Also tried to rebuild mail domains, checked owners of roundcube folders (hestiamail:www-data) and restart apache2 and ngnix services.
I’ve read and tried fixes from these two recent threads:
Unfortunately, not working for me
Has anyone a clue of what could have gone wrong with this update of hestia/roundcube?
PHP 8.5.10 (cli) (built: Aug 28 2026 06:45:57) (NTS) Copyright (c) The PHP Group Built by Ubuntu Zend Engine v4.5.10, Copyright (c) Zend Technologies with Zend OPcache v8.5.10, Copyright (c), by Zend Technologies
and
Loading composer repositories with package information Updating dependencies Nothing to modify in lock file Writing lock file Installing dependencies from lock file Nothing to install, update or remove Package pear/net_socket is abandoned, you should avoid using it. No replacement was suggested. Generating optimized autoload files 9 packages you are using are looking for funding. Use the composer fund command to find out more! No security vulnerability advisories found.
Everything seems in order.
Additionally, /var/log/nginx/error.log has no related entries, all /var/log/nginx/domains/webmail*.error.log files are empty.
BTW, thank you very much for your quick reply and help, really appreciated.
For me, I got an issue during the post-install phase of installation:
[ ! ] Upgrading Roundcube to version 1.7.3... Warning: Failed to update Roundcube modules To investigate the issue, run: COMPOSER_ALLOW_SUPERUSER=1 "/usr/bin/php" "-d disable_functions=" "/home/admin/.composer/composer" --working-dir="/var/lib/roundcube" update --no-dev --no-interaction --optimize-autoloader
Doing that, it complains about upgrading guzzle.
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Root composer.json requires guzzlehttp/guzzle ^7.10.0 -> satisfiable by guzzlehttp/guzzle[7.15.2, 7.15.3, 7.15.4, 7.15.5].
- guzzlehttp/guzzle[7.15.2, ..., 7.15.5] require symfony/deprecation-contracts ^2.5 || ^3.0 -> found symfony/deprecation-contracts[v2.5.0, ..., v2.5.4, v3.0.0, ..., v3.7.1] but it conflicts with your root composer.json require (2.2).
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems.
cool that completed successfully, should the file ownership be changed to hestiamail:www-data following this process? as the new files are root:root currently.
I’ve double checked that Apache2 main error log has no event recorded after several webmail internal server error hits. And there are no webmail*.error.log files in domains log folder.
Aside from that, update installation log received by email had these four lines labelled with an exclamation mark:
[ ! ] Updating default mail domain templates... [ ! ] Upgrading Roundcube to version 1.7.3... [ ! ] Error upgrading Roundcube 1.7.3 [ ! ] Update Hestia PHP dependencies...
I can’t figure out what could have gone so wrong with Roundcube update or how to bring it back on live -_-
RainLoop Webmail cannot access to the data folder "/var/lib/rainloop/data/"
Now /var/lib/rainloop/data is a symlink owned by www-root:www-root, pointing to /etc/rainloop/data I have tested that hestiamail user can indeed write to that directory.
Running php interactively as the hestiamail user and testing the snippet of code which tests for the issue in rainloop doesn’t show the problem… so I’m a bit stumped.
It’s been a while since rainloop was replaced by snappymail. We have moved /etc/snappymail/data to /var/lib/snappymail/data (in your case it is rainloop).
It doesn’t matter, since a few versions ago, PHP systemd service, doesn’t allow to write in /etc/ (even if the user has access), and that’s the reason we did the move to /var/lib/
You should have a really old installation, the alternative rainloop webmail was replaced by snappymail… and in a near future, it could be replaced by tachyon. But for now, just move the data dir.
Only 4 years, installed Nov 2022! I was able to get rainloop going again, and install snappymail via the cli tool. There is no v-delete-sys-rainloop so I guess I’m stuck with that still.
I will be migrating to a new host at some point in the next year with Ubuntu 24/26 LTS so it’s probably fine
Here is the output
to