Resolved SQL error breaking Plesk

[southy]

Hi all,

I'm not sure what I did, but probably trying to recover a Sitebuilder-Site from a backup without the respective key by manually copying the DB file into the MySQL directory (with Deamon stopped of course) broke something.
This _did_ in fact work out - the sitebuilder-sites are up and running on the server.

But: First I had the following error only when trying to do something with a sitebuilder-site (such as migrate to another machine).

SQLSTATE[HY000]: General error: 1017 Can't find file: './sitebuilder5/site.frm' (errno: 13)

now unfortunately my Plesk key has expired. When trying to install a new one, it always breaks with the same error code. Probably it checks the sitebuilder instance when installing a key.

The result is that the complete installation is not manageable any more - I can't install a key and I can't move the sites away from the machine.


Any ideas on how to fix this?


EDIT:
I forgot to mention that of course I checked the file listed above. It _is_ present in
/var/lib/mysql/sitebuilder5

-rw-rw----. 1 mysql mysql 14K 20. Dez 16:45 site.frm

Is there anything wrong with permissions or owner here?

 

[southy]

problem persisting.
Anyone any idea?

As I can't install a key, I can't do much with this installation. The websites are being served, but no one can log in.

 

[Lloyd_mcse]

What is the output of...

# ls -al /var/lib/mysql

Have you tried to run...

# plesk repair installation

Regards

Lloyd

Source: http://docs.plesk.com/en-US/12.5/ad...sk-administration/plesk-repair-utility.74649/

 

[southy]

Hi Lloyd,

thanks for your help.
I didn't know the "plesk repair" toolset - thanks for the good tip. However neither "plesk repair installation" nor "db" nor "web" nor "fs" finds anything. (only some bogus permissions in users dirs, somewhere completely different).

Content of /var/lib/mysql does include a "sitebuilder5"-directory and the file /var/lib/mysql/sitebuilder5/site.frm
_is_ present and not empty (binary).

/var/lib/mysql :

drwxr-xr-x. 27 mysql mysql      4096 11. Jun 20:17 .
drwxr-xr-x. 41 root  root       4096 11. Jun 03:34 ..
drwx------.  2 mysql mysql      4096 23. Dez 01:07 XXXXXXXX
drwx------.  2 mysql mysql      4096 23. Dez 01:03 XXXXXXXX
drwx------.  2 mysql mysql      4096 23. Dez 01:01 XXXXX_wordpress
drwx------.  2 mysql mysql      4096 21. Dez 13:17 apsc
-rw-rw----.  1 mysql mysql     16384 11. Jun 20:09 aria_log.00000001
-rw-rw----.  1 mysql mysql        52 11. Jun 20:09 aria_log_control
drwx------.  2 mysql mysql     12288 23. Dez 15:25 XXXXXXXXX
drwx------.  2 mysql mysql      4096 11. Mär 10:38 XXXXXXXX
drwx------.  2 mysql mysql      4096  7. Mär 10:36 XXXXXXXX
drwx------.  2 mysql mysql      4096 21. Dez 13:16 horde
-rw-rw----.  1 mysql mysql 278921216 11. Jun 20:21 ibdata1
-rw-rw----.  1 mysql mysql   5242880 11. Jun 20:22 ib_logfile0
-rw-rw----.  1 mysql mysql   5242880 30. Mai 03:25 ib_logfile1
drwx------.  2 mysql mysql      4096 29. Dez 23:46 XXXXXXXX
drwx------.  2 mysql mysql      4096 29. Dez 21:52 XXXXXXXX
drwx------.  2 mysql mysql      4096 23. Dez 01:05 XXXXXXXX
drwx------.  2 mysql mysql      4096 23. Dez 01:29 XXXXXXXX
drwx------.  2 mysql mysql      4096 29. Dez 19:35 XXXXXXXX
drwx------.  2 mysql mysql      4096 23. Dez 01:01 XXXXXXXX
drwx------.  2 mysql mysql      4096 23. Dez 01:18 XXXXXXXX
drwx------.  2 mysql mysql      4096 13. Apr 03:50 XXXXXXXX
drwx------.  2 mysql mysql      4096 23. Dez 01:21 XXXXXXXX
drwx------.  2 mysql mysql      4096 21. Dez 13:10 mysql
srwxrwxrwx.  1 mysql mysql         0 11. Jun 20:09 mysql.sock
drwx------.  2 mysql mysql      4096 21. Dez 13:10 performance_schema
drwx------.  2 mysql mysql      4096 21. Dez 13:17 phpmyadmin_2qAoE3ztTAwi
drwx------.  2 mysql mysql     12288 11. Feb 03:15 psa
drwx------.  2 mysql mysql      4096 21. Dez 13:13 roundcubemail
drwx------.  2 mysql mysql     12288 20. Dez 16:45 sitebuilder5
drwx------.  2 mysql mysql      4096  8. Mär 19:38 XXXXXXXX
drwx------.  2 mysql mysql     12288 23. Dez 01:29 XXXXXXXX

