MySQL raises EE_READ (error code 2) when it cannot read a required file due to an operating-system I/O problem, missing path, or insufficient permissions.
MySQL Error 2: EE_READ occurs when the server cannot read a required file because of an OS-level I/O issue, wrong path, or bad permissions. Check the file path, verify OS permissions, and ensure disk health to resolve the error.
Error reading file '%s' (OS errno %d - %s)
MySQL throws the error message “Error reading file '%s' (OS errno %d - %s)” and labels it EE_READ when the storage engine requests a file that the operating system cannot supply. The error code 2 maps to the global EE_READ condition name in MySQL source.
This failure stops the current SQL statement and may abort transactions.
On busy production servers, repeated EE_READ errors can lead to query timeouts, replication lag, or service downtime, so prompt remediation is critical.
Missing or renamed data, index, or temporary files trigger EE_READ because the kernel returns ENOENT (no such file) to MySQL. If a script deletes a .frm or .ibd file while MySQL is running, any subsequent read fails.
Incorrect file permissions also block reads.
When mysqld runs under a dedicated user, the OS must allow that user read access to the directory path and file.
Disk I/O problems such as bad sectors, full filesystems, or read-only mounts force the OS to reject read requests, which then manifest as EE_READ.
First, inspect the full error message in the MySQL error log to capture the exact filename and OS errno.
OS errno 13 indicates permission denied, while 2 signals file not found.
Restore or recreate missing files from backup if ENOENT is returned. For permission errors, change ownership or mode so that the MySQL user can read the file.
If the disk is full or corrupted, free space, run fsck, or migrate data to a healthy volume, then restart MySQL.
During SELECT ...
INTO OUTFILE, EE_READ can appear when the server later attempts to open the written file for verification but the file resides on a read-only mount. Remounting with read-write or changing the secure_file_priv directory fixes the issue.
On replica nodes, a broken relay-log path triggers EE_READ. Recreate the directory, correct permissions, and issue START SLAVE to resume replication.
Keep datadir, tmpdir, and secure_file_priv on reliable storage with RAID and continuous monitoring.
Enforce strict change-management so no process removes database files while MySQL is online.
Use Galaxy’s versioned query library to avoid ad-hoc OUTFILE paths; endorsed queries point only to approved directories, reducing unexpected EE_READ incidents.
EE_WRITE (Error code 1) surfaces when MySQL cannot write to disk; solutions overlap with EE_READ but focus on write permissions and quota.
Error 1030 (HY000): Got error %d from storage engine often wraps EE_READ internally, signaling a lower-level file-system problem that needs identical troubleshooting.
.
No. EE_READ indicates any OS read failure. Missing files are common, but permission issues and disk errors also trigger it.
Yes, if you correct the file path or permissions, affected queries will succeed without restart. Disk repairs may still require downtime.
No. All MySQL storage engines route file reads through the same I/O layer, so EE_READ can occur with MyISAM, InnoDB, CSV, or archive tables.
Galaxy’s secure file export paths and query versioning reduce risky ad-hoc OUTFILE usage, while built-in permissions auditing flags unsafe directory references.
.avif)
.avif){kind=logo}
