How to fix EE_READ (2): Error reading file in MySQL

MySQLINTERMEDIATEHIGHUpdated Dec 29, 2025· 170 views

Error 2 (EE_READ) occurs when MySQL cannot read a file it needs to access, typically due to file permissions, missing files, or filesystem issues. This error prevents database operations and requires checking file access rights and data integrity.

Quick fix

Fixes EE_READ (2): Error reading file

# View recent error log entries
sudo tail -100 /var/log/mysql/error.log
# or
sudo tail -100 /var/log/mysqld.log

# Search for EE_READ errors specifically
sudo grep "EE_READ|Error reading" /var/log/mysql/error.log | tail -20
  1. Check the MySQL error log for the specific file path
  2. Verify the file exists and is accessible
  3. Fix file permissions (most common cause)
  4. Disable and re-enable SELinux/AppArmor if needed
mysql — error
# View recent error log entries
sudo tail -100 /var/log/mysql/error.log
# or
sudo tail -100 /var/log/mysqld.log
# Search for EE_READ errors specifically
sudo grep "EE_READ|Error reading" /var/log/mysql/error.log | tail -20
EE_READ (2): Error reading file

What this error means

Error 2 (EE_READ) indicates that the MySQL server encountered a problem reading a file it requires. This can occur when MySQL tries to read data files, log files, configuration files, or files referenced by LOAD DATA INFILE statements. The error typically arises when: - The MySQL process lacks read permissions on the file - The file has been moved, deleted, or is inaccessible - The filesystem is experiencing I/O errors - SELinux or AppArmor security policies block the read operation - The file is locked by another process Unlike some SQL syntax errors, EE_READ indicates a system-level problem preventing access to required data, making it a critical issue that blocks query execution.

Typical symptoms

  • MySQL queries fail with "Error reading file" messages
  • Database operations hang or timeout waiting for file access
  • Restoring databases from backups fails during file reading
  • LOAD DATA INFILE operations fail even with valid input files
  • MySQL server fails to start or crashes on startup
  • Error log contains repeated "Error reading file" messages with specific paths
  • Operations fail only for certain tables or files, not all
  • The issue appears after filesystem maintenance or permission changes

Common causes

  1. File permissions are incorrect (MySQL user cannot read the file)
  2. File ownership is wrong (file not owned by mysql user or group)
  3. File or directory has been deleted or moved
  4. SELinux or AppArmor policies blocking file access
  5. Filesystem corruption or undetected disk errors
  6. File is locked or in use by another process
  7. Disk space full, preventing proper file operations
  8. Incorrect file path in configuration or LOAD DATA statement
  9. Network filesystem (NFS, CIFS) connectivity or permissions issues

How to fix "EE_READ (2): Error reading file"

1Check the MySQL error log for the specific file path

The error log contains which file MySQL failed to read. Find and examine it:

On Linux/macOS:

bash
# View recent error log entries
sudo tail -100 /var/log/mysql/error.log
# or
sudo tail -100 /var/log/mysqld.log

# Search for EE_READ errors specifically
sudo grep "EE_READ|Error reading" /var/log/mysql/error.log | tail -20

On Windows:

bash
C:\ProgramData\MySQL\MySQL Server 8.0\Data\HOSTNAME.err

Look for the file path in the error message. The log will show something like:

bash
2024-01-15 10:23:45 123456 [ERROR] [MY-012345] EE_READ (2): Error reading file './mydb/mytable.ibd'

Note the exact path returned in the error.

2Verify the file exists and is accessible

Check if the file mentioned in the error actually exists and can be read:

For data files in the data directory:

bash
# List MySQL data directory
sudo ls -la /var/lib/mysql/
# or check specific database
sudo ls -la /var/lib/mysql/mydb/

# Check if the problem file exists
sudo ls -l /var/lib/mysql/mydb/mytable.ibd

If the file doesn't exist:
- The table may have been deleted by accident
- The file path in a LOAD DATA statement is incorrect
- A migration moved files unexpectedly

If the file exists, check if you can read it as a test user:

bash
# Try reading a small amount of the file
sudo head -c 100 /var/lib/mysql/mydb/mytable.ibd > /dev/null && echo "File is readable" || echo "File is not readable"
3Fix file permissions (most common cause)

The MySQL server runs as the 'mysql' user. It must have read permissions on all data files:

