After upgading MySQL to newer version I have error when I want to connect to server:
ERROR 1524 (HY000): Plugin '0' is not loaded
Any ideas?
This looks like a Bug in MySQL as Bug #60432
Modifying mysql.user table can deny users from logging in . Which states that:
If database manager accidentally (or deliberately) modifies mysql.user
table by adding any column in position lower (or equal) than
"max_user_connections", then after reloading privileges no one is
allowed to log in.
Workaround: Undoing the modification made in user table.
Run following commands
sudo /etc/init.d/mysql stop
sudo mkdir -p /var/run/mysqld; sudo chown mysql /var/run/mysqld
sudo mysqld_safe --skip-grant-tables &
and then press enter
now your password get reset, you can change your password again
This works for me
This is indeed a bug with MySQL and a changed user table structure. Unfortunately, if you don't know what changed, you can't change it back. Also, if you cannot login, you cannot fix anything either.
I fixed this as follows. Please be careful with these instructions as they may not work entirely for your setup and you could lose your data if this goes wrong. Don't blame me if it does!
1. Back-up old data dir
Back-up your old data dir somewhere. This allows you to restore the tables at the end. To find out where your data dir is, you can try to initialise mysql. It will give you an error because the data dir already exists:
mysqld initialize
Output:
mysqld: Can't create directory '/usr/local/mysql/data/' (Errcode: 13 - Permission denied)
Now backup your data dir somewhere:
cp -r /usr/local/mysql/data ~/backup-dir/
2. Re-initialize MySQL
With your data dir safely backed up, remove it and re-initialize mysql. It will give you a new temporary password which you can change later.
rm -rf /usr/local/mysql/data
mysqld initialise
The output will give you a new password for 'root'. If you get permission errors, use sudo (not sure about the drawbacks).
Start the server using mysqld_safe to be sure it works the first time:
mysqld_safe
Optionally, change the root password by logging in to mysql and running alter table:
mysql -u root -p
<enter password>
ALTER USER 'root'#'localhost' IDENTIFIED BY 'New Password';
3.Restore data
Stop the mysql server
mysqld stop
Copy all the backup files to the new data dir (run this for every db you need to restore):
cp -r ~/backup-dir/data/<dbname> /usr/local/mysql/data/
For MyISAM tables, this is enough. If you have InnoDB tables, you also need to copy the InnoDB table space from your backup:
cp ~/backup-dir/data/ibdata* /usr/local/mysql/data/
Then, fix permissions (look at the files already present in /usr/local/mysql/data for the right permissions, mine were 'mysql' for both user and group):
chown -R mysql:mysql /usr/local/mysql/data/*
Start the mysql server
mysqld start
All done! You should be able to login again and your tables should be back containing all data, too.
I found a way to fix this...
change the configuration file --my.cnf (usually in /etc/my.cnf)
add "skip-grant-tables" below [mysqld]
now you can login the mysql! backup your database and re-install mysql
I think this will completely repair the problems.
(Plugin 0 is not loaded, i found i cant backup the database then..so you need to add something in mysql.cnf)
I restarted my MySql server and Apache web server and it worked.
Related
I've a Galera Cluster Installation with three nodes. As requirement my MariaDB installation must be in different path that default, and user cannot be mysql. So I've moved all mysql data path and I've created a new user and group to manage the mysql service.
MariaDB service is working fine, but I've noticed that a mysql-slow.log has been created with permissions to mysql:root for a third program installation that monitor queries. Opening mysql.err I've found the following error:
[ERROR] Could not use mysql-slow.log for logging (error 13).Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it.
So I've made chown myuser:mygroup mysql-slow.log and restart the service, but there still having same permissions. Then I've set in my.cnf the slow_query_log=1, in order to try that the myuser create the file at start, but the wrong permission still there also after remove the files and restart.
All the files, in my mariadb data path, are not managed by mysql:mysql user, in my installation are managed by myuser:mygroup so when the mysql-slow.log is created the permissions mysql:root are assigned so I have not permission to write there with myuser:mygroup and if I assign them manually there is not effect because are override with mysql:root after mysql restart.
Somebody knows if there are any way to set by default the user and group owners of the mysql-slow.log file when created?
Thanks.
Regards,
Sergio
Fix the permissions:
chmod 666 mysql-slow.log
See what your script is doing; perhaps it needs fixing, too.
I found my mysql.user table is messed up and use drop table if exists mysql.user to drop it, how can I create this special table manually and add my new account to it.
NB I have never tried this so I have no idea if it will work at all. YOU HAVE BEEN WARNED!!
Before you do anything, shut down the MySQL service and take a backup of the data folder (copy it elsewhere).
Next, either try creating a new data directory and run mysql_install_db (from the MySQL install directory, scripts/mysql_install_db --datadir=<new data directory>), or use a virtual machine and do the same. Whatever you do, do NOT install into the original folder. Use the same version of MySQL to do this
Whichever method you use, take the resultant files from <mysql data folder>/data (they should be called user.MYD, user MYI and user.frm) and copy them into your broken folder. Ensure that user rights are the same as the rest of the folder (owner and group should be read/write).
Restart your MySQL service and see if you can get into the system (no login information will be required, but you will have to log in to MySQL as root. If you can, recreate the relevant users for application access. If not, you still have a backup of the data folder.
In the event that it doesn't work, and assuming that you have recent backups, re-create the data folder completely using mysql_install_db (ensuring that you still have the copy of the folder you took before you started out), create the users, then restore your individual databases one by one from your last good backup. Do not restore the mysql database and tables - they will be built as you restore the other databases.
Try all this out on a virtual machine first - it'll help you find any problems along the way
Good luck
Thanks to #DaveyBoy 's answer. I operated like below on ubuntu 16.04, mysql 5.7.20, and got mysql.user table back:
sudo mysqld --initialize --datadir=~/data_tmp
sudo cp ~/data_tmp/mysql/user.frm /var/lib/mysql/mysql
sudo cp ~/data_tmp/mysql/user.MYD /var/lib/mysql/mysql
sudo cp ~/data_tmp/mysql/user.MYI /var/lib/mysql/mysql
sudo chown mysql:mysql /var/lib/mysql/mysql/user.frm
sudo chown mysql:mysql /var/lib/mysql/mysql/user.MYD
sudo chown mysql:mysql /var/lib/mysql/mysql/user.MYI
In mysql cli select * from mysql.user, table mysql.user should show up now.
I've got ~ 30 sites worth of databases data on a volume on my server in the following directory /mnt/volume0/var/lib/mysql
The directory contains a 6.2G ibdata1 file and directories containing .frm files for each of the websites.
I'm trying to get dumps of the databases so I can move them to another server, however accessing mysql only shows the default databases (as datadir in /etc/mysql/mysql.conf.d/mysqld.cnf is set to /var/lib/mysql)
I've tried changing the datadir in /etc/mysql/mysql.conf.d/mysqld.cnf to /mnt/volume0/var/lib/mysql but mysql fails to start.
It was complaining about "failed to set datadir" which I fixed by running chown mysql:mysql mysql/ -R on /mnt/volume0/var/lib/mysql but now it's complaining about Failed password for root from xxx.xx.xxx.xx port 19192 ssh2
Any help is greatly appriciated!
Thanks
You can try to reset your password
mysqld_safe --skip-grant-tables
if you have here an error, then you have a bigger problem
mysql --user=root mysql
update user set Password=PASSWORD('your new password') where user='root';
flush privileges;
exit;
I ended up solving this issue by replacing the contents of /var/lib/mysql/ on my local machine with the contents of /mnt/volume0/var/lib/mysql/ (from the server).
I then encountered an error whilst trying to start MySQL Table 'performance_schema.session_variables' doesn't exist which I solved by upgrading MySQL on my local machine and restarting: https://stackoverflow.com/a/20262826/8231049
Now I'm able to dump the databases from my local machine :)
Edit: Can't accept my answer before waiting 2 days. Will do then.
Okay, I have a little problem.
My password is expired and my users table is corrupted. I can login via
mysql -u root -p
but on every action I perform I get the folowing error:
Column count of mysql.user is wrong. Expected 45, found 46. The table is probably corrupted.
I have read that you can fix the mysql.user table with the folowing command:
mysql_upgrade -u root -p
But when I do that I get the folowing error:
mysql_upgrade: Got error: 1862: Your password has expired. To log in you
must change it using a client that supports expired passwords. while
connecting to the MySQL server
Upgrade process encountered error and will not continue.
So, How do I fix this?
I have backups of all my tables so I won't be a problem if I have to reset all my databases.
(why the weird format? Stackoverflow thinks it's all code and wants me to put it in code blocks, otherwise I can not save it)
EDIT:
I know my password. That's not the problem at all.
My problem is that the password is expired and I am not able to do anything becuase my mysql.user is corrupted!
Try to disable the password expiration option: edit the my.cnf and put
[mysqld]
default_password_lifetime=0
and try to restart mysql server and try again login again.
the source is here https://dev.mysql.com/doc/refman/5.7/en/password-expiration-policy.html
For repairing the database you run mysqlcheck --repair --databases db_name or mysqlcheck --repair --all-databases for repairing all databases
The source is here https://dev.mysql.com/doc/refman/5.7/en/rebuilding-tables.html
You could first try to repair the database then you could try to disable password lifetime.
Had the same issue when restoring an old backup from 2018, reinstalling MySQL as you said in a comment didn't solve the issue.
How I did:
Stop MySQL service
Run mysqld_safe --skip-grant-tables --skip-networking &
(if you get an error you may need to manually create and chown the directory /run/mysqld)
--skip-grant-tables will allow passwordless logins and will also disable any check on the password expiration
Now run mysql_upgrade --force and mysqlcheck --repair --all-databases
You can now kill the running mysqld_safe (ps aux | grep mysql to find the PID to kill) and then start the server normally with service mysql start.
In my case it didn't work and I still had the "Expected 45, found 46" error. In that case go ahead:
Stop the server again and restart it in safe mode as point 2 above
Now you should be able to dump the content, but we must exclude the mysql schema from being dumped.
Since mysqldump doesn't have a --exclude-database option, we need to get the list of databases to dump. To get the list of existing databases, except system schemas, run:
mysql -Nse "SELECT GROUP_CONCAT(SCHEMA_NAME SEPARATOR ' ') FROM information_schema.SCHEMATA WHERE SCHEMA_NAME NOT IN ('mysql','information_schema','performance_schema','sys');"
Remove from the list any other db you don't need, and run the dump:
mysqldump --databases db1 db2 ... db50 > mysqldump.sql
Kill mysqld, move the datadir away and create an empty one (mv /var/lib/mysql /var/lib/mysql-old && mkdir /var/lib/mysql && chown mysql:mysql /var/lib/mysql)
service mysql start and a fresh datadir will be populated.
Run mysql_secure_installation to set a new root password
Import the dump file:
cat mysqldump.sql | mysql -u root -p
After that, the server is UP and running without issues.
I installed LAMP on Ubuntu 11.04 and copy project from Windows.
PHP directory (/ci/) to var/www/
and
MySQL project directory (/ci/) to var/lib/mysql/
Full text of error that i get:
A Database Error Occurred
Error Number: 1017
Can't find file: './ci/users.frm' (errno: 13)
SELECT COUNT(*) AS `numrows` FROM (`users`) WHERE `email` = 'admin#localsite.com'
I googled that its permission problem, but don't know what do next.
Log from /var/log/mysql/error.log:
110622 19:27:21 [ERROR] /usr/sbin/mysqld: Can't find file: './ci/users.frm' (errno: 13)
Permissions problem meaning the permissions on the file. MySQL probably can't read it. Just change the owner and group to mysql and it should work.
chown mysql:mysql /var/lib/mysql/ci/*
As well as the files being readable by the MySQL user, the directory containing the .MYI files needs to be read, write and executable by the MySQL user. On my system this was achieved by:
chown -R mysql:mysql /var/lib/mysql/dbname
chmod -R 660 /var/lib/mysql/dbname
chown mysql:mysql /var/lib/mysql/dbname
chmod 700 /var/lib/mysql/dbname
This is an old topic, but I didn't find anything that worked for me so for anyone running into the same problem, yet the above file permission suggestions still don't change the "Can't find file" errors, here's what worked for me and my particular issue.
I was doing a rescue from one CentOS server to another using a recovery image, which had a different OS than the original OS and the original filesystem was mounted on a temporary dir. While I had access to the original /var/lib/mysql files, I didn't have access to the mysql admin or dump utilities, which requires the server to be running anyway (it's not automatically included when doing a recovery from a read-only image). Backups were a week old and I wanted to see if I could get the most recent data possible.
Changing the standard file permissions on these still kept giving "Can't find file" for nearly all of the database tables, however I could see that the tables were there. Turns out it was related to SELinux context on the files I had moved over using rysnc. All of the rescued dirs and files looked like this:
$ ls -alZ
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_dev
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_local
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_production
drwx------. mysql mysql unconfined_u:object_r:admin_home_t:s0 somedb_staging
The -Z flag notes the security context of files and dirs. Notice the unconfined_u and admin_home_t context. These are different from what they should be:
drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
Changing these database files to the proper context solved the problem and gave proper access to mysqld using the chcon command:
$ chcon -R -u system_u -t mysqld_db_t somedb_*
This changed all my custom databases to the proper SELinux context and the files could now be recognized by mysqld. I recommend running the chcon commad while the database server is not active, just as a precaution.
Hope that helps someone running into the same problem I had! Of course, you can turn off SELinux temporarily to test if this is fact this issue, but I didn't want turning off SELinux as a permanent solution.
I followed this steps:
Stop the mysql service.
Modify the my.cnf line datadir to my custom location.
Deleted all the files ib_data* , ib_logfile* in our new custom location
Change the permissions of the entire folder with your sentence:
chown mysql:mysql -R /custom_location/mysql/*
Start again the mysql service.
It works!!
Thanks
This error also occurs if the table is not in the database; so if you changed permissions of the directory and are still running into issues check your database and make sure the table is there.
So let's say you got an error like the OP:
Can't find file: './ci/users.frm'
ci is the database name
users is the table name
So in this case if you changed permissions and still had this issue you would verify that the users table is in the ci database.
#Brent Baisley It does work in XAMPP for Linux, but the location is different.
I did upgrade the Kernel today to fix the new Linux “Dirty Cow” Vulnerability (CVE-2016-5195). After the reboot I got the 'frm' permission error too.
So, if you get the following error:
Can't find file: 'yourtablename.frm' (errno: 13 - Permission denied) SQL query :...
You can do:
chown mysql:mysql /opt/lampp/var/mysql/yourDBname/*.frm
This will resolve your issue.
If you'd like to check, if your permission to any of the files has been modified before you execute the permission change, do:
ls -l /opt/lampp/var/mysql/yourDBname/*.frm
Hope that helps someone.
If you have failed RENAME TABLE statement, it could leave MySQL metadata in bad state. The solution is to recreate schema or to recreate table.