mysql create table with data directory: access denied - mysql

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.

Related

MariaDb access to file system

I am trying to read a CSV file into MariaDb and get an error message that says "permission denied". Can you tell me what I have done wrong (see details below)?
I am running MariaDb 10.2.6 on OSX High Serra. I am logged in to MariaDb as 'root'#'localhost'. I have granted 'root'#'localhost' FILE privilege. The user 'root'#'localhost' is using the security plugin 'unix_socket'.
I have created a table using the CONNECT storage engine like so:
create table twins (
ABOT double,
SCLK double,
LMST varchar(30),
LTST varchar(30),
UTC varchar(30),
HORIZONTAL_WIND_SPEED double,
VERTICAL_WIND_SPEED double,
WIND_DIRECTION double,
AIR_TEMP double)
engine=CONNECT table_type=CSV file_name='twins_calib_8066_01.csv'
header=1;
The permission to the file I wish to read is:
-rw-r--r-- 1 ssackett everyone 873837 Mar 20 11:29 twins_calib_8066_01.csv
When I issue the SQL: select * from twins;
I receive the error message:
ERROR 1296 (HY000): Got error 174 'Open() error 13 on twins_calib_8066_01.csv: Permission denied' from CONNECT
The CSV storage engine doesn't allow UPDATE or DELETE, but it does allow INSERT, therefore mysqld needs write permission on the file, or else it can't open it.
But your CSV file is owned by ssacckett, not "mysql" (or whatever uid your mysqld runs as), so it's not writeable by the mysqld process.
Try:
sudo chown mysql:mysql twins_calib_8066_01.csv
Change it to the user & group that the mysqld process runs as.
Alternatively, change the file mode to writeable by all:
chmod 666 twins_calib_8066_01.csv
Check the permission on the directory containing the .csv file. You need "search" (x) permission on the directory to even see the files in it.

Resetting MySQL root password giving error when running init-file

I know there are countless questions and posts about this, but I'm getting an error when trying to start the MySQL Server and I don't know how to solve it.
So to explain I cannot access my database so I tried to reset the password of the root user. I've followed this guide however I've had no luck. First I had issues with permissions on my machine and now I'm getting this error:
1105 Bootstrap file error, return code (0). Nearest query: ''
Technically the MySQL Server is starting, however the init-file is not being run, and so my password is not being reset.
Command I am running is this:
mysqld --defaults-file="C:\\ProgramData\\MySQL\\MySQL Server 5.7\\my.ini" --init-file=C:\\mysql-init.txt --console
Contents of mysql-init.txt
ALTER USER 'root'#'localhost' IDENTIFIED BY 'new_password';
The following is the part of the log where the error is shown:
[Note] Execution of init_file 'C:\\mysql-init.txt' started.
[ERROR] 1105 Bootstrap file error, return code (0). Nearest query: ''
[Note] Execution of init_file 'C:\\mysql-init.txt' ended.
[Note] C:\Program Files\MySQL\MySQL Server 5.7\bin\mysqld.exe: ready for connections.
MySQL Version: 5.7
OS: Windows 10
Actually you can pass the command:
--init-file=C:\\mysql-init.txt
as a parameter to start the MySQL service from its general tab.
(Source)
Had two errors with MySQL 5.7.24
1.) The script file must be in a separate folder (not mysql installation folder or data directory)
and that folder must get "secure-file-privileges"
2.) The error above was raised for the script did not end with a ';'
Succeeded then with command line statement as
mysqld --datadir=D:\ProgramData\mysql\data --init-file=D:\ProgramData\mysql\reset\reset.sql --secure-file-priv=D:\ProgramData\mysql\reset --console
and SQL-script file 'reset.sql' as
alter user 'root'#'localhost' identified by 'root_pwd';
For me, on Ubuntu, problem was init file was not owned by mysql user.
chown mysql:mysql /tmp/reset_mysql_pswd.sql
sudo mysqld --init-file=/var/lib/mysql/reset_mysql_pswd.sql
# ^C or kill -9 <mysqld pid>
systemctl stop mysql.service
systemctl start mysql.service
Even when the folder containing the init file and the init file itself had permissions 777 (which is a bad idea), I still get:
2020-04-10T23:14:48.030719Z 0 [Note] Execution of init_file '/tmp/reset_mysql_pswd.sql' started.
2020-04-10T23:14:48.030764Z 0 [ERROR] mysqld: File '/tmp/reset_mysql_pswd.sql' not found (Errcode: 13 - Permission denied)
2020-04-10T23:14:48.030772Z 0 [ERROR] Aborting

Building MySQL as non-root and with another MySQL already running

I need to use a bioinformatics tool that uses MySQL. The tool is called SyMap. When I try to run SyMap, it tells me there's a MySQL server already running so I should either shut it down or point SyMap to another server. Since I work on an HPC that allows me limited permissions, I cannot shutdown the MySQL server. So I've been trying to build my own local MySQL server. With zero knowledge about MySQL, this has been frustrating.
I tried to follow this guide to build MySQL as a non-root user with the addition of the flag MYSQL_TCP_PORT=3307 to the cmake command to have the local server run on a different port than the original's (3306). Whenever I get to the step where I have to execute mysql_install_db, it says:
2015-10-31 20:52:02 [WARNING] mysql_install_db is deprecated. Please
consider switching to mysqld --initialize 2015-10-31 20:52:02 [ERROR]
Child process: /home/rajeha/software/mysql/bin/mysqldterminated
prematurely with errno= 32 2015-10-31 20:52:02 [ERROR] Failed to
execute /home/rajeha/software/mysql/bin/mysqld --bootstrap
--datadir=/home/rajeha/software/mysql/data --lc-messages-dir=/usr/share/mysql --lc-messages=en_US
-- server log begin -- 2015-11-01T01:52:02.964453Z 0 [Warning] --bootstrap is deprecated. Please consider using --initialize instead 2015-11-01T01:52:02.969334Z 0 [ERROR] Invalid old_passwords mode: 1.
Valid values are 2 and 0
2015-11-01T01:52:02.969376Z 0 [ERROR] Aborting
-- server log end --
I also tried to run the ./bin/mysqld --initialize --user=mysql command, but I still get the error that old_passwords is equal to 1.
If I try to run the server with mysql_safe, it says:
*./bin/mysqld_safe: line 130: /var/log/mysqld.log: Permission denied ./bin/mysqld_safe: line 164: /var/log/mysqld.log: Permission denied
151031 20:53:12 mysqld_safe mysqld from pid file
/home/rajeha/software/mysql/the.pid ended ./bin/mysqld_safe: line 130:
/var/log/mysqld.log: Permission denied*
This is because it's trying to access /var/log/ which I cannot write onto. I probably have to change the config file that tells mysql to access this directory, and that also specifies the value of old_passwrods, but I don't know where to find it.
I would appreciate your help.
Thanks.

Why can't I drop MySQL Database?

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.

Unable to modify a table

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.