My MySQL log shows duplicated errors:

141223  5:47:21 [ERROR] Invalid (old?) table or database name 'lost+found'

I have a database named #mysql50#lost+found but I cannot seem to delete it.

mysql> show databases;
| Database            |
| information_schema  |
| maindatabas         |
| maindatabas_help    |
| maindatabas_tracker |
| gitlabhq_production |
| locations           |
| #mysql50#lost+found |
| mysql               |
| osticket            |
| performance_schema  |
10 rows in set (0.00 sec)

mysql> DROP DATABASE `#mysql50#lost+found`;
ERROR 1008 (HY000): Can't drop database '#mysql50#lost+found'; database doesn't exist

I am operating Server version: 5.5.40 Distributed by The IUS Community Project on Centos 6.

Per MySQL is running VERY slow on CentOS 6x (not 5x), my datadir is on ext3 with the barrier=0 option.

What is causing this error, and how can it be eliminated?


It looks to me like your datadir is in a file system of its own.

Ext file systems, like most FSes under Unix, have at their root a directory called lost+found. It exists in order to allow files that become detached (that is, they have content, but no associated directory entry) to be reattached somewhere when an inconsistent file system is fscked (see, eg, https://unix.stackexchange.com/questions/18154/what-is-the-purpose-of-the-lostfound-folder-in-linux-and-unix for more details). This purpose is important in disaster-recovery, so you shouldn't delete the directory.

Your problem arises when the mount point, on which the file system that contains that directory is mounted, is given over entirely to an application that expects everything in that mount point to belong to it. MySQL being one such, it attempts to interpret the lost+found directory as being something db-related, and (not unreasonably) fails.

Your best bet is never to dedicate an entire FS to an application, but instead to mount the FS on some application-non-specific mount point, eg /data1, create a subdirectory under that, eg /data1/mysql, and reconfigure the application to use that directory as its datadir.


MadHatter explained well the error. But since then the times have changed and now MySQL (since 5.6.3) has an option to ignore this directory. Just add this statement into your /etc/mysql/my.cnf file:


After MySQL restart you can check it with command:

show global variables like 'ignore_db_dirs';

If you want to ignore multiple directories, you need specify the option for each of them separately.

Source: http://www.chriscalender.com/ignoring-the-lostfound-directory-in-your-datadir/


Location of my.cnf under CentOS 7.2 if You are using MariaDB is in


You can restart the service with

systemctl restart mariadb.service

ignore-db-dir should be put under [mysqld] section and not under [mysqld_safe] one.



# Disabling symbolic-links is recommended to prevent assorted security risks
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

# include all files from the config directory
!includedir /etc/my.cnf.d

MariaDb is ignore_db_dirs MySQL is ignore_db_dir - without the "s"

See https://mariadb.com/kb/en/library/server-system-variables/#ignore_db_dirs

I had a hidden directory as below


so in etc/my.cnf --- for MariaDB it was

[mysqld] ignore_db_dirs=.local

and restart the database server - then check the database is no longer in the SHOW DATABASES command or with MariaDB there is a " mysqlshow " from the command line

Then you may delete the directory and whatever is under it in /var/lib/mysql, then re-edit the /etc/my.cnf file and comment out the command or remove it, and restart the server again - the problem is fixed

DO NOT JUST DELETE THE UNWANTED DIRECTORY WITHOUT doing this above FIRST = as the datastore that the server keeps will be corrupted and you may not get it to restart again short of having to delete all databases and restore databases from backup or worse - and that is a BIG OUCH.


As our MySQL does not yet understand ignore_db_dirs, I did

# chmod 0 lost+found

which solved the (this) problem.

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.