[root@XXXX~]# ls -la /var/lib/mysql/sitebuilder5/site.frm
-rw-rw----. 1 mysql mysql 13928 20. Dez 16:45 /var/lib/mysql/sitebuilder5/site.frm

Any other ideas?

Thanks again and have a good evening!

Southy

 

[Olray]

Please remove the sitebuilder5 directory, then go to mysql and issue "create database sitebuilder5;" so the database is known to mysql. Only then you may possibly be able to copy any files in there.
By just copying your files the file system is out of sync with the Mysql database.
For future reference, you shall only ever use mysqldump to create backups of your database, period.

 

[southy]

Sorry to warm this old thing up, but after it's been lying around for a while I re-visited the case and found the solution. In case someone comes across a similar problem, here is what to check:
After I quadruple-checked, it became apparent that there is definitely no problem with the privileges of the files in question.
As it's not the file system privileges, it occured to me that there is SELinux present on the system.
So check:

# ls -Z /var/lib/mysql
drwx------. mysql mysql system_ubject_r:mysqld_db_t:s0 any_other_DB_folder
drwx------. mysql mysql unconfined_ubject_r:admin_home_t:s0 sitebuilder5

Aparently the folder "sitebuilder5" has a different user as well as type than it should, so the MySQL deamon can not access it.
So you go:

# chcon -R -t mysqld_db_t sitebuilder5/
# chcon -R -u system_u sitebuilder5/

and then have:
# ls -Z /var/lib/mysql
drwx------. mysql mysql system_ubject_r:mysqld_db_t:s0 any_other_DB-folder
drwx------. mysql mysql system_ubject_r:mysqld_db_t:s0 sitebuilder5

That's it.

And by the way:
Yes, I do know that copying a DB directory is a bad idea. However I had no choice: these sites originate from a server with hardware damage to the hard drive, lots of data in the file system was damaged and I could only recover stuff from the file system manually, no chance to start the mySQL deamon to extract data via dump.

Problem solved, perhaps someone benefits from this.

BR,
southy

 

[Olray]

Yes, this is what I mentioned and it's unrelated to SELinux. By copying the files of the database directory /var/lib/mysql/* directly with file system commands you have f... up the file permissions and this is the main reason for always using MYSQL commands to manipulate MYSQL databases.

 

[southy]

Olray,
respecfully: you are wrong.
The file system permissions were totally fine.
If you check my last posting you'll see it's specifically the SELinux User objects that are off. Not the file system user.

You are of course right regarding that the reason is the same: manual copying.

But I did add this information in this thread to make someone else dealing with this problem becomes aware that they might not only need to check Linux file system permission, but also SELinux - which at least I had overseen as I simply didn't think of SELinux and as ist's not shown in standard "ls" command.