I have just installed MySQL 5.7 on a fresh CentOS 6.7(vm).

When I start the MySQL service with this command:

sudo service mysqld start

It doesn't start and raise this error:

Initializing MySQL database: 2015-12-07T11:00:51.060114Z 0 [Warning]
TIMESTAMP with implicit DEFAULT value is deprecated. Please use
--explicit_defaults_for_timestamp server option (see documentation for more details). 2015-12-07T11:00:51.062305Z 0 [ERROR]
--initialize specified but the data directory has files in it. Aborting. 2015-12-07T11:00:51.062347Z 0 [ERROR] Aborting [FAILED]

Do you know what is the problem?


I faced the same issue myself and I successfully resolved it. What needs to be done is: Open the my.conf file in vi editor and add a line under [mysqld]:

explicit_defaults_for_timestamp = 1

This will fix the first issue. Now check the access rights of the location pointed by datadir field and make sure mysql can access it. Worst case rename the location it points to. eg:


Yes, (I suppose it's bug of MySql) right now I have solved the same issue. In my case I have created separated partition (mount point) for MySQL database. There was created the directory "lost+found". You should temporary move it or other files or folders to any other place and clean /var/lib/mysql . After this just run again "sudo service mysqld start" then you will see something like this:

Initializing MySQL database: [ OK ]
Installing validate password plugin: [ OK ]
Starting mysqld: [ OK ]

Good luck.


You can follow the below steps

mysqld --initialize-insecure --user=username --datadir=datadir_path

you can also opt to --initialize-secure, but it would ask for root password as it was in previous versions with secure_installation.

Make sure the datadir is an empty created folder or else it will throw errors and then you can use following to start mysql:

./bin/mysqld_safe --defaults-file=path to cnf file


serivce mysqld start

Please check for error log file and share if you face any errors following above steps and do set root password once it is started.


I had a similar issue with Kubernetes and MySQL 5.7 as well.

Adding the suggestion from yosifki to my container's definition got things working.

A new ext4 disk partition is not usually empty; there is a lost+found directory, which mysql is known to choke on. You could try adding --ignore-db-dir=lost+found to the CMD to know for sure (from mysql docs)

Here's an extract of my working YAML definition:

name: mysql-master
image: mysql:5.7
  - "--ignore-db-dir=lost+found"

Here's an example snippet in docker-compose to clarify:

version: '3'
    image: mysql:5.7
    command: [--ignore-db-dir=lost+found]

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.