Yeah, I saw just as I pushed reply.
Then replace 8.4 with 8.3:
mkdir -p /etc/systemd/system/php8.3-fpm.service.d/
echo -e '[Service]\nReadWritePaths="/usr/share/phpmyadmin/tmp/"' > /etc/systemd/system/php8.3-fpm.service.d/override.conf
systemctl daemon-reload
systemctl restart php8.3-fpm.service
Everything worked fine. Sorry.
===
I think perhaps this fix needs to be made at the panel update level.
Let’s like this to enable the roundcube update to 1.7.X.
This is desperately needed!
I’ve created this PR to fix the issue with Hestia 1.9.5 and webmail ssl conf:
It would be great to release updates, say, every 14 days. Or, as needed, 15 or 20 fixes.
That’s not difficult. Or do the developers incur any financial costs when releasing updates?
I think 90 percent of people would even be willing to buy a paid annual subscription if that were the case.
Releasing updates with fixes is very important.
Dear developers, please reconsider your policy for releasing new versions of the panel!
I’m personally ready to deploy a test server. I have quite a few servers in production.
There are the same concerns about working with DNS and a remote database with SSO…
It’s so easy to fix, but no one’s doing anything about it.
I’m even ready to test it!
mkdir -p /etc/systemd/system/php8.3-fpm.service.d/
echo -e '[Service]\nReadWritePaths="/usr/share/phpmyadmin/tmp/"' > /etc/systemd/system/php8.3-fpm.service.d/override.conf
systemctl daemon-reload
systemctl restart php8.3-fpm.service
==
Is it possible to fix this with a global update?
It’s possible, but the problem is that every user has their own default PHP version, and users can change it whenever they want. Hestia should handle that.
The same issue happens with SnappyMail, and I created a PR to move the configuration from /etc to /var/lib. I think we should do the same for phpMyAdmin.
This should work fine, and we can avoid messing with PHP-FPM services.
mkdir -p /var/lib/phpmyadmin/tmp/
chown -R hestiamail:www-data /var/lib/phpmyadmin/tmp/
echo "\$cfg['TempDir'] = '/var/lib/phpmyadmin/tmp';" >> /etc/phpmyadmin/conf.d/01-localhost.php
I tried to do this, it doesn’t work. And I don’t use localhost either. Remote mysql servers. Only the first solution you provided helped.
It works fine in default installation. I don’t use it remote so I can’t test it and can’t provide a fix.
cat dummy.conf
; origin-src: deb/php-fpm/dummy.conf
[www]
listen = /run/php/php8.3-fpm.dummy.sock
listen.owner = hestiamail
listen.group = www-data
listen.mode = 0660
;“hestiamail” user created to prevent users from abusing this config
user = hestiamail
group = www-data
pm = ondemand
pm.max_children = 4
pm.max_requests = 4000
pm.process_idle_timeout = 10s
===
cat www.conf
; origin-src: deb/php-fpm/www.conf
[www]
;listen = 127.0.0.1:9000
;listen.allowed_clients = 127.0.0.1
;“hestiamail” user created to prevent users from abusing this config
;user = hestiamail
;group = www-data
;pm = ondemand
;pm.max_children = 4
;pm.max_requests = 4000
;pm.process_idle_timeout = 10s
listen = /run/php/www.sock
listen.owner = hestiamail
listen.group = www-data
listen.mode = 0660
;“hestiamail” user created to prevent users from abusing this config
user = hestiamail
group = hestiamail
pm = ondemand
pm.max_children = 4
pm.max_requests = 4000
pm.process_idle_timeout = 10s
==
I remember something changed in PHP. There were some fixes, but I don’t remember exactly. It was discussed here.
Thanks for all the replies. Good thing I turned auto updates off in time.
Curious how many servers are hitting the hestia repository every day and I’m assuming auto update is the default. As I am wondering how many servers are running an updated hestia cp.
I’m gonna wait till this gets settled out.
Will there be an update to this maintenance release that fixes the issues? Also, a lot of us have updated roundcube due to security issues. Hopefully any forthcoming update will account for that. Personally I stayed on the 1.6.x revision.
I see the branch on git had been open for awhile but I dont recall any call for beta testing but I probably just missed it. Post when the beta comes out that will support Debian 13 and I will help test it.
appreciate all the work on hestia cp
Just now, on a server without Apache and running nginx and php-fpm, the sites crashed after a control panel update.
The solution helped: Internal Server Error, something went wrong - #9 by sahsanu
Even phpMyAdmin doesn’t work. Apparently, this problem hasn’t been fixed…
sounds more like another issue with not properly customised templates.
the update might only be the trigger for rebuilding the web configs and if the templates have been fiddled with, this can cause issues of course.
yet the update process is not responsible for fixing or checking those templates.
this is just an assumption, feel free to give more information about the actual cause and what is in the logs about that 500 error.
Why change Hestia’s moedel into something it’s not? I personally love HestiaCP, but from all your comments I see littered across the forum, perhaps NodeWorx or CPanel is more your jam. You can pay monthly for licenses.
Hello everyone, before updating to the new 1.9.6 release, I wanted to do some research on the forum and I came across this post, where I read that the update introduces some bugs that still need to be fixed.
At this point, I would like to know whether these bugs have been resolved and if I can safely proceed with the update, or if it would be better to wait for a more stable version.
I have scheduled maintenance on my servers Debian 12 for tomorrow, but if you recommend waiting, I will exclude the HestiaCP update from this maintenance window.
Thank you all.
All known bugs has been resolved with 1.9.6.
thats great. So if I already updated roundcube to 1.6.16 by the method given here on the forum would everything still be ok ? I also have a custom nginx template that sets a 301 and proxy_pass with headers. thanks and I appreciate all the work
I updated 2 servers from 1.9.4. to 1.9.6 and it worked fine. Debian 12. thanks so much