A failed setup to a new box

OS type and version Ubuntu 22.04LTS
Virtualmin version 7.5

I am hoping this is not a big deal. I had a server that for some reason would no longer run bind, no longer run mariadb. It was on a linode Debian image. I spun up a new ubuntu 22.04LTS box and decided to install virtualmin this way on a new install. I was able to do that, I recreated all the virtual sites. I then went ahead and I pulled the old /var/lib/mysql directory and then I stopped maria, backed up the original folder, then went ahead and uploaded the old mysql folder. I then started maria and it didn’t give me any errors and showed running. I have 2 out of 3 wordpress installs that have come up and they run. The one website just keeps giving me a redirect error. I’m not sure if its related or not but I am putting in out there. I went ahead and made sure the owner of the database files matched to what they should be with the owner being the same name as the user for the virtualsite. However, within virtualmin if I hit edit database I get

Fatal Error!
You do not have access to this MariaDB database

If I try to access maria via cli I get.

root@webserver:/home# mysql
ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: NO)
root@webserver:/home# mysql -u root
ERROR 1045 (28000): Access denied for user ‘root’@‘localhost’ (using password: NO)
root@webserver:/home# mysql -u whitekidsoncomputers
ERROR 1045 (28000): Access denied for user ‘whitekidsoncomputers’@‘localhost’ (using password: NO)
root@webserver:/home# mysql -u whitekidsoncomputers -p
Enter password:
ERROR 1044 (42000): Access denied for user ‘whitekidsoncomputers’@‘localhost’ to database

I’m not sure what other steps I might need to complete here to fix the maria permissions issues so that I can go ahead and get everything fully recovered. I still have the old server in an off state at the moment. Any insight would be great!

Maybe you should fix the first server, did you post the errors on the forums?

why did you not use the virtualmin restore function ?

1 Like

Why on earth would you ever do that?

You copied an entire directory from a failed server and uploaded it into a new one? Especially when it’s two completely different data server types? (MySQL to MariaDB)

All you need are the databases. You should have exported the databases or simply backed them up and then use those on the new server by importing them via the import database dialogue.

MariaDB goes to the mysql directory thats why.

MariaDB will not start on the old server. I never posted here about it. Maria on the old server when trying to start complains about permissions even though nothing was changed. The box won’t do an update or anything.

root@webserver:~# systemctl status mariadb.service
● mariadb.service - MariaDB 10.3.36 database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2023-02-06 14:57:16 UTC; 2s ago
     Docs: man:mysqld(8)
  Process: 5640 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
  Process: 5641 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 5643 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS)
  Process: 5693 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=203/EXEC)
 Main PID: 5693 (code=exited, status=203/EXEC)

Feb 06 14:57:15 webserver systemd[1]: Starting MariaDB 10.3.36 database server...
Feb 06 14:57:16 webserver systemd[5693]: mariadb.service: Failed to execute command: Permission denied
Feb 06 14:57:16 webserver systemd[5693]: mariadb.service: Failed at step EXEC spawning /usr/sbin/mysqld: Permission denied
Feb 06 14:57:16 webserver systemd[1]: mariadb.service: Main process exited, code=exited, status=203/EXEC
Feb 06 14:57:16 webserver systemd[1]: mariadb.service: Failed with result 'exit-code'.
Feb 06 14:57:16 webserver systemd[1]: Failed to start MariaDB 10.3.36 database server.

Is what I got, I then tried editing the service file with other suggestions online but non work. I chmod the file it mentions to 777 thinking that would get it to stop but it still says the same thing. The only way I could seem to pull the data with the database not working was to copy this directory over and start mariadb.

You generally can’t do that.

You have to dump/restore. If you can’t dump on the old system because Mariadb or MySQL isn’t working, you’ll have to fix it there, so you can perform a dump.

You cannot copy the binary database files to a different version of the database (even if both are MariaDB, different versions are still not guaranteed to be binary compatible and you’d want to dump/restore the databases).

1 Like

That is never the right thing to do. Literally never.

1 Like

correct, you shouldn’t put a 777 on a file, I understand that but when it says permissions error and I’m trying to confirm a permission issue a 777 is a quick check to see if it works. You say you can’t just copy over, if that is the case then why do the sites actually load? Why does mariadb start with no problems? If I could get mariadb to run on the old server and dump I would, I have spent hours trying to get it to work but it has not worked. I would much rather of had the virtualmin move and restore to the new server, that would of been great.

If this is a database permissions issue? Perhaps check to see if the user has the proper rights to the database and using the correct password.

Then you have to fix that before you do anything else.

I’ve still been trying to get it to run with no success. its one error after another. I’m just rolling through every potential way to get the issue resolved and running on a new box.

I have been able to resolve the issue and have been able to migrate the database over. Due to the box being in the state it was in this was resolved by spinning up a debian 10 image, installing mariadb, stopping mariadb service, dropping in the mysql folder, chown -R mysql:mysql, run maria with skip-grant-tables, change root password, disconnect and kill pid. Start mariadb service again and dump the tables needed. Then restore into new instance.


Thanks for following up with your solution. I’m glad you got it sorted! Sorry we didn’t have easy answers for you.

That’s a lot of hoops you jumped through. Well done.

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.