Check current permissions:

bash
# Check data directory ownership and permissions
sudo ls -la /var/lib/mysql/ | head -5
# Output should show: drwxr-x--- mysql mysql

# Check specific file/directory permissions
sudo ls -l /var/lib/mysql/mydb/

Fix permissions if needed:

bash
# Change ownership to mysql user and group
sudo chown -R mysql:mysql /var/lib/mysql/
# or for a specific database
sudo chown -R mysql:mysql /var/lib/mysql/mydb/

# Set correct permissions (750 for directories, 640 for files)
sudo chmod -R 750 /var/lib/mysql/
sudo chmod -R 640 /var/lib/mysql/**/*.{ibd,MYD,MYI}

# For specific table files
sudo chmod 640 /var/lib/mysql/mydb/mytable.ibd
sudo chown mysql:mysql /var/lib/mysql/mydb/mytable.ibd

Restart MySQL to verify the fix:

bash
sudo systemctl restart mysql
sudo systemctl status mysql
4Disable and re-enable SELinux/AppArmor if needed

Security modules can block MySQL file access even with correct permissions:

Check if SELinux is active (Linux):

bash
getenforce
# Output: Enforcing, Permissive, or Disabled

Check SELinux context on MySQL files:

bash
# View SELinux context
sudo ls -Z /var/lib/mysql/
# Should show: mysql_db_t for directories and files

# If context is wrong, restore it:
sudo restorecon -Rv /var/lib/mysql/

Check AppArmor (Ubuntu/Debian):

bash
sudo aa-status | grep mysql
# If in "enforce" mode and blocking, check the profile
sudo cat /etc/apparmor.d/usr.sbin.mysqld | grep "^/var/lib/mysql"

Temporarily allow all file access to test:

bash
# Put AppArmor in complain mode (logs violations without blocking)
sudo aa-complain /usr/sbin/mysqld

# Restart MySQL and test
sudo systemctl restart mysql

# Check if error is gone
# If gone, AppArmor was the issue; create custom profile or use enforce after fixing
5Check filesystem health for I/O errors

Disk errors can cause read failures even if the file exists:

Check system logs for I/O errors:

bash
# Linux: check kernel messages for disk errors
dmesg | grep -i "io error|i/o error" | tail -20

# or check syslog
sudo grep -i "i/o error" /var/log/syslog | tail -20

Run filesystem check (requires MySQL shutdown):

bash
# First, stop MySQL
sudo systemctl stop mysql

# Check filesystem (use -n flag for read-only first)
sudo fsck -n /dev/sda1

# If errors found, run repair (WARNING: can take time and may modify files)
sudo fsck -y /dev/sda1

# Restart MySQL
sudo systemctl start mysql

Monitor disk health with smartctl:

bash
# Check if SMART is available
sudo smartctl -i /dev/sda

# Run quick SMART self-test
sudo smartctl -t short /dev/sda
sudo smartctl -a /dev/sda | grep "SMART"
6Fix LOAD DATA INFILE file path issues

If the error occurs during LOAD DATA INFILE, the input file path may be incorrect:

Verify the input file exists and is readable:

bash
# Check if file exists
ls -l /path/to/input/file.csv

# Verify permissions for MySQL to read it
sudo cat /path/to/input/file.csv > /dev/null

Use correct absolute paths in LOAD DATA:

sql
-- WRONG: Relative path (MySQL runs from different directory)
LOAD DATA INFILE 'data.csv'
INTO TABLE mytable;

-- CORRECT: Absolute path
LOAD DATA INFILE '/var/lib/mysql-import/data.csv'
INTO TABLE mytable;

If file is outside /var/lib/mysql/, ensure permissions:

bash
# Allow MySQL to read from custom directory
sudo chown mysql:mysql /var/lib/mysql-import/
sudo chmod 750 /var/lib/mysql-import/
sudo chmod 640 /var/lib/mysql-import/data.csv

On Docker, mount volumes correctly:

bash
# Mount the CSV directory and set permissions
docker run -v /host/data:/data mysql:latest
# Then in MySQL:
# LOAD DATA INFILE '/data/file.csv' ...
7Recover corrupted table files

If the file is corrupt or partially unreadable, recovery may be necessary:

For MyISAM tables (older MySQL):

bash
# Stop MySQL
sudo systemctl stop mysql

