Introduction

The warning that the MySQL data directory is not owned by the mysql user usually means the server process may not have the correct file permissions to read, write, or protect its own database files. This is both a reliability issue and a security issue, because the data directory should normally be controlled by the account running the MySQL server.

Why Ownership Matters

The MySQL data directory contains:

• table files
• InnoDB data files
• logs
• metadata

If the directory is owned by the wrong user, MySQL may fail to start, fail to write, or run with an unexpectedly permissive security posture. Even if the server starts, the ownership mismatch is a signal that the installation or migration was not completed cleanly.

Check the Real Service User

Before fixing anything, verify which account the server actually runs as:

ps -ef | grep mysqld

Then inspect the directory ownership:

ls -ld /usr/local/mysql/data
ls -l /usr/local/mysql/data | head

The exact path varies by installation. On many Linux systems the data directory is under /var/lib/mysql, while custom or Homebrew-style installations may use something closer to /usr/local/mysql/data.

Correct the Ownership Carefully

If the MySQL server should run as mysql:mysql, fix ownership recursively:

sudo chown -R mysql:mysql /usr/local/mysql/data

Do this only after confirming the correct service account. Blindly changing ownership to mysql on a system using a different service user can make the problem worse instead of better.

It is also safer to stop MySQL before performing large permission corrections:

sudo systemctl stop mysql
sudo chown -R mysql:mysql /usr/local/mysql/data
sudo systemctl start mysql

Check Permissions Too

Ownership is not the only issue. Permissions also matter:

sudo find /usr/local/mysql/data -type d -exec chmod 750 {} \;
sudo find /usr/local/mysql/data -type f -exec chmod 640 {} \;

The exact mode policy can vary by platform and packaging, but the general principle is the same: the database service account should have access, and unrelated users should not.

Understand How the Problem Happens

This warning often appears after:

• restoring data from a backup as root
• copying files manually from another machine
• unpacking a tarball installation by hand
• switching between package-manager and custom MySQL installs

It can also happen after running administrative commands with sudo in the data directory and accidentally changing ownership on generated files.

Confirm the Server Starts Cleanly

After correcting ownership, check the service and error log:

sudo systemctl status mysql
sudo tail -n 100 /var/log/mysql/error.log

If the service still fails, the ownership warning may have been only one of several issues. InnoDB file permissions, AppArmor or SELinux restrictions, or a mismatched datadir path can all produce similar symptoms.

If this is a production instance, make sure you understand the maintenance window and backup posture before making recursive ownership changes. The warning is important, but the data directory is also the most sensitive part of the installation.

Common Pitfalls

• Running chown -R mysql:mysql without first verifying the actual MySQL service user on that machine.
• Fixing the top-level directory but forgetting files inside it.
• Treating the warning as cosmetic even though it can block startup or weaken security.
• Ignoring the package-specific data directory path and fixing the wrong folder.
• Changing ownership while the server is actively using the data directory without planning the maintenance window.

Summary

• The MySQL data directory should normally be owned by the user that runs the MySQL server.
• Verify the service user and actual datadir path before changing ownership.
• Correct both ownership and, when needed, the directory permissions.
• Recheck service status and error logs after the fix.
• Treat this warning as a real operational problem, not just a harmless message.