The "MariaDB refused to start" error typically occurs when the database service lacks the necessary file system permissions to access its data directory or configuration files. This issue is most commonly resolved by correcting the ownership of the
/var/lib/mysql directory so that it belongs to the
mariadb user, ensuring the service can initialize correctly without security violations.
Understanding the Root Cause
When you attempt to start the MariaDB service on a Linux-based operating system, the daemon runs under a specific unprivileged user account, usually named
mariadb. If this user cannot read from or write to the data directory where database files are stored, the initialization process fails immediately. The system logs will explicitly report a permission denied error, indicating that the file ownership or group associations are incorrect.
This problem often arises after manual interventions such as copying data files from another server, changing the default data directory location, or performing partial updates to the database software. It can also happen if a previous installation was removed improperly, leaving behind files owned by the root user. Without the correct permissions, the MariaDB server refuses to bind to the network socket or open the necessary socket files for local connections.
Verifying Current Permissions
Before applying fixes, you should verify the current state of the data directory. Open your terminal and navigate to the parent directory of your MySQL data. By default, this is located at
/var/lib. Run the following command to list the details of the
mysql directory:
ls -ld /var/lib/mysql
You are looking for the user and group columns in the output. They should both display
mariadb or
mysql, depending on your distribution's naming convention. If you see
root listed as the owner, this confirms that the permission mismatch is the cause of the startup failure. Additionally, check the error log located at
/var/log/mariadb/mariadb.log or
/var/log/mysql/error.log for specific lines mentioning "Permission denied" during the startup sequence.
Correcting Ownership with chown
The primary solution involves recursively changing the ownership of the data directory to the database user. Use the
chown command to assign ownership to the
mariadb user and group. Execute the following command with sudo privileges:
sudo chown -R mariadb:mariadb /var/lib/mysql
The
-R flag ensures that all subdirectories and files within the data folder inherit the correct ownership. This step is critical because MariaDB creates numerous internal files, including transaction logs and temporary tables, which must be accessible to the service user. After running this command, verify the change by listing the directory again. The owner should now consistently show as
mariadb.
If your system uses
mysql instead of
mariadb as the username, adjust the command accordingly:
sudo chown -R mysql:mysql /var/lib/mysql
Adjusting File Permissions
While ownership is the most common culprit, file permissions themselves may also be too restrictive. Ensure that the data directory allows the owner to read, write, and execute, while allowing the group to read and execute. You can set these permissions using the
chmod command:
sudo chmod 750 /var/lib/mysql
This setting grants full access to the owner, read and execute access to the group, and no access to others. This level of restriction is secure and sufficient for the database service. Avoid using
777 permissions, as this poses a significant security risk by allowing any user on the system to modify database files.
Restarting the Service
Once permissions are corrected, restart the MariaDB service to apply the changes. Use the systemd init system commands to stop and start the service:
sudo systemctl stop mariadb
sudo systemctl start mariadb
Check the status of the service to confirm it is running without errors:
sudo systemctl status mariadb
If the service starts successfully, you will see an active (running) message. If it fails, re-check the error logs for any remaining issues, such as SELinux restrictions or incorrect configuration paths in
/etc/my.cnf.
Related Resources
For users encountering broader database management challenges, exploring additional troubleshooting guides can be beneficial. For instance, optimizing SQL dump loading times can help when restoring large datasets after fixing permission issues. You might find our guide on how to speed up SQL dumps loading useful for managing large-scale data migrations efficiently. Additionally, understanding how to prepare your server for performance updates can prevent future stability issues. Check out our article on waiting for MySQL/MariaDB server readiness for updates to ensure your environment remains optimized.
Frequently Asked Questions
Why does MariaDB fail to start after moving the data directory?
Moving the data directory often leaves the new location owned by root or the original user. MariaDB requires explicit ownership of the new path to function. You must run
chown on the new directory path and update the
datadir setting in
my.cnf to point to the correct location before restarting the service.
How do I check if SELinux is blocking MariaDB?
SELinux can enforce strict policies that override standard Unix permissions. Check the audit log using
ausearch -m avc -ts recent for denials related to
mariadbd. If found, you may need to restore the default SELinux contexts with
restorecon -Rv /var/lib/mysql or adjust policies to allow database access.
What if the error persists after changing ownership?
Persistent errors may indicate issues with the socket file or network binding configurations. Verify that the
socket path in
my.cnf is writable by the
mariadb user. Also, ensure that no other processes are holding locks on the data files, which can happen if a previous instance crashed unexpectedly.
Can I use a different user for MariaDB?
Yes, you can configure MariaDB to run under a different user by modifying the
User directive in
my.cnf. However, you must also ensure that the new user has full read/write access to the data directory and that the group permissions are correctly aligned to avoid startup failures.
How do I reset MariaDB permissions safely?
To reset permissions safely, stop the service first, then recursively apply
chown and
chmod as described. Always backup your data directory before making bulk permission changes. This ensures you can restore the original state if the new permissions cause unexpected behavior during the next startup attempt.