I am not sure if this is the right Stack Exchange to post to or not (StackOverflow figured it belonged elsewhere, so maybe it will do better here?) but I keep receiving this MySQL error when I try to install Magento2 on a VPS (Centos6, MySQL 5.7.11):

SQLSTATE[HY000]: General error: 1030 Got error 168 from storage engine

I have searched around and have found that it has to do with InnoDB not being able to write to its data files. I have also found that people who have had the same 1030 error mostly receive a -1 or 28 error and both are easily identified as 1) innodb_force_recovery set to greater than 0 (I don't have this set in my my.cnf file), and 2) not enough disk space (I have 5GB left on the drive mysql is on).

I should note that it installs anywhere from 136-162 tables fine before it stops and errors out. After that I try to add the last table it errored on manually, it then exhibits symptoms similar to this issue:

Can't create table, but table doesn't exist

The MySQL manual says:

"Check the %d value to see what the OS error means. For example, 28 indicates that you have run out of disk space."

So my question(s) are:

  1. Does anyone know what the 168 code means? -OR-
  2. Where to find the list of "%d value" errors so I can hopefully get some idea for what else to try? I have Googled %d value mysql and other versions of these search criteria and don't get back any results of value (that I can decipher anyway)

What I have tried thus far:

  1. Adding a line to my fstab to up the storage of my /temp folder to 2GB
  2. I have tried to repair tables (which actually was not a good idea, that messed up a bunch of stuff)
  3. I tried to run the mysql_upgrade (I recently updated the MySQL install so I could install Magento2 so I was hoping I forgot to do that and that might work)
  4. Various other tinkering-type things that probably broke something else I don't know about...

If anyone has any insight on where these %d descriptions are or can point me in the right direction besides what's already out there for the -1 and 28 versions of this error, I would appreciate it. I am not a Database expert at all, but I've never had so much trouble installing into a database before, usually it's pretty straight forward.


After reviewing the log, this is the top-most part of the error and is the table it failed on:

 2016-05-15T15:08:22.610729Z 240 [ERROR] InnoDB: Unable to lock
 ./magento_test2/authorization_rule.ibd error: 37
 2016-05-15T15:08:22.610789Z 240 [ERROR] InnoDB: Operating system error
 number 37 in a file operation. 2016-05-15T15:08:22.610840Z 240 [ERROR]
 InnoDB: Error number 37 means 'No locks available'
 2016-05-15T15:08:22.610879Z 240 [Note] InnoDB: Some operating system
 error numbers are described at
 2016-05-15T15:08:22.610896Z 240 [ERROR] InnoDB: Cannot create file
 './magento_test2/authorization_rule.ibd' 2016-05-15T15:08:23.025333Z 0
 [ERROR] InnoDB: Unable to lock ./magento_test2/quote_address.ibd
 error: 37 2016-05-15 08:08:23 0x7f968ae75700  InnoDB: Assertion
 failure in thread 140284552238848 in file fil0fil.cc line 884 InnoDB:
 Failing assertion: success InnoDB: We intentionally generate a memory
 trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
 InnoDB: If you get repeated assertion failures or crashes, even
 InnoDB: immediately after the mysqld startup, there may be InnoDB:
 corruption in the InnoDB tablespace. Please refer to InnoDB:
 InnoDB: about forcing recovery. 15:08:23 UTC - mysqld got signal 6 ;
 This could be because you hit a bug. It is also possible that this
 binary or one of the libraries it was linked against is corrupt,
 improperly built, or misconfigured. This error can also be caused by
 malfunctioning hardware. Attempting to collect some information that
 could help diagnose the problem. As this is a crash and something is
 definitely wrong, the information collection process might fail.

I guess it's just not working very well in general.

  • What is the query/statement which ends in this error? I found one test case checking for this code - github.com/mysql/mysql-server/blob/5.7/mysql-test/suite/… and it seems to have something to do with InnoDB fulltext index helper tables and tablespaces configuration. If you can get the statement you might make a test case from it to help finding the culprit.
    – jkavalik
    May 14, 2016 at 10:19
  • Thanks for your response. The query is not always the same one. Same kind, but not the same one. Some times it stops before sometimes it stops later but since it's installing Magento it fails on creating a table (CREATE TABLE IF NOT EXISTS XXX....etc) of one type or another.
    – Rasclatt
    May 14, 2016 at 14:11
  • So it shows randomly? If you try to run the same statement just after receiving the error it would succeed?
    – jkavalik
    May 14, 2016 at 14:14
  • No, as above in my question, when I try adding the table manually from where I left off, it then says table exists, but it actually doesn't. Then I try to drop the table and it says it doesn't exist. Sometimes the database is pretty much toast, it won't let me add anymore tables.
    – Rasclatt
    May 14, 2016 at 14:16
  • I personally am hoping the 168 error code would give me more information on what it's doing but I don't know where to locate those error codes like it says on the MySQL manual site
    – Rasclatt
    May 14, 2016 at 14:19

1 Answer 1

[ERROR] InnoDB: Unable to lock ./magento_test2/authorization_rule.ibd error: 37
[ERROR] InnoDB: Error number 37 means 'No locks available'

Check your OS open file limit (for the mysql user) - ulimit -a and open files or maybe file locks for values between 256-512 (160 tables created, each having ibd/frm or frm/myi/myd for possible myisam table means a bit over 300 files) and try to make it higher.

  • After Googling, I think this is correct. I haven't tried the Magento installer but I have updated my /etc/security/limits.conf file and it installed one of my bigger databases where it previously failed....but I have completely messed up my VPS by fiddling so I have to probably get my provider to reset my whole container to default so I can start over with it. Anyway I think this will be the right direction, so thanks a lot for the info! I appreciate it.
    – Rasclatt
    May 16, 2016 at 8:03
  • 1
    Yeah, 1024 is unreasonably low for MySQL; this is a common problem with certain Operating Systems.
    – Rick James
    May 26, 2016 at 0:04
  • Another solution might be to lower table_open_cache in my.cnf, and perhaps some other settings.
    – Rick James
    May 26, 2016 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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