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.
Related
So I dropped all the users in mysql.user and restarted the mysql database. Now I can't seem to get into the mysql again or how to reset it as if it was a clean install. I tried uninstalling it with brew uninstall mariadb and then reinstalling it with brew install mariadb, but that didn't fix it. The only resources I can find is about how to restore a user from inside mysql (which I am struggling to get into) or how to delete mysql completely by deleting files in certain directories (which don't exist in the first place).
There are two methods:
method 1:
1.Uninstall the mysql database, delete the data files in the /data directory, and then reinstall
Method 2:
1.Stop the mysql service (systemctl stop mysqld)
2.Delete the files in the /data directory (rm -fr /data/*)
3.Initialize mysql (mysqld --defaults-file=/mysql/my.cnf --initialize --user=mysql --basedir=/mysql/app/mysql --datadir=/mysql/data/3306/data/)
PS1: The path may be different from yours, you need to change it according to your own data directory
I did end up finding a solution to my problem. I didn't end up getting it from one source, but more cobbled a bunch of different stuff together until I figured out that this worked.
Stop the server: `brew services stop mariadb
Start it with this command: mysql --skip-grant-tables
Run this command to fix the table with no users: mysql_upgrade --force
Force kill mysql: ps -ef | grep mysql followed by kill -9 <pid>
Start up the server again: brew services start mariadb
I did first try mysql_install_db instead of mysql_upgrade --force as some site suggested, but that didn't work since mysql.user table still existed. It was just empty.
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.
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.
I am trying to set up a dev environment on my Mac laptop, and I have run into some trouble when installing mysql. When I try to create a database, I get the following error:
ERROR 1006 (HY000): Can't create database 'SummerGypsy_development'
(errno: 2
From what I have gathered, this means there was some problem in creating the database on the disc.
Here is how I installed mysql:
First, using Homebrew, I executed:
brew install mysql
Once that finished, I tried running mysql_install_db, but got an error. To remedy this error, I ended up running
mysql_install_db --basedir=/usr/local/
I can run mysql, but creating a database does not work. I ran
mysqladmin variables | grep datadir
To find where mysql was trying to create the database. The output was: /usr/local/mysql/data
/usr/local/mysql and /usr/local/mysql/data directories do not actually exist, and I have a feeling that the datadir is pointing here because of the basedir I passed into mysql_install_db. As a quick fix, I tried creating both directories, and then running
chown -R mysql:mysql /usr/local/mysql
to give mysql permissions in this directory. This did not fix the problem, though.
Does anyone have any suggestions?
you need to change the permissions in the data.
chown -R mysql:mysql /usr/local/mysql/data
You might want to try installing from the .dmg file (installer, system preferences pane, and startup script) that is distributed directly from MySQL. There is a thread on Getting MySQL work on OSX 10.7 Lion that you might want to take a look at. These steps helped me get MySQL running on OSX Lion. Hope this helps.
I tried lot of the suggestions including the file permission reset with no luck. But i then restarted the mysql using the command "./mysqld_safe &" (excluding quotes) and it worked.
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.