How to fix EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue in MySQL

MySQLINTERMEDIATEHIGHUpdated Dec 22, 2025ยท 108 views

This MySQL error occurs when a configuration file has overly permissive file permissions that allow other users to read or write to it. MySQL enforces strict security by requiring config files to be readable/writable only by the current user.

Quick fix

Fixes EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue

# Common locations
ls -la /etc/mysql/my.cnf
ls -la /etc/my.cnf
ls -la ~/.my.cnf
ls -la /usr/local/mysql/my.cnf

# Check which files MySQL is reading
mysqld --help --verbose | grep -A 1 "Default options"
  1. Locate your MySQL configuration file
  2. Check current file permissions
  3. Set correct file permissions
  4. Restart MySQL server
mysql โ€” error
# Common locations
ls -la /etc/mysql/my.cnf
ls -la /etc/my.cnf
ls -la ~/.my.cnf
ls -la /usr/local/mysql/my.cnf
# Check which files MySQL is reading
mysqld --help --verbose | grep -A 1 "Default options"
EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue

What this error means

Error 53 (EE_CONFIG_FILE_PERMISSION_ERROR) was introduced in MySQL 8.0.13 as a security measure to prevent unauthorized access to configuration files. The error message states "%s should be readable/writable only by current user." When MySQL detects that a configuration file (typically my.cnf on Linux/Unix or my.ini on Windows) has permissions that allow other users to read or modify it, it will refuse to read the file and throw this error. This is intentional security behavior to prevent sensitive information like passwords from being exposed to unauthorized users. On Unix systems, MySQL specifically ignores configuration files that are world-writable (permissions like 777 or 666). The server requires that configuration files containing sensitive options be protected with restrictive permissions that limit access to the MySQL user account only.

Typical symptoms

  • MySQL server fails to start or restart
  • Client applications cannot connect using configuration file options
  • Error message indicates config file should be readable/writable only by current user
  • MySQL logs show permission-related warnings for my.cnf or my.ini files
  • Server starts successfully after removing or renaming the config file

Common causes

  1. Configuration file has world-writable or world-readable permissions (e.g., 777, 666, 644)
  2. File was created or copied with incorrect default permissions
  3. Multiple users edited the file using sudo or different accounts
  4. Deployment scripts or containers set overly permissive permissions
  5. File permissions were changed during system migration or backup restoration
  6. On Windows, the MySQL service user lacks proper read permissions to my.ini

How to fix "EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue"

1Locate your MySQL configuration file

First, identify which configuration file MySQL is trying to read. Common locations include:

Linux/Unix:

bash
# Common locations
ls -la /etc/mysql/my.cnf
ls -la /etc/my.cnf
ls -la ~/.my.cnf
ls -la /usr/local/mysql/my.cnf

# Check which files MySQL is reading
mysqld --help --verbose | grep -A 1 "Default options"

Windows:

powershell
# Common locations
C:\ProgramData\MySQL\MySQL Server 8.0\my.ini
C:\Windows\my.ini
C:\mysql\my.ini
2Check current file permissions

Verify the current permissions on the configuration file:

Linux/Unix:

bash
ls -l /etc/mysql/my.cnf

Look for permissions like:
- -rw-rw-rw- (666) - Too permissive, world-writable
- -rwxrwxrwx (777) - Too permissive, world-writable
- -rw-r--r-- (644) - Too permissive for files with passwords
- -rw------- (600) - Correct for files with sensitive data

Windows:

powershell
icacls "C:\ProgramData\MySQL\MySQL Server 8.0\my.ini"
3Set correct file permissions

Fix the file permissions to be restrictive:

Linux/Unix (for files with passwords/sensitive data):

bash
# Set permissions to 600 (read/write for owner only)
sudo chmod 600 /etc/mysql/my.cnf

# Ensure MySQL user owns the file
sudo chown mysql:mysql /etc/mysql/my.cnf

Linux/Unix (for general config files):

bash
# Set permissions to 644 (read/write for owner, read for others)
sudo chmod 644 /etc/mysql/my.cnf
sudo chown mysql:mysql /etc/mysql/my.cnf

Docker environments:

bash
# In your Dockerfile or docker-compose.yml
RUN chmod 0444 /etc/mysql/conf.d/*.cnf

Windows:

powershell
# Grant MySQL service user read permissions
icacls "C:\ProgramData\MySQL\MySQL Server 8.0\my.ini" /grant "NT AUTHORITY\NETWORK SERVICE:R"
4Restart MySQL server

After fixing permissions, restart MySQL to apply changes:

Linux (systemd):

bash
sudo systemctl restart mysql
# or
sudo systemctl restart mysqld

Linux (SysV init):

bash
sudo service mysql restart

macOS:

bash
brew services restart mysql

Windows:

powershell
net stop MySQL80
net start MySQL80

Docker:

bash
docker-compose restart mysql
5Verify the fix

Confirm MySQL is running and reading the config file:

bash
# Check MySQL status
sudo systemctl status mysql

# Connect to verify settings are loaded
mysql -u root -p -e "SHOW VARIABLES LIKE '%config_file%';"

# Check error log for permission warnings
sudo tail -f /var/log/mysql/error.log

If you see no permission errors in the logs and MySQL starts successfully, the issue is resolved.

Advanced notes

Security Best Practices:

1. Separate Config Files: Use different config files for different purposes:
- /etc/mysql/my.cnf (644) for general server settings
- ~/.my.cnf (600) for client credentials with passwords
- /etc/mysql/conf.d/ directory for included configs

2. AppArmor/SELinux Considerations:
- AppArmor profiles may restrict MySQL's access to config files outside standard paths
- Check AppArmor status: sudo aa-status | grep mysql
- Temporarily disable for testing: sudo aa-disable /usr/sbin/mysqld
- SELinux can also block access: sudo setenforce 0 (temporary)
- For permanent SELinux fixes, use chcon or create custom policies

3. Docker/Container Specifics:
- When mounting config files as volumes, ensure host file permissions are 0444 or 0644
- Avoid mounting files with 777 permissions from Windows hosts
- Use docker exec to check permissions inside the container

4. UMASK Settings:
- If files consistently have wrong permissions, check UMASK environment variable
- MySQL respects UMASK_DIR for database directory creation (default 0750)
- Set UMASK before starting mysqld if needed

5. Include Directive Permissions:
- Files referenced by !includedir directive must also have correct permissions
- On Unix: must end in .cnf extension
- On Windows: can be .ini or .cnf
- All included files are subject to the same permission checks

6. Related Error - Error 54:
- Error 54 (EE_IGNORE_WORLD_WRITABLE_CONFIG_FILE) is related
- Message: "World-writable config file '%s' is ignored"
- MySQL silently ignores world-writable files rather than throwing a hard error
- Check MySQL error log for warnings about ignored config files

Frequently asked questions

What does "EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue" mean?
13 as a security measure to prevent unauthorized access to configuration files. ini on Windows) has permissions that allow other users to read or modify it, it will refuse to read the file and throw this error. This is intentional security behavior to prevent sensitive information like passwords from being exposed to unauthorized users.
How do I fix "EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue"?
This MySQL error occurs when a configuration file has overly permissive file permissions that allow other users to read or write to it. MySQL enforces strict security by requiring config files to be readable/writable only by the current user.
What causes "EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue"?
Configuration file has world-writable or world-readable permissions (e.g., 777, 666, 644) File was created or copied with incorrect default permissions Multiple users edited the file using sudo or different accounts
Is the "EE_CONFIG_FILE_PERMISSION_ERROR (53): Config file permission issue" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading