MySQL Error 47: EE_FAILED_TO_OPEN_DEFAULTS_FILE – How to Fix and Prevent

What is MySQL Error 47 EE_FAILED_TO_OPEN_DEFAULTS_FILE?

The error string “Failed to open required defaults file” signals that MySQL tried to load configuration parameters from a defaults file (usually my.cnf) but could not open it.

MySQL 8.0.13 introduced error code 47 for this failure, which halts server startup or blocks client connections that specify an invalid --defaults-file option.

Fixing the issue quickly is critical because MySQL will not start or the mysql client will refuse to run without a readable defaults file. Production outages, broken CI pipelines, and failed automation scripts are common consequences.

.

What Causes This Error?

Missing files trigger the error most often. If the file referenced by --defaults-file or my-default.cnf is deleted or renamed, MySQL cannot load mandatory parameters and stops with code 47.

Incorrect paths also cause code 47. Typographical errors or relative paths that change between environments prevent MySQL from locating the configuration file.

Permission issues are another root cause. MySQL must read the file as the system user running mysqld or mysql.

Locked-down SELinux, AppArmor, or file ACLs can block access even when the path exists.

.

How to Fix MySQL Error 47 EE_FAILED_TO_OPEN_DEFAULTS_FILE

First verify that the file path is correct. Run ls -l /etc/my.cnf (or the path you specified) to confirm the file exists. Correct the --defaults-file command-line argument if necessary.

Next adjust ownership and permissions so the mysql OS user can read the file.

Typical safe settings are chown mysql:mysql /etc/my.cnf and chmod 640 /etc/my.cnf.

If the file truly is missing, recreate it from backup or regenerate a minimal my.cnf containing at least [mysqld] and datadir directives. Then restart the service with systemctl restart mysqld.

.

Common Scenarios and Solutions

Containerized deployments often mount a custom my.cnf. When the volume mount path is wrong, mysqld inside the container throws code 47. Correct the Docker -v parameter or Kubernetes ConfigMap path.

CI pipelines sometimes invoke the mysql client with --defaults-file=./ci.cnf. When the working directory changes, the relative path breaks. Switch to an absolute path such as /workspace/ci.cnf.

After an OS patch, SELinux can re-label files and block mysqld.

Use restorecon -Rv /etc or setenforce Permissive to test, then update SELinux policy rules.

.

Best Practices to Avoid This Error

Keep configuration files in a version-controlled repository and deploy them with automation to prevent accidental deletion.

Always use absolute paths with --defaults-file to avoid context changes that break relative locations.

Apply least-privilege permissions (640) but ensure the mysql user retains read access. Automated security hardening tools should whitelist my.cnf.

Monitor mysqld logs for “EE_FAILED_TO_OPEN_DEFAULTS_FILE” and alert immediately so you can restore the file before users notice downtime.

Related Errors and Solutions

Error 1 "EE_CANTCREATEFILE" occurs when MySQL cannot create the error log or PID file. Check disk space and directory write permissions.

Error 1296 "HY000 Got error 47 from storage engine" looks similar but is a storage-engine error, not a configuration file issue.

Error 1045 "28000 Access denied for user" appears after you fix code 47 but your my.cnf credentials are wrong. Update the [client] section with valid user and password lines.