I'm having trouble with mysql. I can read and write, but now I want to add some fields to a table. I run this command:
ALTER TABLE Pubs ADD COLUMN issue tinyint AFTER volume;
but get this error message:
ERROR 7 (HY000): Error on rename of './user_acct/Pubs.MYI' to './user_acct/#sql2-cb0-76f2.MYI' (Errcode: 13)
I created this table a few months ago, modified it a little bit, so it worked then. I can still update and insert items, but I just can't modify the table anymore.
Any help would be appreciated.
--Dave
You can use perror to undesrtand mysql error:
$ perror 13
OS error code 13: Permission denied
Do the MySQL user on the system have write permission to the ./user_acct/ folder?
Only the access permission is the issue
Error:
mysql> rename table BL_Backup.TMP_BL_transaction_02 to BL_Backup.BL_transaction_02;
ERROR 7 (HY000): Error on rename of './BL_Backup/TMP_BL_transaction_02.MYI' to './BL_Backup/BL_transaction_02.MYI' (Errcode: 13)
Solution
[root#s4 Db_Backup]# ll
total 52
drwxr-xr-x 2 root root 4096 Sep 28 18:19 BL_Backup
drwx------ 2 mysql mysql 49152 May 19 15:59 mauj_2010_2011
[root#s4 Db_Backup]# chown mysql:mysql BL_Backup
[root#s4 Db_Backup]# ll
total 52
drwxr-xr-x 2 mysql mysql 4096 Sep 28 18:19 BL_Backup
drwx------ 2 mysql mysql 49152 May 19 15:59 mauj_2010_2011
mysql> rename table TMP_BL_transaction_02 to BL_transaction_02;
Query OK, 0 rows affected (0.00 sec)
I just ran into this. I was getting errcode 13 when I tried to do anything which would change the .frm of my older MyISAM tables, but no newer ones.
It was because the ubuntu update process (done a few weeks before) had somehow gotten mysql to check permissions on a file deep in /tmp which it didn't have persmissions to.
root root /tmp/upgrade-XX-X/var/.wh..wh.afs
I discovered this by using 'dmesg' and seeing the permission denied error.
[111111111.222222] type=1503 audit(1862.6:7): operation="link"
pid=<> parent=1 profile="/usr/sbin/mysqld" requested_mask="::l"
denied_mask="::l" fsuid=<> ouid=<>
name="/tmp/upgrade-XX-X/var/lib/mysql/<dbname>"
name2="/tmp/upgrade-XX-X/var/.wh..wh.aufs"
And wondering why in the world mysql was trying to get information about this file?
chmod 777 on this .wh file didn't help, but chown mysql:mysql did.
Related
Fresh install of Ubuntu 20.04 on AWS.
Using ubuntu logon under /home/ubuntu/dev.
Created database myFiles.
Added MYISAM table with static data and tried....
myisampack /var/lib/mysql/myFiles/table01.MYI
and this failed with :
var/lib/mysql/myFiles/table01.MYI gave error 13 on open
permissions are :
-rw-r----- 1 mysql mysql 2340864 Nov 15 00:25 table01.MYI
parent folders :
drwxr-x--- 2 mysql mysql 4096 Nov 15 00:25 myFiles
.. and ..
drwx------ 7 mysql mysql 4096 Nov 15 00:05 mysql
so I lose permissions at /var/lib/mysql
What is the canonical way to perform this?
I have tried adding ubuntu to the mysql group (group has read at least, and execute on the folders).
Running as sudo gives a "140" (Wrong create options).
I have tried running from the /opt folder.
I know this may be an obscure usage, but I am hoping someone has had had to sweat over this already.
I don't want to chmod the tree as the permissions are probably carefully considered.
Plan A:
$ sudo myisampack /var/lib/mysql/myFiles/table01.MYI
Plan B:
$ su mysql myisampack /var/lib/mysql/myFiles/table01.MYI
Plan C:
Don't use MyISAM; then you won't need myisampack. Use InnoDB.
Plan D:
Run OPTIMIZE TABLE while connected to the server.
C is the preferred approach.
I have my main database on an SSD but I also want to hold semi-temporary data in a ramdisk. This is all on Ubuntu with mySQL 8.0.23. However, I'm unable to issue the following query:
mysql> create table t1 (c1 int) data directory = '/mnt/ramdisk/mysql';
I get this:
ERROR 1045 (28000): Access denied for user 'username'#'localhost' (using password: NO)
However, I can do it without the data directory option.
I have the directory in innodb_directories:
mysql> show variables like 'innodb_directories';
+--------------------+--------------------+
| Variable_name | Value |
+--------------------+--------------------+
| innodb_directories | /mnt/ramdisk/mysql |
+--------------------+--------------------+
Permissions to the directory seem okay:
root#localhost:~# ls -ld /mnt/ramdisk/mysql/
drwxr-xr-x 2 mysql mysql 40 Feb 19 10:59 /mnt/ramdisk/mysql/
edit:
Suggestion below pointed to the "file" privilege. After granting "file" privs:
mysql> grant create on ib.* to username#localhost;
Now complains about this when creating the table:
ERROR 1030 (HY000): Got error 168 - 'Unknown (generic) error from engine' from storage engine
With error.log reporting the following even though the directory has rwx perms for all:
2021-02-19T19:20:16.105812Z 26 [ERROR] [MY-012592] [InnoDB] Operating system error number 13 in a file operation.
2021-02-19T19:20:16.105879Z 26 [ERROR] [MY-012595] [InnoDB] The error means mysqld does not have the access rights to the directory.
edit:
After creating a subdirectory for the database named "db", and chown'ing it to mysql:
/mnt/ramdisk/mysql/db
I'm getting this:
2021-02-20T02:47:04.997841Z 8 [ERROR] [MY-012592] [InnoDB] Operating system error number 13 in a file operation.
2021-02-20T02:47:04.997854Z 8 [ERROR] [MY-012595] [InnoDB] The error means mysqld does not have the access rights to the directory.
2021-02-20T02:47:04.997869Z 8 [ERROR] [MY-012126] [InnoDB] Cannot create file '/mnt/ramdisk/mysql/db/table.ibd'
edit:
I noticed that I was able to create the table if I used /tmp... now things are getting interesting...
I did an strace on mysqld to see what was causing the issue and got this:
99911 openat(AT_FDCWD, "/mnt/ramdisk/mysql/db/table.ibd", O_RDWR|O_CREAT|O_EXCL, 0640) = -1 EACCES (Permission denied)
Not knowing what all those flags are, I wrote a quick C program to do the same thing... and it worked. It's not even that the mysql user (running mysqld) can't do it, since the following worked:
sudo -u mysql <the C program>
Any pointers? Thanks...
Okay, sort of figured it out. If the mount point is /mnt, or some other directory that I make, I get the issues described above. If the mount point is /tmp, it works. This is even if I use the same attributes as /tmp. In the end, I'm convinced it's not a mysql issue, but something to do with the filesystem.
This being just about the only relevant post I could find when encountering this problem myself, I'll post my solution.
But first, the problem, apparmor!
Here's how to check if apparmor or similar !#$##$ is the reason for your grievances.
If running:
journal -fx
return something akin to this when you try to create your db: (removed timestamps etc)
audit[813063]: AVC apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mnt/volume_fra1_01/mysql/mydb/tda.ibd" pid=813063 comm="connection" requested_mask="c" denied_mask="c" fsuid=112 ouid=112
audit: type=1400 audit(1664628440.627:200): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mnt/volume_fra1_01/mysql/mydb/tda.ibd" pid=813063 comm="connection" requested_mask="c" denied_mask="c" fsuid=112 ouid=112
Then you've hit jackpot!
Find mysql's apparmor file, mine is in /etc/apparmor.d/usr.sbin.mysqld. Find the rows allowing access to mysql's default data dir and add your rows, my addition is the two last ones, you'll of course need to change them to suit yours, if you're feeling frisky you can just allow access to /mnt/ and be done with it.
# Allow data dir access
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
/mnt/volume_fra1_01/mysql/ r,
/mnt/volume_fra1_01/mysql/** rwk,
Once you've edited your apparmor file you may swear some more and run:
apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld
Done! Now run your CREATE TABLE again and go on with your life to greener pastures.
Today I updated openssl (due to the recent heartbleed vulnerability) and all of a sudden mysql is acting strangely. I was recently able to modify tables, but now when I try to add a column I get:
ERROR 1005 (HY000): Can't create table '#sql-34f_872b' (errno: 13)
And trying to do show tables results in:
ERROR 1018 (HY000): Can't read dir of './<db>/' (errno: 13)
During the openssl upgrade there was a prompt asking about an upgrade to mysql. It was asking if I want to keep my current /etc/my.cnf or if I wanted to replace with the new one - I selected to keep.
Typically this would be a permissions issue, and I've tried and tested the permissions on the mysql datadir (using this answer from a similar question).
A few other strange things:
When I try these commands, I'm using the mysql command client and logged in as root
I am able to insert new rows into existing tables
I feel like the openssl upgrade is too much of a coincidence to ignore, and I'm not keen on the idea of restarting mysqld without really knowing that the server will definitely come back up (since there's an unknown issue going on here).
Any ideas?
Reply to comments and questions:
Output of ls -ltrFa:
remy#ip-10-168-9-52:~$ ls -ltrFa /vol/mysql/
total 49367084
-rwxr-xr-x 1 mysql mysql 0 Feb 11 2013 debian-5.5.flag*
drwxr-xr-x 2 mysql mysql 4096 Feb 11 2013 test/
drwxr-xr-x 2 mysql mysql 4096 Feb 11 2013 performance_schema/
drwxr-xr-x 2 mysql mysql 4096 Feb 11 2013 mysql/
-rwxr-xr-x 1 mysql mysql 6 Feb 11 2013 mysql_upgrade_info*
-rwxr-xr-x 1 mysql mysql 25 Feb 12 2013 slave-relay-bin.index*
-rwxr-xr-x 1 mysql mysql 126 Feb 12 2013 slave-relay-bin.000001*
drwxr-xr-x 6 mysql mysql 4096 Oct 14 14:35 ./
drwxr-xr-x 2 mysql mysql 4096 Apr 3 15:50 jsbin/
drwxrwxrwx 5 root root 4096 Apr 9 16:07 ../
-rwxr-xr-x 1 mysql mysql 50417631232 Apr 9 17:24 ibdata1*
-rwxr-xr-x 1 mysql mysql 67108864 Apr 9 17:24 ib_logfile0*
-rwxr-xr-x 1 mysql mysql 67108864 Apr 9 17:25 ib_logfile1*
Output of ps aux | grep mysql:
mysql 847 1.4 83.9 16342212 14681964 ? Ssl 2013 3646:34 /usr/sbin/mysqld
remy 4038 0.0 0.0 101816 2824 pts/0 S+ 16:58 0:00 mysql -uroot -px xxxxx jsbin
Note that I've also tried running mysql using sudo -u mysql mysql -uroot -pxxx jsbin and it results in the same issue.
Here is the the log from the apt-get upgrade openssl which shows mysql being included in the update: https://gist.github.com/remy/10291829
Server is ubuntu-precise-12.04-amd64 (installations are all via apt-get rather than manually compiled).
Versions of mysql:
$ mysqld --version
mysqld Ver 5.5.29-0ubuntu0.12.04.1 for debian-linux-gnu on x86_64 ((Ubuntu))
$ mysql --version
mysql Ver 14.14 Distrib 5.5.35, for debian-linux-gnu (x86_64) using readline 6.2
The following worked for me :
rm /var/lib/mysql/ib_logfile*
/etc/init.d/mysql restart
So it turns out that apt-get upgrade openssl actually upgrades everything else in it's wake - along with openssl. So somehow MySQL got caught in that update.
By accident (an AWS backup actually) the machine was rebooted, and all problems went away.
I'm pretty sure this is because some of MySQL's libraries had been updated, but the server that was loaded in memory was somehow incompatible.
I wouldn't generally recommend a random restart to fix these issues, but in this particular situation, it did the job.
The most-likely reason I can think of for this is due to some upgrade process or script trying to alter table defaults and/or one of the dependent tools adding a table and immediately altering it. This could step on a documented limitation in MySQL that prevents you from adding and dropping foreign keys in the same ALTER statement.:
* http://bugs.mysql.com/bug.php?id=68286
Can you check your logs to see what was running when the failure happened and then manually edit the update script or manually make the change so it's skipped?
I think keeping your my.cnf was the right way to go too. But if you can't get enough info from the logs as noted above, you could try disabling FK checks in there, https://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
...that does risk some trash data though, so use as a last resort.
As for OpenSSL, this was triggered by the update but not specific to OpenSSL. Any update to 5.5.29 that ran a complex ALTER might have triggered this
Problem
I'm running MySQL 5.5.23 on Mac OS 10.8.2 and am unable to drop a particular database, but I can drop others.
When I attempt to drop the specific table I get this error:
#1548 - Cannot load from mysql.proc. The table is probably corrupted
Attempted Fixes
I have restarted the system
I have tried to restart MySQL via CLI
$ sudo /usr/local/mysql/support-files/mysql.server stop
but received this error ERROR! MySQL server PID file could not be found!
I have repaired the mysql.proc table.
REPAIR TABLE mysql.proc
REPAIR TABLE mysql.proc USE_FRM
I have repaired all mysql.* tables.
REPAIR TABLE mysql.*
When running mysqlcheck from the Command Line
mysqlcheck --repair --all-databases
mysqlcheck --repair specific-db
I received this error : mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/mysql/mysql.sock' (2) when trying to connect
Current Status
I still cannot drop the original specific database, but can drop others.
Update[1] 2013-01-05 11:15 am [New York]
Logs and Feedback (per #Thomas in comments)
To find all logs, I ran (cli):
$(ps auxww|sed -n '/sed -n/d;/mysqld /{s/.* \([^ ]*mysqld\) .*/\1/;p;}') --verbose --help|grep '^log'
I received this feedback:
130105 11:35:21 [Warning] Can't create test file /usr/local/mysql-5.5.23-osx10.6-x86_64/data/wills-mbp.lower-test
130105 11:35:21 [Warning] Can't create test file /usr/local/mysql-5.5.23-osx10.6-x86_64/data/wills-mbp.lower-test
130105 11:35:21 [Note] Plugin 'FEDERATED' is disabled. /usr/local/mysql/bin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
130105 11:35:21 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
I'm looking into the mysql_upgrade.
Update[2] 2013-01-05 4:04 pm [New York]
I ran this :
sudo /usr/local/mysql/support-files/mysql.server stop
And received this error:
ERROR! MySQL server PID file could not be found!
Update[2.1] 2013-01-05 5:37 pm [New York]
I ran ps auxww | grep mysql and found the mysqld process and killed it (sudo kill [process id]). I was then able to restart mysql successfully. However, I'm still having no luck dropping that specific database mentioned above.
Resolved
After trying to manually repair the corruption and many of the suggestions and the other answer listed here, reinstalling mySQL was the only thing that solved my problem.
On a Mac (running 10.8.2) I also had to do some manual deletions for a clean install:
sudo rm /usr/local/mysql
sudo rm -rf /usr/local/mysql*
sudo rm -rf /Library/StartupItems/MySQLCOM
sudo rm -rf /Library/PreferencePanes/My*
sudo rm -rf /Library/Receipts/mysql*
sudo rm -rf /Library/Receipts/MySQL*
sudo rm /etc/my.cnf
Articles consulted
MySQL duplicates with CONCAT error 1548 - Cannot load from mysql.proc. The table is probably corrupted
SQL error: BIGINT UNSIGNED value is out of range in (…), but it doesn't make sense
How to repair corrupted table
MySQL manager or server PID file could not be found
PHP/MySQL issue after security update 2010-005
mysql problems after Mac OS X software update
How to remove MySQL completely Mac OS X Leopard
I ran into an issue that queries on my databases (named: caloriecalculator) was taking too long and it won't drop at all. I followed these steps below and it fixed my issue:
See all MySQL processes: mysqladmin processlist -u root -p
Kill all processes relating to caloriecalculator as it was blocking my next queries to be executed.
mysqladmin -u root -p kill 4
Now run: drop database caloriecalculator;
I would try:
Backup/save any databases that have important data.
Remove mySQL
Reinstall mySQL
Restore any backed up databases.
I had this happen to me on a Linux server, and the cause was a corrupted database directory.
UPDATE: one thing to do is to go into MySQL database directory and perform a ls -la, to verify that the evil DB is the same as the others as regards permissions, ownership and so on. For example here the 'original' database cannot be dropped (it was created by a stupid tool ran as root):
drwx------ 2 mysql mysql 4096 Aug 27 2015 _db_graph
drwx------ 2 mysql mysql 4096 Jul 13 11:58 _db_xatex
drwxrw-rw- 2 root root 12288 May 18 14:27 _db_xatex_original
drwx------ 2 mysql mysql 12288 Jun 9 08:23 _db_xatex_contab
drwx------ 2 mysql mysql 12288 May 18 17:58 _db_xatex_copy
drwx------ 2 mysql mysql 4096 Nov 24 2016 _db_xatex_test
Running chown mysql:mysql _db_xatex_original; chmod 700 _db_xatex_original would fix the problem (but check inside the directory to verify there too permissions and ownerships are copacetic).
In the end, I employed the following ugly hack (after trying stopping, restarting and repairing whatever could be targeted by a REPAIR):
created a database "scapegoat"
stopped MySQL Server
copied the directory created by MySQL Server, /var/lib/mysql/scapegoat, to /tmp
restarted MySQL Server, dropped the database "scapegoat", stopped the server
Now I had a copy of a clean, empty DB dir that MySQL no longer knew anything about.
moved the "evildb" directory to /tmp (so that if thing went wrong I could put it back)
moved the "scapegoat" directory to /var/lib/mysql renaming it to "evildb"
started MySQL Server
not sure if I ran any more repairs at this point
and the "evildb" database became droppable!
My explanation is that when asked to drop a database, MySQL Server first performs some checks on the files in the database directory. If these checks fail, the drop also fails. These checks must be subtly different from the ones performed by REPAIR. Maybe in the affected directory there is something unexpected.
I think this was on a MySQL 5.1 or 5.2 on a SuSE 11.2 Linux distribution. Hope it helps.
UPDATE
On thinking back, I don't remember getting errors about "proc". So I'm less sure that the problem lies in the directory. It might be connected with the proc table, without being a table corruption. Have you tried visually inspecting the proc database table, in order to find something there that belongs to the evil DB?
USE mysql;
SELECT * FROM proc;
That, or any errors therefrom, could help in solving the problem. You might, who know, have some lines with the wrong db column. In a pinch, you could export the proc table and reload it after cleaning (either through SQL or via a disk file).
TEST
I have partial verification for the above update. By intentionally inserting rubbish into the proc table apropos a newly created database evil, I partially reproduced your symptoms (undroppable database, MySQL connection crashes on attempt). Error number is not 1548 though; but maybe it would be, if I inserted the right rubbish in that table... anyway, the useful bit is that by removing all references to the evil db, the latter became droppable again:
mysql> drop database evil;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> use mysql;
No connection. Trying to reconnect...
Connection id: 1
Current database: *** NONE ***
Database changed
mysql> DELETE FROM proc WHERE db = 'evil';
Query OK, 2 rows affected (0.00 sec)
mysql> drop database evil;
Query OK, 0 rows affected (0.00 sec)
I had the same problem and all I did was to delete the database directory from the mysql data directory.
If you using xampp In windows
you can also drop your database using phpmyadmin
go to home -> databases -> click on your [database name] -> drop
OR
you can also drop your database manually
go to xampp -> mysql -> data -> [database name]
delete your [database name] now.
i used the following sytanx
drop database filmo;
and got the following error:
ERROR 1010 (HY000): Error dropping database (can't rmdir './filmo/', errno: 17)
any ideas..
It means there are files in that directory not relating to MySQL. Another issue, although I doubt it, is insufficient permissions. You may delete that directory from the filesystem.
Got same error. This fixed it for me in Ubuntu 10.04:
stop mysql
rm -rf /var/lib/mysql/XXXXX
start mysql
Where XXXXX is the offending database name.
sudo rm -rf /var/lib/mysql/db_production
where
db_production is the name of the database
Remember to use "sudo".
I've changed the permissions on mysql folder ( windows server c:\xampp\mysql ) and is working now, I've created and dropped databases without any error.
This is what I do on Mac OS X Mavericks:
Stop the MySQL service
Remove the directory at /usr/local/mysql/data
1) rm -rf /var/lib/mysql/data/***
keep the data dir , rm the contents of data/
2) use
mysql -uxxx -pyyy
$ drop database data;
then it would be ok to recreate the data database again.
hopefully it will help,
Attention , direct remove data dir is useless, whatever you restart mysqld or not .
Here is a way to simulate your error
1.create a directory on MySQL data directory
mkdir /data/mysql/data/filmo
2.check the last item
[root#linux]# ls -ltrh /data/mysql/data/
总用量 173M
-rw-rw---- 1 mysql mysql 48M 4月 17 11:00 ib_logfile1
drwx------ 2 mysql mysql 4.0K 4月 17 11:00 performance_schema
drwx------ 2 mysql mysql 4.0K 4月 17 11:00 mysql
-rw-rw---- 1 mysql mysql 56 4月 18 06:01 auto.cnf
drwxr-xr-x 2 root root 4.0K 4月 18 07:25 backup
-rw-rw---- 1 mysql mysql 19 4月 23 07:29 mysql-bin.index
-rw-rw---- 1 mysql mysql 5 4月 23 07:29 oldboylinux.pid
-rw-rw---- 1 mysql mysql 19K 4月 23 07:29 error.log
-rw-rw---- 1 mysql mysql 76M 4月 23 09:56 ibdata1
-rw-rw---- 1 mysql mysql 48M 4月 23 09:56 ib_logfile0
-rw-rw---- 1 mysql mysql 5.9K 4月 23 10:21 mysql-bin.000001
drwxr-xr-x 2 root root 4.0K 4月 23 10:36 filmo
3.create a dump file in it
[root#linux]# mysqldump -uroot -p123456 -B mysql>/data/mysql/data/filmo/dump_file.sql
4.MySQL will believe filmo is a database
[root#linux]# mysql -uroot -p123456 -e"show databases;"
+--------------------+
| Database |
+--------------------+
| information_schema |
| backup |
| filmo |
| mysql |
| performance_schema |
+--------------------+
5.when I drop this "database",here is your error
[root#linux]# mysql -uroot -p123456 -e"drop database filmo;"
ERROR 1010 (HY000) at line 1: Error dropping database (can't rmdir './filmo/', errno: 17)
This is amazingly old, but another thing to check is the data folder. On Windows, that should be C:\ProgramData\MySQL<Version>\Data. IN my case, I was getting a 'cannot find folder' error.
I found that somehow the data folder for my database had been deleted. I imagine it was user error. I added a blank folder with the database name, and when I went back the DROP the table, it went as expected. Took me a while to find out what had happened, but hopefully this will save someone else the heartache.
do you have write permission on that directory (and the parent)? you may need to recursively make the directory writable (security tab in windows or chmod in nix) and delete any non-db files like "Thumbs.db"
I had this problem and it seems to be about your mysql user permissions.
try doing it by root user if it did work use this command as root to grand drop permission to your user:
grant drop
execute on *.* to 'your-user-name'#'user-ip';
That error usually comes when you have wrong TABLESPACE in ibdata1 file (that's for innodb engine)
innodb engine store some settings inside ibdata1 file
if you have recently copied / moved your files to other server or tried to restore then you should move ibdata1 file aswell then you can delete the db.
I assume you are having issue like table doesn't exist and now deleting db?
if yes then stop mysql service then delete files and then create db again, that will help you.
Further here this might help you
[Error Dropping Database (Can't rmdir '.test\', errno: 17)
Not sure where I got this answer from (apologies) but, although similar to the above, it has the additional info of how to find the mysql data directory:
mysql -e "select ##datadir"
This, I assume, is generic and returns the path to mysql/data. If you move to that directory (unix/linux/macOS command):
cd path_to_mysql/data
you will find the database you want to remove, which on nix can be done by:
sudo rm -rf DB_NAME
On MacOS X (10.9.5) I did not have to stop MySQL, but this may differ on other platforms.
drop database <database_name>;