Fresh install - can't access Phpmyadmin

PHPMyadmin just won’t load. When trying to access the phpmyadmin page, it gives a took too long to respond error on multiple browsers. I’ve changed PHP versions to see if this would be the cause of it, however it isn’t so.

It is on a fresh install of HestiaCP, so not sure why it would fail.

It is not proxied on CloudFlare either. It does have a letsencrypt SSL generated on the backend though.

You need to change the owner of the phpMyAdmin files. I’m sure someone will be able to tell you the commands you need. I can’t remember what changes I needed.

I think you need the following commands:

chown -R root:www-data /etc/phpmyadmin/
chown -R hestiamail:www-data /usr/share/phpmyadmin/tmp/

This didn’t work for me, I tried rebuilding the users aswell. I’ve also verified the folders exist.

OK, on my system I have:

chown -R root:hestiamail /usr/share/phpmyadmin/tmp

I suspect you’re going to need a more experience Hestia user to help you, sorry!

I’ve done another clean install on the system, installed Ubuntu 22.04 and opened all the ports manually. Still cannot access phpmyadmin.

Disabling Letsencrypt seems to have fixed it, after which I ran into the Existing configuration file (/etc/phpmyadmin/ is not readable. and I fixed that by running chown -R root:www-data /etc/phpmyadmin/

How do I now get Phpmyadmin to work with Letsencrypt enabled? The templates are all default, nothing special has been done, it’s a fresh install.

@eris Any assistance will be appreciated

Use it should work fine…

Yes, this does work. I wanted to know how I could get the SSL to work with it?


That’s what I did to generate it in the first place and it stopped working after that.

I’ve done it again now and it’s back to “took too long to respond.” when trying to access phpmyadmin.

I’ve resolved it.

I thought it would be CloudFlare proxying, however it wasn’t being proxied so I ruled that out.

I even tried doing a strict SSL on a custom rule configuration for the hostname, but that didn’t work either.

I pinged the hostname and it was timing out, so I assumed some ports were closed. The port 80 was open, however 443 (SSL) and 21 (FTP) was closed. I totally mixed up 465 SMTP with 443 SSL. so I assumed that all the necessary ports were opened.

I ran a port scan using Port Checker - Check Open Ports Online for anyone that wants to do the same.

I also checked and ran an http-01 test against the hostname and it was giving me connectivity errors which. This helped me to see if the LetsEncrypt SSL was generated properly.

I also used SSL Certificate Checker - Diagnostic Tool | and SSL Checker to see if the certificates were using CloudFlare’s certificate or the LetsEncrypt one.

I ran the following commands in terminal

sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 21 -j ACCEPT
sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT
sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT
sudo netfilter-persistent save

Because the server is deployed on Oracle Cloud, I added an Ingress Rule (Virtual Cloud Network > My Server’s VCN > Default Security List) for ports 21, 80 and 443 with the following details:

Source CIDR:
IP Protocol: TCP
Source Port Range: All
Destination Port Range: 443

Source CIDR:
IP Protocol: TCP
Source Port Range: All
Destination Port Range: 80

Source CIDR:
IP Protocol: TCP
Source Port Range: All
Destination Port Range: 21