Thanks for the important testing @Felix! I’ll try to reproduce and answer the points as soon as I can. Please just post more here, if you find anything else. Due to current workload, my answer could be a bit delayed.
1 Like
I solved issue 6 changing permission from 640 to 644 on these 2 files
chmod 644 /etc/roundcube/config.inc.php
chmod 644 /etc/roundcube/debian-db-roundcube.php
And for Issue 4 you can try change cert path editing VSFTPD config on server tab or using
nano /etc/vsftpd.conf
changing
rsa_cert_file=/usr/local/hestia/ssl/certificate.crt
rsa_private_key_file=/usr/local/hestia/ssl/certificate.key
to
rsa_cert_file=/home/admin/conf/web/hostname.domain.com/ssl/hostname.domain.com.crt
rsa_private_key_file=/home/admin/conf/web/hostname.domain.com/ssl/hostname.domain.com.key
Hi @donko
Thanks for your input! Currently I can’t recommed both of your ways for productive systems - with 644 you let every user read the php file, so basicly they could get now the db credentials from debian-db-roundcube.php - at leat when they have ssh with their user.
For vsftpd I think there is only a restart missing, both issues are currently in debugging. Pleae give us some additional time, we will get them solved for sure!
1 Like
Could you check, if a service vsftpd restart solves the issue? Probaly the service restart is missing the related v-script.
1 Like
Yeap! That’s it @ScIT ! Issue 4 resolved by restarting the service with service vsftpd restart 
Solution to Issue 6 by @donko also works! But I’m a bit worried about the security implications of giving read access to everyone on these files. Wouldn’t it be better to add the process/user accessing those files to www-data group?
1 Like
As I already wrote: not a good idea 
, we are already working for a solution.
www-data doesnt help, I’ll need to work with @lupu for a solution, it’s a issue due to the changed right management with fpm. webmail.domain.tld is working properly as you already mentioned.
Is it possible, that you added a domain without any subdomain/alias? For example just test.domain.tld instead domain.tld (with www.domain.tld as alias)?
Yes. There is no “www” alias. The test was done on the default WEB domain which is created automatically during installation. The FQDN of the server is like server.domain.com.
For issue 7 I have created this pull request
- Issue with phpMyAdmin
I’m checking phpMyAdmin at https://[SERVER-FQDN]/phpmyadmin. I was able to login as MySQL root user, but then I got those errors at the bottom of the phpMyAdmin page:
The configuration file now needs a secret passphrase (blowfish_secret).
The $cfg['TempDir'] (/var/lib/phpmyadmin/tmp/) is not accessible. phpMyAdmin is not able to cache templates and will be slow because of this.
First of all I need to mention that the URL https://[SERVER-FQDN] is using hosting nginx template + default apache template + PHP-FPM7.4 template. Now let’s move on to troubleshooting…
I can see in file config.inc.php line 34 there is a file that should be included (/var/lib/phpmyadmin/blowfish_secret.inc.php). This file contains the cfg setting for blowfish_secret (random alphanumeric and special characters). So in theory, it should work.
Then I noticed that if I create an new domain (xxx.yyy using default nginx template + default apache template + default php-fpm template) and then login at the URL https://xxx.yyy/phpmyadmin/index.php , I get no errors there! It still works even if I change web domain to hosting nginx template + default apache template + PHP-FPM7.4 template (as is the https://[SERVER-FQDN]/phpmyadmin).
So I guess this issue is kinda similar to issue #6. Permission issue maybe?
1 Like
Can confirm the php issues, we’re currently try to resolve this prior to the 1.1.0 release.
1 Like
Hello,
Issue 3: Confirmed.
Issue 6: I wasn’t able to replicate this (Ubuntu 18.04, nginx + PHP-FPM).
Issue 7: Will be amended at the next release, thanks for your contribution.
Issue 8: Confirmed, will be fixed at the next release.
1 Like
I just done a fresh install on fresh debian 10 install and am getting same errors?
thanks
Please open another thread and describe your issues.
Hello, i’m not sure if my problem is just the same or have relation to this. But i arrived to here trying to solving it and it worked also for me to run the command: service vsftpd restart
In my case it seems that the “Hestia” successfully updated Let’s Encrypt Certificates a month ago, but VSFTPD was using the old version of the certificate, so the FTP Client was alerting about an outdated certificate when connecting.
As i said, it got solved immediately manually running service vsftpd restart, but i think that there is some kind of “problem” here with the autonomous updating of the SSL certificates on VSFTPD.
Maybe i’m wrong… please i’m sorry if i’m talking about things that i don’t master yet 
Anyway, thanks!!
Uppsss… now, another server with Hestia has updated hestiacp version too, and the SSL certificate used for https://mydomain.com is DIFFERENT that the used with https://mydomain.com:8083 (hestia panel)… !! the second one is outdated.
In other words, the address https://mydomain.com is using a right certificate, but https://mydomain.com:8083 is using an expired certificate.
I don’t know if it’s due to the update of Hestia to v.1.4.11 just a couple of hours ago or due to the expiring of the SSL certificate JUST ALSO today (a few hours ago).
Obviously, the :8083 certificate has not been updated, while the main it does !? So i’ve 2 doubts: a) is it required to use 2 different certificates for 2 different ports?, b) in affirmative case, why Hestia has not updated the :8083 certificate?
Tell me if you need more info. I think that could be some kind of error on Hestia with the auto-update of certificates. Is it possible?
Please create a new topic it doesn’t make sense to update each one.
If you run v-add-letsencrypt-host it will create an ssl certificate for both “hestia” and nginx
1 Like