{"id":2792,"date":"2023-04-10T04:39:36","date_gmt":"2023-04-10T04:39:36","guid":{"rendered":"http:\/\/kedar.nitty-witty.com\/?p=2792"},"modified":"2024-01-27T11:28:49","modified_gmt":"2024-01-27T11:28:49","slug":"1030-unknown-generic-error-from-engine-in-mysql","status":"publish","type":"post","link":"https:\/\/kedar.nitty-witty.com\/blog\/1030-unknown-generic-error-from-engine-in-mysql","title":{"rendered":"How to fix 1030 Unknown generic error from engine in MySQL"},"content":{"rendered":"\n

In this blog, I will share the steps I took to debug an error ‘ERROR 1030 (HY000): Got error 168 – ‘Unknown (generic) error from engine’ from storage engine’ while creating a table in MySQL on my lab machine.<\/p>\n\n\n\n

\"mysql-unknown-error-from-storage-engine\"
unknown-error-from-storage-engine<\/figcaption><\/figure>\n\n\n\n

I attempted to create a table using the following command:<\/p>\n\n\n\n

mysql> CREATE TABLE `email` (\n    -> `email_id` varchar(50) CHARACTER SET latin1 NOT NULL,\n    -> `email_from` varchar(255) CHARACTER SET latin1 NOT NULL,\n    -> `created_at` datetime NOT NULL,\n    -> `sent_at` datetime DEFAULT NULL,\n    -> PRIMARY KEY (`email_id`),\n    -> KEY `idx_email_created_at` (`created_at`),\n    -> KEY `idx_email_sent_at` (`sent_at`)\n    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;<\/code><\/pre>\n\n\n\n
However, I received the following error message:<\/p>\n\n\n\n
ERROR 1030 (HY000): Got error 168 – ‘Unknown (generic) error from engine’ from storage engine<\/h3>\n\n\n\n
I verified that the disk was functional by running the df -h command, which confirmed that there was enough space on the disk.
[root@ip-172-31-82-182 test]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.8G 0 3.8G 0% \/dev
tmpfs 3.8G 0 3.8G 0% \/dev\/shm
tmpfs 3.8G 564K 3.8G 1% \/run
tmpfs 3.8G 0 3.8G 0% \/sys\/fs\/cgroup
\/dev\/mapper\/rhel-root 19G 9.0G 11G 48% \/
\/dev\/xvda2 1014M 138M 877M 14% \/boot
tmpfs 777M 0 777M 0% \/run\/user\/1000
overlay 19G 9.0G 11G 48% \/var\/lib\/docker\/overlay2\/3c7a3368393279a5fc542cb3d177dc541d2af40a2e5cdb1e2945d892e032c975\/merged<\/code><\/pre>\n\n\n\n
I then turned to the error log, where I found the following error message:<\/p>\n\n\n\n
tail \/var\/log\/mysql\/mysqld.log\n...\n2023-04-07T12:52:31.975043Z 14489 [ERROR] [MY-012592] [InnoDB] Operating system error number 13 in a file operation.\n2023-04-07T12:52:31.975054Z 14489 [ERROR] [MY-012595] [InnoDB] The error means mysqld does not have the access rights to the directory.\n2023-04-07T12:52:31.975063Z 14489 [ERROR] [MY-012126] [InnoDB] Cannot create file '.\/test\/email.ibd'<\/code><\/pre>\n\n\n\n
hmmm\u2026 I see the “[InnoDB] Cannot create file” in MySQL error log and “perror” suggests that is “Permission denied”.<\/p>\n\n\n\n
[root@ip-172-31-82-182 test]# perror 13
OS error code 13: Permission denied
MySQL error code MY-000013: Can't get stat of '%s' (OS errno %d - %s)
[root@ip-172-31-82-182 test]#<\/code><\/pre>\n\n\n\n
I just decided to take the matter in my hands and try writing a file myself in that directory.<\/p>\n\n\n\n
[root@ip-172-31-82-182 test]# su mysql
This account is currently not available.<\/code><\/pre>\n\n\n\n
Wait what? This account is currently not available.<\/strong>  Not available? Is this the problem? Nope.<\/p>\n\n\n\n
[root@ip-172-31-82-182 ~]# cat \/etc\/passwd | grep mysql
mysql:x:27:27:MySQL Server:\/var\/lib\/mysql:\/sbin\/nologin
[root@ip-172-31-82-182 ~]#<\/code><\/pre>\n\n\n\n
The default shell for the user mentions \/sbin\/nologin. I just logged in specifying explicit shell.<\/p>\n\n\n\n
[root@ip-172-31-82-182 test]# su mysql -s \/bin\/bash
bash-4.4$ pwd
\/var\/lib\/mysql\/test
bash-4.4$ touch x
bash-4.4$ ls -lhtr
total 2.0M<\/code><\/pre>\n\n\n\n
-rw-r--r--. 1 mysql mysql 304K Apr 3 14:08 dupl_index_chk.ibd
-rw-r--r--. 1 mysql mysql 112K Apr 3 14:08 mytable.ibd
-rw-r--r--. 1 mysql mysql 112K Apr 3 14:08 user_email_settings.ibd
-rw-r--r--. 1 mysql mysql 112K Apr 3 14:08 t1.ibd
-rw-r--r--. 1 mysql mysql 0 Apr 7 13:55 x
bash-4.4$<\/code><\/pre>\n\n\n\n
So, I could touch the file with MySQL user in data directory but I couldn’t do that with MySQL client!<\/p>\n\n\n\n
I went on verifying which user MySQL is running with and it is “mysql”<\/p>\n\n\n\n
[root@ip-172-31-82-182 test]# ps -ef | grep mysqld
mysql 66740 1 0 Apr04 ? 00:31:19 \/usr\/libexec\/mysqld --basedir=\/usr<\/code><\/pre>\n\n\n\n
This time I vim-ed the error log and noted that the errors are for every table:<\/p>\n\n\n\n
[root@ip-172-31-82-182 test]# vi \/var\/log\/mysql\/mysqld.log
\u2026
2023-04-07T12:58:59.455500Z 0 [System] [MY-010116] [Server] \/usr\/libexec\/mysqld (mysqld 8.0.30) starting as process 1619218
2023-04-07T12:58:59.495718Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-04-07T12:58:59.504768Z 1 [Warning] [MY-012197] [InnoDB] Unable to open '.\/test\/user_email_settings.ibd'
2023-04-07T12:58:59.504768Z 1 [Warning] [MY-012197] [InnoDB] Unable to open
\u2026<\/code><\/pre>\n\n\n\n
Well, clearly something is blocking MySQL, and who other than firewalls? Immediately turned to SELinux. SELinux is a Linux kernel security module that provides a mechanism for supporting access control security policies.<\/p>\n\n\n\n
[root@ip-172-31-82-182 ~]# sestatus\nSELinux status: enabled\nSELinuxfs mount: \/sys\/fs\/selinux\nSELinux root directory: \/etc\/selinux\nLoaded policy name: targeted\nCurrent mode: enforcing<\/strong>\nMode from config file: enforcing\nPolicy MLS status: enabled\nPolicy deny_unknown status: allowed\nMemory protection checking: actual (secure)\nMax kernel policy version: 33\n[root@ip-172-31-82-182 ~]#\n[root@ip-172-31-82-182 test]# getenforce\nEnforcing<\/code><\/pre>\n\n\n\n
I checked the SELinux audit log by running the following command:<\/p>\n\n\n\n
[root@ip-172-31-82-182 test]# tail -f \/var\/log\/audit\/audit.log | grep mysql<\/p>\n\n\n\n
The output of the command showed that there were several denials related to MySQL:<\/p>\n\n\n\n
type=AVC msg=audit(1617792152.868:636): avc: denied { getattr } for pid=58278 comm=\"mysqld\" path=\"\/var\/lib\/mysql\/test\/email.ibd\" dev=\"xvda1\" ino=2880727 scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
type=AVC msg=audit(1617792152.869:637): avc: denied { create } for pid=58278 comm=\"mysqld\" name=\"email.ibd\" scontext=system_u:system_r:mysqld_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0<\/code><\/pre>\n\n\n\n
These denials indicate that MySQL is being denied permission to create or access files in the \/var\/lib\/mysql directory.
To resolve this issue, we need to configure SELinux to allow MySQL to access the necessary files and directories as follows:<\/p>\n\n\n\n
[root@ip-172-31-82-182 ~]# chcon -Rv --type=mysql_db_t \/var\/lib\/mysql
changing security context of '\/var\/lib\/mysql\/mysql\/general_log.CSM'
changing security context of '\/var\/lib\/mysql\/mysql\/general_log.CSV'
changing security context of '\/var\/lib\/mysql\/mysql\/slow_log_214.sdi'
changing security context of '\/var\/lib\/mysql\/mysql\/slow_log.CSM'
changing security context of '\/var\/lib\/mysql\/mysql\/slow_log.CSV'
changing security context of '\/var\/lib\/mysql\/mysql\/general_log_213.sdi'
changing security context of '\/var\/lib\/mysql\/mysql'
changing security context of '\/var\/lib\/mysql\/performance_schema\/events_waits_his_85.sdi'
changing security context of '\/var\/lib\/mysql\/performance_schema\/error_log_83.sdi'
\u2026<\/code><\/pre>\n\n\n\n
Though in my lab machine I could just change the SELinux mode to “permissive” which allows operations that are not permitted in enforcing mode and logs those operations to the SELinux audit log.<\/p>\n\n\n\n
[root@ip-172-31-82-182 test]# setenforce 0
[root@ip-172-31-82-182 test]# getenforce
Permissive<\/code><\/pre>\n\n\n\n
[root@ip-172-31-82-182 ~]# sestatus
SELinux status: enabled
SELinuxfs mount: \/sys\/fs\/selinux
SELinux root directory: \/etc\/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
[root@ip-172-31-82-182 ~]#<\/code><\/pre>\n\n\n\n
I restarted MySQL which came up clean and I could create my table. I noted that the system was restarted and I hadn’t persisted the configuration earlier.<\/p>\n\n\n\n
[root@ip-172-31-82-182 ~]# uptime
18:50:14 up 1 days, 9:04, 1 user, load average: 0.26, 0.13, 0.11<\/code><\/pre>\n\n\n\n
TL;DR If you see Unknown (generic) error from engine, check SELinux \/ Firewall.<\/p>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
In conclusion, permissions errors in Linux can be frustrating and time-consuming to troubleshoot, but by understanding the root causes and common solutions, you can quickly resolve these issues and get back to work. This blog walks you through the steps of identifying and fixing the issue. Remember to always check the file and directory permissions, as well as the ownership and group settings, when encountering a permissions error. By following these best practices, you can avoid many common permissions errors and keep your MySQL on Linux system running smoothly.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"In this blog, I will share the steps I took to debug an error ‘ERROR 1030 (HY000): Got error 168 – ‘Unknown (generic) error from engine’ from storage engine’ while…\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[8,377],"tags":[537,535,531,534,358,427,544,545,533,107,543],"class_list":{"0":"post-2792","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-mysql","7":"category-mysql-articles","8":"tag-debugging","9":"tag-error","10":"tag-error-1030","11":"tag-got-error-168","12":"tag-innodb","13":"tag-mysql","14":"tag-mysql-error-2","15":"tag-permission-denied-2","16":"tag-selinux","17":"tag-storage-engine","18":"tag-unknown-error-2"},"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts\/2792","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/comments?post=2792"}],"version-history":[{"count":7,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts\/2792\/revisions"}],"predecessor-version":[{"id":3187,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/posts\/2792\/revisions\/3187"}],"wp:attachment":[{"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/media?parent=2792"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/categories?post=2792"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kedar.nitty-witty.com\/blog\/wp-json\/wp\/v2\/tags?post=2792"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}