# Run myisamchk to check and repair
sudo myisamchk -r /var/lib/mysql/mydb/mytable.MYI

# Restart MySQL
sudo systemctl start mysql

For InnoDB tables (MySQL 5.7+):

bash
# MySQL has built-in recovery, but if file is severely corrupt:
# 1. Stop MySQL
sudo systemctl stop mysql

# 2. Restore from backup (preferred method)
sudo cp /backup/mydb/mytable.ibd /var/lib/mysql/mydb/
sudo chown mysql:mysql /var/lib/mysql/mydb/mytable.ibd
sudo chmod 640 /var/lib/mysql/mydb/mytable.ibd

# 3. Start MySQL
sudo systemctl start mysql

For partial corruption, use innodb_force_recovery:

ini
# /etc/mysql/my.cnf
[mysqld]
innodb_force_recovery=3

Then restart MySQL. This allows reading from corrupted InnoDB files. After dumping data, restore the backup and remove the flag.

8Check for file locks and process interference

Another process may be locking the file:

Check what processes have files open:

bash
# Linux: list all processes accessing MySQL data directory
sudo lsof /var/lib/mysql/ | head -20

# Check for specific file
sudo lsof /var/lib/mysql/mydb/mytable.ibd

Check for stuck backup or replication processes:

bash
# See all MySQL-related processes
ps aux | grep mysql | grep -v grep

# Kill zombie mysqld processes if needed (use with caution)
# sudo kill -9 <pid>

If using NFS or network filesystem:

bash
# Check NFS mount status and locks
showmount -a /var/lib/mysql

# Remount NFS if stale:
sudo umount /var/lib/mysql
sudo mount /var/lib/mysql

# Or check if NFS server is available
ping <nfs-server-ip>

Advanced notes

InnoDB File-Per-Table Troubleshooting:
With innodb_file_per_table enabled (MySQL 5.6+), each table has its own .ibd file. If one .ibd file is corrupted, only that table is affected. Check individual table status:

sql
CHECK TABLE mytable;
-- If status is not OK, run:
REPAIR TABLE mytable;

Cluster/Replication Specific Issues:
In MySQL Cluster or InnoDB Cluster environments, nodes synchronize data files. If a node has permission issues, it may fail to read replicated files. Ensure consistent filesystem permissions across all nodes.

Docker and Container Permissions:
Docker containers run MySQL with specific user IDs. If permissions are set on the host OS, they may not translate to the container. Use proper volume mounting and --user flags:

bash
docker run --user mysql:mysql -v /host/data:/var/lib/mysql mysql:latest

Performance Schema for File Diagnostics:
MySQL 5.7+ includes file I/O instrumentation:

sql
SELECT * FROM performance_schema.file_io_waits_summary_by_instance
WHERE event_name LIKE '%read%'
ORDER BY count_read DESC;

Preventing EE_READ Errors:
1. Regular backups: Corrupted files are easier to recover if you have backups
2. Filesystem monitoring: Set alerts for I/O errors from dmesg/syslog
3. Regular permission audits: Ensure /var/lib/mysql stays owned by mysql:mysql
4. Monitor disk space: Keep filesystem at least 10-15% free
5. Use managed services: Cloud databases (AWS RDS, Azure Database) handle file management automatically

Frequently asked questions

What does "EE_READ (2): Error reading file" mean?
Error 2 (EE_READ) indicates that the MySQL server encountered a problem reading a file it requires. This can occur when MySQL tries to read data files, log files, configuration files, or files referenced by LOAD DATA INFILE statements. The error typically arises when: - The MySQL process lacks read permissions on the file - The file has been moved, deleted, or is inaccessible - The filesystem is experiencing I/O errors - SELinux or AppArmor security policies block the read operation - The file is locked by another process Unlike some SQL syntax errors, EE_READ indicates a system-level problem preventing access to required data, making it a critical issue that blocks query execution.
How do I fix "EE_READ (2): Error reading file"?
Error 2 (EE_READ) occurs when MySQL cannot read a file it needs to access, typically due to file permissions, missing files, or filesystem issues. This error prevents database operations and requires checking file access rights and data integrity.
What causes "EE_READ (2): Error reading file"?
File permissions are incorrect (MySQL user cannot read the file) File ownership is wrong (file not owned by mysql user or group) File or directory has been deleted or moved
Is the "EE_READ (2): Error reading file" 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