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.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.039 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.