I have around 6000 InnoDB tables across 15 databases, and using the innodb_file_per_table, I found out when everytime I reboot the Ubuntu server, the MySQL failed to start, with error..

Version: '5.1.56-rel12.7-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Percona Server (GPL), 12.7, Revision 224)
111106  5:09:00  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 ./db1/tbl182.ibd
InnoDB: File operation call: 'open'.

Since the filename of the problematic table (i.e. tbl182.ibd) is not the same everytime, so I suspect is due MySQL is doing something with all the tables?

However, when I restart using command (sudo /etc/init.d/mysql restart), MySQL can be started successfully. This is very strange!

My Env: MySQL version: 5.1.56-rel12.7-log (Ubuntu 10.04 LTS + Percona)


Problem solved by removing a large number of tables, so it should be something related to the file limit, not permission.

I have already changed /etc/init.d/mysql to hard coded value ulimit -n 50000, still not help when I creating massive tables.

  • when I restart using command -- using what command? – chx Nov 6 '11 at 5:54
  • sudo /etc/init.d/mysql restart – Howard Nov 6 '11 at 6:00
  • What's the hard filehandle limit for the mysql user? (You can check by su-ing to mysql and running "ulimit -Hn".) – Mike Scott Nov 6 '11 at 7:14
  • Could this simply be because you have two instances of MySQL installed, and one of them fails to start at boot? – Kvisle Nov 6 '11 at 11:58
  • @MikeScott, MySQL user does not have a shell, so I tried to edit the /etc/init.d/mysql script, and put ulimit -n 10000 at the beginning, does not help either. – Howard Nov 7 '11 at 14:47

The problem is not the limit on file handles. That would be error 24, not 13. The problem is what it says: permissions. I've seen this dozens of times, and even when people think that everything is set up correctly and has the right permissions, it IS permissions, every time, and someone always figures out that they missed something :) You either have permissions set wrong or you have something like the following:

  • There is a weird permission set on a higher level directory, such as / being restricted. (This sometimes matters.)
  • You have another process, such as two instances of mysqld, running and interfering with privileges.
  • SELinux or AppArmor is interfering.

You "solved" the problem by removing a large number of tables -- I don't think this is really a solution. You probably just removed some tables that had wrong permissions set on them :)

  • If it is due to the permission issue, the MySQL it will not able to start when I login into the shell and restart it manually. It only halt at boot time or I need to delete tables to make it start during boot. Anyway, I can restart manually using command everytime. – Howard Nov 13 '11 at 13:45
  • +1 for the 'having another process running' line. I killed that process and this problem disappeared. – allesklar Mar 25 '15 at 12:26

I'd recommend you to check write permission for DB user in the directory where your DB files are located.

  • I can succesfully start up the mysql when I enter the shell and type sudo /etc/init.d/mysql restart – Howard Nov 7 '11 at 14:35
  • @Howard So then the problem is solved. Post this as answer. – mailq Nov 9 '11 at 13:56
  • @mailq, the problem is not solved yet. – Howard Nov 9 '11 at 14:08

Is this an AppArmor issue? It could be something like AppArmor being started or killed between when you reboot and when you are trying to start it manually.

Check your syslog around the same times.

  • Update: Problem solved by removing a large number of tables, so it should be something related to the file limit, not permission. – Howard Nov 10 '11 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.