Bug #27973 Can't change location of InnoDB data and log files - error number 13
Submitted: 20 Apr 2007 9:11 Modified: 21 Apr 2007 20:21
Reporter: Eddie Duffy Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0.18 OS:Linux (Fedora Core 5)
Assigned to: CPU Architecture:Any
Tags: 13, 5, data, directory, error, innodb, log, MySQL

[20 Apr 2007 9:11] Eddie Duffy
Description:
We recently performed an upgrade from Fedora Core 4/MySQL 4.1.11-log to Fedora Core 5/MySQL 5.0.18-log. Well, I say upgrade. Actually, it was a complete reformat and reinstall, loading back the necessary files and config changes, etc. post-install.

The problem is, this time MySQL refuses to let us change the locations of the InnoDB data and log files from the default of /var/lib/mysql/.

We have a dedicated filesystem /database, where the ibdata<nn> and ib_logfile<nn> files all happily sat under the previous FC4/MySQL4 configuration. We are using the same my.cnf as before (based on my-huge.cnf), with all three innodb*_dir parameters set to /database/. This time, however, if we start MySQL with the 'service mysqld start' command, the error returned in /var/log/mysql.log is:

070418 16:37:42  mysqld started
070418 16:37:42  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 /database/ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.
070418 16:37:42  mysqld ended

At first, I thought this must be a simple access rights issue, but even with /database owned by mysql:mysql and with mode 777 set, it still failed with the same error. Then I thought we may have exceeded some maximum file size on the filesystem, but that appeared not to be the case, since reducing the file sizes in innodb_data_file_path changed nothing.

I've tried various locations for the database, and all have failed, apart from /var/lib/mysql2/, which worked.

The mysqld_safe command *does* seem to work, no matter what the location of the files has been set to. However, I'd rather we were able to set this as a proper level 3 service so that it gets stopped and started correctly on shutdown and restart. In any case, 'service mysqld start', when successful, is clearly running mysqld_safe anyway. When we have the innodb parameters set to /var/lib/mysql/, MySQL starts OK and a ps command shows that the mysqld process has been started from mysqld_safe.

I get the feeling I'm probably missing something embarrassingly obvious here, and yes, I have Read The Fine Manual, but I can't for the life of me see what's going wrong. Any ideas, folks?

How to repeat:
Run 'service mysqld start' under Fedora Core 5 / MySQL 5.0, with different location for InnoDB files.
[20 Apr 2007 9:18] Eddie Duffy
Our my.cnf file

Attachment: my.cnf (application/octet-stream, text), 5.05 KiB.

[20 Apr 2007 12:10] Valeriy Kravchuk
Thank you for a problem report. Please, send the results of:

ls -l /database

Please, check if SELinux is ON (it is, by default) on your FC5.
[20 Apr 2007 13:18] Eddie Duffy
The output from ls -l /database was fairly uninteresting as the files had not been created yet:

[root@cds02m ~]# ls -l /database
total 16
drwx------ 2 root root 16384 Apr 18 13:01 lost+found

But aha! SELinux was indeed enabled and enforcing. I've now changed the status to 'permissive' and MySQL starts/stop OK in all circumstances. (I can fine-tune SELinux later if I want to enforce it.)

[root@cds02m ~]# ls -l /database
total 2831100
-rw-rw---- 1 mysql mysql 2097152000 Apr 20 14:10 ibdata1
-rw-rw---- 1 mysql mysql   10485760 Apr 20 14:10 ibdata2
-rw-rw---- 1 mysql mysql  394264576 Apr 20 14:10 ib_logfile0
-rw-rw---- 1 mysql mysql  394264576 Apr 20 14:08 ib_logfile1
drwx------ 2 mysql mysql      16384 Apr 18 11:45 lost+found
[root@cds02m ~]# ps -fu mysql
UID        PID  PPID  C STIME TTY          TIME CMD
mysql     2875  2845  0 14:10 pts/0    00:00:00 /usr/libexec/mysqld --defaults-f

So many thanks for your help, Valeriy! It's all OK now.

Eddie.
[21 Apr 2007 20:21] Valeriy Kravchuk
Closed as caused by SELinux settings.