I tried everything and whenever i try to start mysql i get this error
140526 18:21:36 InnoDB: Using Linux native AIO
^G/usr/sbin/mysqld: Can't create/write to file '/mysql/ibAlmthH' (Errcode: 13)
I even tried to chnage tmp dir in my.cnf with full write permissions but i still get that error
I tried this post
https://stackoverflow.com/a/16178696
But still same error
what should i do
Refer this, from the stackoverflow question number-2783313 may it help:
Recent Ubuntu Server Editions (such as 10.04) ship with AppArmor and MySQL's profile might be in enforcing mode by default. You can check this by executing sudo aa-status like so:
# sudo aa-status
5 profiles are loaded.
5 profiles are in enforce mode.
/usr/lib/connman/scripts/dhclient-script
/sbin/dhclient3
/usr/sbin/tcpdump
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/sbin/mysqld
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode :
/usr/sbin/mysqld (1089)
0 processes are in complain mode.
If mysqld is included in enforce mode, then it is the one probably denying the write. Entries would also be written in /var/log/messages when AppArmor blocks the writes/accesses. What you can do is edit /etc/apparmor.d/usr.sbin.mysqld and add /data/ and /data/* near the bottom like so:
...
/usr/sbin/mysqld {
...
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,
/data/ r,
/data/* rw,
}
And then make AppArmor reload the profiles.
# sudo /etc/init.d/apparmor reload
WARNING: the change above will allow MySQL to read and write to the /data directory. We hope you've already considered the security implications of this.
Try to run this command manually:
touch /mysql/ibAlmthH
If it failed to create it, you then have a filesystem problem, e.g. read-only filesystem,
So you need to fix the filesystem problem first,
Also check the available disk space on this directory, may be there is no space.
Change directory permission to read, write and execute..
Chmod 777 /directory_path
Related
Something is wrong. I stopped MaridaDB, moved /var/lib/mysql to a different place, then replaced the old mysql with a softlink
cd /var/lib
ln -s /data/mysql .
Then I added
chown -R mysql:mysql mysql
and then I went to /data and did the same (Note: this relocation works fine in regular mysql). But in MariaDB
ERROR] mysqld: Can't create/write to file
'/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied")
[ERROR] mysqld: Got error 'Can't create file' when trying to use aria
control file '/var/lib/mysql/aria_log_control' [ERROR] Plugin 'Aria'
init function returned error. [ERROR] Plugin 'Aria' registration as a
STORAGE ENGINE failed.
So what can I do to fix this? I tried setting
chmod 777 /var/lib/mysql/aria_log_control
but to no avail.
In my case the problem was that while directory mysql and files within were owned by user mysql, the path has a directory that lacked x bit for the users that are not in the correct group. In other words, user could not move to the target directory because one of the directories in the path did not allow it.
In My case this happened after a change which required OS restart, turned out that SELINUX was in ENFORCE mode and was not allowing MySQL to access the files, used below command to resolve:
sudo getenforce
sudo setenforce 0
I'm running on EC2, and want to have MYSQL's datadir on another EBS. I mounted the EBS (ext3) on /data and changed the datadir in my.cnf to point to that dir. However, when I try to start mysql, I get this error:
120518 03:53:17 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
120518 03:53:28 mysqld_safe Starting mysqld daemon with databases from /data/mysql/
120518 3:53:28 [Warning] Can't create test file /data/mysql/ip-10-136-23-225.lower-test
120518 3:53:28 [Warning] Can't create test file /data/mysql/ip-10-136-23-225.lower-test
/usr/libexec/mysqld: Can't change dir to '/data/mysql/' (Errcode: 13)
120518 3:53:28 [ERROR] Aborting
120518 3:53:28 [Note] /usr/libexec/mysqld: Shutdown complete
120518 03:53:28 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Any ideas?
If you are running on a distro like Ubuntu, then AppArmor is probably blocking mysqld from being able to access files in a different directory. If you check your system log files, you'll find a cryptic error message to this effect.
Solutions include:
Disable AppArmor (not recommended)
Edit the AppArmor rules (complicated)
Use "mount bind" to make MySQL think that your data files are in the original location while they are actually over on the EBS volume. Revert your changes to datadir.
I wrote an article for Amazon years back describing community best practices for exactly what you are trying to do including commands for the mount bind example:
Running MySQL on Amazon EC2 with EBS
http://ec2ebs-mysql.notlong.com
Note that the AMI id in the article is old. Using a modern Ubuntu AMI, you'll need to replace /dev/sdh with /dev/xvdh in the mkfs.xfs and /etc/fstab (but not in the ec2 tools command lines).
If you're running Ubuntu, you can run into this error due to the apparmor service. To get around this. To get around it, you need to do the following:
1) Edit '/etc/apparmor.d/usr.sbin.mysqld' and add these lines:
/opt/lib/mysql/ r,
/opt/lib/mysql/** rwk,
( assuming your new data directory is in /opt/lib/mysql )
2) re-start the apparmor service:
sudo service apparmor restart
Change owner of /data directory to mysqld process owner (chown owner /data ). or (chmod 777 -R /data) very unsafe.
MySQL 5.1.54
Ubuntu 11.04
I'am try to change bin log directory in my.conf as:
[mysqld]
log_bin=/home/developer/logs/mysql/mysql-bin.log
After this changes MySQL server can't start with error:
/usr/sbin/mysqld: File '/home/developer/logs/mysql/mysql-bin.index'
not found (Errcode: 13)
111005 12:47:58 [ERROR] Aborting
Permission for directory /home/developer/logs/mysql/ is 0777
What's going on?
As usual, the solution was simple but not obvious: it needed to edit apparmor settings
I just added to /etc/apparmor.d/usr.sbin.mysqld a new string with path to target directory: /home/developer/logs/* rw
It works!
/usr/sbin/mysqld: File '/usr/binlogs/mysql-bin.index' not found
(Errcode: 13)
It worked for me with:
chown -R mysql:mysql /usr/binlogs/
Just as an FYI for anyone who runs into a similar problem, the solution is basically the same, but the cause of the problem isn't obvious.
After upgrading Debian wheezy, mysql failed to start.
Somehow, I have no idea how, permissions on some of the files in /var/lib/mysql were not owned by the mysql user, thus preventing the server from firing up.
A chown -R mysql.mysql /var/lib/mysql fixed it.
I didn't do anything to mess up mysql, it was a standard:
apt-get update
apt-get upgrade
Something got hinky during the Debian upgrade and manual intervention was needed.
Selinux might enforce the rule that MySQL database files have to live in /var/lib/mysql and not anywhere else. Try turning off selinux (selinux=0 on kernel boot command line) if you moved mysql to another directory.
Option 1:
service mysqld stop
Copy the log files including the .index file to new location.
cp mysql-bin.log* /path/to/binlogs
cp mysql-bin.index /path/to/binlogs
Do Changes in the /etc/my.cnf file.
[mysqld]
log-bin=/path/to/newdirecory/mysql-bin
log-bin-index=/path/to/newdirectory/mysql-bin.index
service mysqld start
Option 2:
Use this utiltiy to relocate binary logs:
mysqlbinlogmove --binlog-dir=/server/data /new/binlog_dir
You need to give user permissions to the directory as follows:
chown -R mysql:mysql /home/developer/logs/mysql/
Does your user have access to all upper directories? In special, the /home/developer/ directory? Try to log in with the mysql server account and touch the log file.
mysqld: File '/data/log/mysql/mysql-bin.index' not found (Errcode: 2
- No such file or directory)
I was really stuck in the middle of my MySQL Master - Slave setup. Finally the above was a permission issue, adding the below command solved my issue.
chown -R mysql:mysql /data/log/mysql/
I had a similar problem when I was trying to change the datadir variable during a fresh install. The solution in my case was to run the first time start up with log-bin disabled. After that I was able to enable it again using the new path ...
Your config is wrong:
log_bin=/home/developer/logs/mysql/mysql-bin.log
You would use instead
log-bin=/home/developer/logs/mysql/mysql-bin.log
During replication configuration in "my.cnf" file needs to mention
server-id=1
log_bin=/var/log/mysql/mysql-bin.log
you can make your own directory and give permission.
create directory "mysql" in /var/log/
chmod 777 mysql
this is applicable with MySQL version 5.7
You can also comment the line in my.cnf file which is defining the log location, so mysql will consider its default path and will start properly.
log-bin = /var/log/mysql/mysql-bin.log -> #log-bin = /var/log/mysql/mysql-bin.log.
This will be helpful if you are not concerned much about logs.
As documentation in mysql say https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_log_bin
The variable is log_bin and not log-bin at least in version 5.7
Server shutdown from power failure.
Mysql will not start now.
Disk is not full.
Syslog is below
Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31 InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
If you are using ubuntu or apparmor you should permit this change in apparmor.
Edit /etc/apparmor.d/usr.sbin.mysqld and change /var/lib/mysql with the new DATADIR.
It should work.
Error:
101130 14:42:51 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
101130 18:07:58 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
101130 18:07:58 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
Solution SeLinux SeLinux security:
[root#localhost ~]# service mysqld restart
Deteniendo mysqld: [ OK ]
Iniciando mysqld: [ FALLÓ ]
[root#localhost ~]# restorecon -R /var/lib/mysql/
[root#localhost ~]# service mysqld restart
Deteniendo mysqld: [ OK ]
Iniciando mysqld: [ OK ]
[root#localhost ~]#
please check this:
chown -R mysql:mysql /var/lib/mysql
The file is not corrupt. You can find out the source of these errors with 'perror'. i.e.
toaster:~ morgo$ perror 13
OS error code 13: Permission denied
InnoDB has corruption detection (page checksums) and would happily tell you if that were the problem.
Either the directory permissions have changed, or your my.cnf file has been hosed, and it's trying to recreate data files somewhere else.
For me, restoring the security context (selinux) did the trick
restorecon -R /var/lib/mysql/
In short, (especially on RHEL/CentOS/Fedora) try
getenforce
if it replies with Enforcing you have SELinux up and running. Temporarily deactivate it with setenforce 0 and see if MariaDB starts now! Rather common, especially on RHEL/CentOS/Fedora.
There's more about this further down, as well as in this official article.
In general
There are more things in a UNIX environment that might prevent file access, than just user access rights.
Security modules like SELinux (see above) or AppArmor (as Dan mentioned) could disallow it
Access Control Lists (ACL) could be specifically set, for the required files/directories
Any of the parent folders could be owned by another user, and have no x (="dir access") set for others
Additionally there could be other unexpected factors, like ...
The mysql datadir being set to a place, where mysql doesn't have permissions (see /etc/my.cnf)
Mysql could (strangely) be running as a different user, or the file could be simply owned by someone else
Just to mention a view things off the top of my head (feel free to edit/add to this answer btw).
In the case, SELinux is "the problem"
For a permanent solution, you could try to restore the appropriate security context, ...
restorecon -R /var/lib/mysql/
... or just deactivate SELinux (but think about this one a little bit before doing so), by editing the config (typically in /etc/selinux/config) and setting SELINUX=disabled as suggested in following article.
Here the official help page from mariadb.com: What to do if MariaDB doesn't start
And here something from redhat.com: MariaDB Changing Database Location
Obviously those are applicable to MySQL just the same way.
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
ls -Z /var/lib/mysql
and
ls -Z /new/mysql/dir
If you see any difference it's likely to be your problem.
To modify this :
chcon -R --type=mysql_db_t /new/mysql/dir
The -R switch is for recursion. If you only need to change one file you can omit it.
If your context is different than mine(maybe a different distro), use the one indicated by the output of the first (it should be the 3rd field of the SELinux stuff)
ls -Z /var/lib/mysql
I had the same problem and fix by below steps
Working directory /var/lib/mysql
Earlier /var/lib/mysql was owned by some unknown user
Changed it to mysql
mysql]# chown -R mysql:mysql *
mysql]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service
Works like a charm
I had exactly the same problem on my CentOS box. After moving mysql data directory around I couldn't start the service anymore, even as I had copied the files with the same owner and permissions.
I had a problem with the SELinux security context. If you run your CentOS stock it has good chance to be enabled and won't let do what you want with MySQL. To fix this :
First compare the old dir and new dir using
ls -Z /var/lib/mysql
and
ls -Z /new/mysql/dir
If you see any difference it's likely to be your problem.
To modify this :
chcon -R --type=mysql_db_t /new/mysql/dir
The -R switch is for recursion. If you only need to change one file you can omit it.
When this popped up for me, I found the answer in the /etc/mysql/my.cnf configuration file. The datadir line did not point to the /var/lib/mysql directory (where the databases are). Once I put this path in, the server restarted no problem.
If you use SEL Linux
Intall semanage
yum whatprovides /usr/sbin/semanage you get policycoreutils-python-2.5-22.el7.x86_64
See mysqld security context
After installation yum install policycoreutils-python you can just look what different security context mysqld has.
semanage fcontext -l | grep mysqld
/etc/mysql(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/etc/my\.cnf\.d(/.*)? all files system_u:object_r:mysqld_etc_t:s0
/var/log/mysql.* regular file system_u:object_r:mysqld_log_t:s0
/var/lib/mysql(-files|-keyring)?(/.*)? all files system_u:object_r:mysqld_db_t:s0
/var/run/mysqld(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/var/log/mariadb(/.*)? all file system_u:object_r:mysqld_log_t:s0
/var/run/mariadb(/.*)? all files system_u:object_r:mysqld_var_run_t:s0
/usr/sbin/mysqld(-max)? regular file system_u:object_r:mysqld_exec_t:s0
/var/run/mysqld/mysqlmanager.* regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
/usr/lib/systemd/system/mysqld.* regular file system_u:object_r:mysqld_unit_file_t:s0
/usr/lib/systemd/system/mariadb.* regular file system_u:object_r:mysqld_unit_file_t:s0
/etc/my\.cnf regular file system_u:object_r:mysqld_etc_t:s0
/root/\.my\.cnf regular file system_u:object_r:mysqld_home_t:s0
/usr/sbin/ndbd regular file system_u:object_r:mysqld_exec_t:s0
/usr/libexec/mysqld regular file system_u:object_r:mysqld_exec_t:s0
/usr/bin/mysqld_safe regular file system_u:object_r:mysqld_safe_exec_t:s0
/usr/bin/mysql_upgrade regular file system_u:object_r:mysqld_exec_t:s0
/etc/rc\.d/init\.d/mysqld regular file system_u:object_r:mysqld_initrc_exec_t:s0
/var/lib/mysql/mysql\.sock socket system_u:object_r:mysqld_var_run_t:s0
/usr/libexec/mysqld_safe-scl-helper regular file system_u:object_r:mysqld_safe_exec_t:s0
/home/[^/]+/\.my\.cnf regular file unconfined_u:object_r:mysqld_home_t:s0
Here you see all context for mysqld a short list with explanation
mysqld_etc_t - config files
mysqld_db_t - data db files
mysqld_log_t - log files
mysqld_exec_t - execution files
So if you have the wrong security context on your files you get a permission denied (error 13)
Solution
chcon -R -u system_u -t mysqld_db_t /var/lib/mysql
But check the "normal" permissions, too. I had this problem with centos. You have to systemctl restart mysql for the changes.
In my siuation is Selinux's problem. And the
chcon -R --type=mysql_db_t /new/mysql/dir comes error:
chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.
So i use the command：chcon -R root:object_r:mysqld_db_t /new/mysql/dir.
If you have this problem on a Synology NAS you can fix it by following the advice of the Synology support team:
Dear User,
This has been confirmed as a known issue and we will try to fix this issue in further MariaDB release. Sorry for your inconvenience.
Here is the workaround:
Please try to telnet to your DS with "root" account and password (same as admin's)
run the command "echo 1 > /var/services/mysql/VERSION"
open MariaDB package from DSM will trigger update again
type in the DB password and click Update will fix this issue
More info: Synology forum
I had the same problem.
Did alot of research and found out this solution.
You need to run this command on ibdata1
sudo shadowprotect -u root | root
I dont know what this does.. but it worked for me.
Good luck.
I am trying to dump the contents of a table to a csv file using a MySQL SELECT INTO OUTFILE statement. If I do:
SELECT column1, column2
INTO OUTFILE 'outfile.csv'
FIELDS TERMINATED BY ','
FROM table_name;
outfile.csv will be created on the server in the same directory this database's files are stored in.
However, when I change my query to:
SELECT column1, column2
INTO OUTFILE '/data/outfile.csv'
FIELDS TERMINATED BY ','
FROM table_name;
I get:
ERROR 1 (HY000): Can't create/write to file '/data/outfile.csv' (Errcode: 13)
Errcode 13 is a permissions error, but I get it even if I change ownership of /data to mysql:mysql and give it 777 permissions. MySQL is running as user "mysql".
Strangely I can create the file in /tmp, just not in any other directory I've tried, even with permissions set such that user mysql should be able to write to the directory.
This is MySQL 5.0.75 running on Ubuntu.
Which particular version of Ubuntu is this and is this Ubuntu Server Edition?
Recent Ubuntu Server Editions (such as 10.04) ship with AppArmor and MySQL's profile might be in enforcing mode by default. You can check this by executing sudo aa-status like so:
# sudo aa-status
5 profiles are loaded.
5 profiles are in enforce mode.
/usr/lib/connman/scripts/dhclient-script
/sbin/dhclient3
/usr/sbin/tcpdump
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/sbin/mysqld
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode :
/usr/sbin/mysqld (1089)
0 processes are in complain mode.
If mysqld is included in enforce mode, then it is the one probably denying the write. Entries would also be written in /var/log/messages when AppArmor blocks the writes/accesses. What you can do is edit /etc/apparmor.d/usr.sbin.mysqld and add /data/ and /data/* near the bottom like so:
...
/usr/sbin/mysqld {
...
/var/log/mysql/ r,
/var/log/mysql/* rw,
/var/run/mysqld/mysqld.pid w,
/var/run/mysqld/mysqld.sock w,
**/data/ r,
/data/* rw,**
}
And then make AppArmor reload the profiles.
# sudo /etc/init.d/apparmor reload
WARNING: the change above will allow MySQL to read and write to the /data directory. We hope you've already considered the security implications of this.
Ubuntu uses AppArmor and that is whats preventing you from accessing /data/. Fedora uses selinux and that would prevent this on a RHEL/Fedora/CentOS machine.
To modify AppArmor to allow MySQL to access /data/ do the follow:
sudo gedit /etc/apparmor.d/usr.sbin.mysqld
add this line anywhere in the list of directories:
/data/ rw,
then do a :
sudo /etc/init.d/apparmor restart
Another option is to disable AppArmor for mysql altogether, this is NOT RECOMMENDED:
sudo mv /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
Don't forget to restart apparmor:
sudo /etc/init.d/apparmor restart
I know you said that you tried already setting permissions to 777, but as I have an evidence that for me it was a permission issue I'm posting what I exactly run hoping it can help. Here is my experience:
tmp $ pwd
/Users/username/tmp
tmp $ mkdir bkptest
tmp $ mysqldump -u root -T bkptest bkptest
mysqldump: Got error: 1: Can't create/write to file '/Users/username/tmp/bkptest/people.txt' (Errcode: 13) when executing 'SELECT INTO OUTFILE'
tmp $ chmod a+rwx bkptest/
tmp $ mysqldump -u root -T bkptest bkptest
tmp $ ls bkptest/
people.sql people.txt
tmp $
MySQL is getting stupid here. It tries to create files under /tmp/data/.... So what you can do is the following:
mkdir /tmp/data
mount --bind /data /tmp/data
Then try your query. This worked for me after hours of debugging the issue.
You can do this :
mysql -u USERNAME --password=PASSWORD --database=DATABASE --execute='SELECT `FIELD`, `FIELD` FROM `TABLE` LIMIT 0, 10000 ' -X > file.xml
This problem has been bothering me for a long time. I noticed that this discussion does not point out the solution on RHEL/Fecora. I am using RHEL and I do not find the configuration files corresponding to AppArmer on Ubuntu, but I solved my problem by making EVERY directory in the directory PATH readable and accessible by mysql. For example, if you create a directory /tmp, the following two commands make SELECT INTO OUTFILE able to output the .sql AND .sql file
chown mysql:mysql /tmp
chmod a+rx /tmp
If you create a directory in your home directory /home/tom, you must do this for both /home and /home/tom.
Some things to try:
is the secure_file_priv system variable set? If it is, all files must be written to that directory.
ensure that the file does not exist - MySQL will only create new files, not overwrite existing ones.
I have same problem and I fixed this issue by following steps:
Operating system : ubuntu 12.04
lamp installed
suppose your directory to save output file is : /var/www/csv/
Execute following command on terminal and edit this file using gedit editor to add your directory to output file.
sudo gedit /etc/apparmor.d/usr.sbin.mysqld
now file would be opened in editor please add your directory there
/var/www/csv/* rw,
likewise I have added in my file, as following given image :
Execute next command to restart services :
sudo /etc/init.d/apparmor restart
For example I execute following query into phpmyadmin query builder to output data in csv file
SELECT colName1, colName2,colName3
INTO OUTFILE '/var/www/csv/OUTFILE.csv'
FIELDS TERMINATED BY ','
FROM tableName;
It successfully done and write all rows with selected columns into OUTPUT.csv file...
In my case, the solution was to make every directory in the directory path readable and accessible by mysql (chmod a+rx). The directory was still specified by its relative path in the command line.
chmod a+rx /tmp
chmod a+rx /tmp/migration
etc.
I just ran into this same problem. My issue was the directory that I was trying to dump into didn't have write permission for the mysqld process. The initial sql dump would write out but the write of the csv/txt file would fail. Looks like the sql dump runs as the current user and the conversion to csv/txt is run as the user that is running mysqld. So the directory needs write permissions for both users.
You need to provide an absolute path, not a relative path.
Provide the full path to the /data directory you are trying to write to.
Does Ubuntu use SELinux? Check to see if it's enabled and enforcing. /var/log/audit/audit.log may be helpul (if that's where Ubuntu sticks it -- that's the RHEL/Fedora location).
I had the same problem on a CentOs 6.7
In my case all permissions were set and still the error occured. The problem was that the SE Linux was in the mode "enforcing".
I switched it to "permissive" using the command sudo setenforce 0
Then everything worked out for me.