MySQL Bugs: #82281: mysqld --initialize reports "Permission denied", regardless of permissions

Bug #82281	mysqld --initialize reports "Permission denied", regardless of permissions
Submitted:	19 Jul 2016 12:59	Modified:	20 Jul 2016 12:19
Reporter:	Leon Boot	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S2 (Serious)
Version:	5.7.13	OS:	Ubuntu (16.04 x86_64 4.4.0-31-generic)
Assigned to:		CPU Architecture:	Any

Description:
When altering the value of datadir in the /etc/mysql/mysql.conf.d/mysqld.cnf and performing an initialization by running mysqld --initialize, MySQL reports "mysqld: Can't create directory '/path/to/mysql-datadir/' (Errcode: 13 - Permission denied)" The datadir's parent location, "/path/to" in this example, exists, is owned by root and has permissions 0755.

How to repeat:
- Create a fresh Ubuntu 16.04 LTS server
- Add the MySQL APT repository using the method described on the MySQL website
- Install mysql-server
- Either:
  - Edit the /etc/mysql/mysql.conf.d/mysqld.conf file and set datadir to /path/to/mysql-data and make sure /path/to exists, is owned by root and has permissions 0755
  - Delete /var/lib/mysql
- Reinitialize the MySQL database using mysqld --initialize
- MySQL will report that it has no permissions to create the mysql datadir.
- Setting ownership to mysql:mysql or permissions to 0777 on the parent dir (/path/to if you've changed the datadir value in my.cnf) will result in the same error message
- Creating the datadir directory by hand using mkdir, setting the ownership to mysql:mysql and the permissions to 0750 and running mysqld --initalize again will result in an error message "mysqld: Can't create directory '/path/to/mysql-datadir/' (Errcode: 17 - File exists)"

It turns out AppArmor was causing the initialization to fail, since the datadir was located in a place the mysqld binary was not allowed to write to.

I found out after stumbling upon this page: https://dev.mysql.com/doc/refman/5.7/en/starting-server-troubleshooting.html. The following line got me thinking:

"Even with correct ownership, MySQL might fail to start up if there is other security software running on your system that manages application access to various parts of the file system. In this case, reconfigure that software to enable mysqld to access the directories it uses during normal operation."

So I started digging through the list of files provided by the mysql-community-server by running dpkg-query -l mysql-community-server and noticed the files created in /etc/apparmor.d. Not being familiar with AppArmor, I started looking for information about it and found out I could disable the mysqld profile by running aa-disable /usr/sbin/mysqld. After disabling the profile, I was able to run mysqld --initialize without any errors.

It might be a good idea to update the documentation, referring to specific packages such as AppArmor, to provide people with a better starting point.

Thank you for the feedback!
As you have noted already, there is already a generalized(including every single security system details is not possible) note which has been included in the manual stating "Even with correct ownership, MySQL might fail to start up if there is other security software running on your system that manages application access to various parts of the file system. In this case, reconfigure that software to enable mysqld to access the directories it uses during normal operation." which is sufficient.

Also, some details are in the official oracle blogs - https://blogs.oracle.com/jsmyth/entry/apparmor_and_mysql

Thank you for your interest in MySQL.

Thank you.

[20 Jul 2016 9:11] Leon Boot
This answer was helpful for me.