MySQL error EE_WRITE (3) indicates a failure writing to a file, typically caused by permission problems, non-existent directories, or path issues with the tmpdir setting. This error blocks database operations until the underlying filesystem problem is resolved. Quick fixes include checking permissions, verifying directory existence, and ensuring the MySQL tmpdir points to a valid location.
MySQL Error EE_WRITE (3) occurs when the MySQL server fails to write to a file during operations that require disk access. The error code 3 typically maps to filesystem issues like missing directories or invalid paths rather than simple permission denials. This error can appear during: - Temporary file creation (during large queries, sorts, or GROUP BY operations) - Writing to the data directory (table files, log files) - Creating temporary tables or on-disk storage for result sets - Writing to binary logs or InnoDB redo logs - Backup or export operations Unlike EE_DISK_FULL (which means the disk is completely out of space), EE_WRITE (3) usually indicates a path problem: the directory doesn't exist, cannot be accessed, or the tmpdir configuration points to an invalid location. This is a filesystem-level error that prevents MySQL from completing write operations.
Log into MySQL and check where temporary files are supposed to be created:
-- View the tmpdir setting
SHOW VARIABLES LIKE 'tmpdir';
-- Also check related temp settings
SHOW VARIABLES LIKE '%temp%';
SHOW VARIABLES LIKE '%tmp%';Note the directory path shown for tmpdir. This is where MySQL expects to write temporary files.
From the shell, check if the tmpdir directory exists and has proper permissions:
# Replace /tmp with your tmpdir path from step 1
ls -la /tmp/
# Check specific permissions
stat /tmp
# Verify it's not a dead symlink
cd /tmp
pwd # Should show actual directory, not symlink targetLook for:
- Directory exists (not missing)
- Is not read-only: should show 'd' and 'w' in permissions (drwxr-xr-x or similar)
- Is not a broken symbolic link
- Path is reachable and not on an unmounted filesystem
If the directory is missing, create it with proper permissions:
# Create the directory (using /tmp as example)
sudo mkdir -p /tmp
# Set proper permissions for MySQL
sudo chmod 1777 /tmp
# Or if you have a custom tmpdir path
sudo mkdir -p /custom/mysql/tmpdir
sudo chmod 1777 /custom/mysql/tmpdir
# Verify permissions were applied
ls -la /custom/mysql/tmpdirThe 1777 permission means:
- Sticky bit (1): prevents users from deleting other users' temp files
- Full read/write/execute (777): for owner, group, and others
Ensure the MySQL system user can write to tmpdir:
# Find MySQL user and group (usually 'mysql')
id mysql
# Check current ownership
ls -la /tmp | head -20
# Fix ownership (important if directory was manually created or changed)
sudo chown -R mysql:mysql /custom/mysql/tmpdir
# Ensure write permissions exist
sudo chmod -R 755 /custom/mysql/tmpdir
# Verify
ls -la /custom/mysql/tmpdirMySQL must own (or have read+write access to) the tmpdir directory. If tmpdir is /tmp (shared), that's usually fine since /tmp has sticky bit enabled (tmpdir=1777).
If the tmpdir is on a problematic filesystem or too small, reconfigure it:
# Create a new tmpdir location (example: on a larger partition)
sudo mkdir -p /var/lib/mysql/tmp
sudo chown mysql:mysql /var/lib/mysql/tmp
sudo chmod 700 /var/lib/mysql/tmp
# Edit MySQL configuration
sudo nano /etc/mysql/mysql.cnf
# or /etc/mysql/my.cnf
# Add or modify the tmpdir setting under [mysqld]
[mysqld]
tmpdir = /var/lib/mysql/tmp
# Save and restart MySQL
sudo systemctl restart mysql
# Verify the setting took effect
mysql -u root -p -e "SHOW VARIABLES LIKE 'tmpdir';"Choose a new tmpdir location that:
- Is on a filesystem with plenty of free space (at least 50GB if handling large datasets)
- Is not shared with system logs or other heavy I/O
- Has good read/write performance (local SSD preferred over NFS)
If the error occurs during InnoDB operations, verify the temp tablespace:
-- Check InnoDB temp tablespace path
SHOW VARIABLES LIKE 'innodb_temp_data_file_path';
-- Check other relevant InnoDB paths
SHOW VARIABLES LIKE '%innodb%path%';
-- View temp tablespace status
SELECT * FROM INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO;If innodb_temp_data_file_path is set to a custom path:
# Verify the path exists and is writable
ls -la /path/to/innodb/temp/dir
# If not, create it
sudo mkdir -p /path/to/innodb/temp/dir
sudo chown mysql:mysql /path/to/innodb/temp/dir
sudo chmod 700 /path/to/innodb/temp/dirVerify that all filesystems have adequate space and are not in error state:
# Check disk space on all partitions
df -h
# Check inode usage (could be full even with space available)
df -i
# Check for filesystem errors in system logs
sudo journalctl -xe | grep -i filesystem
# If using LVM, check its status
sudo pvs
sudo lvs
sudo vgs
# Check mount options (tmpdir should not be mounted read-only)
mount | grep tmpdir
# Should NOT show 'ro' (read-only)If tmpdir is on a separate partition and shows 100% usage, either:
- Delete old temp files: sudo rm -rf /tmpdir/#sql*
- Expand the partition
- Point tmpdir to a different filesystem
After making changes, test that MySQL can write files again:
-- Simple test that uses tmpdir
SELECT * FROM your_table ORDER BY column1 LIMIT 1000;
-- Create a test temporary table
CREATE TEMPORARY TABLE test_tmp AS
SELECT * FROM information_schema.tables LIMIT 100;
-- Check if it succeeded
SELECT COUNT(*) FROM test_tmp;
-- Cleanup
DROP TABLE test_tmp;If these queries succeed without "Error writing file", the tmpdir issue is resolved.
After configuration changes, restart MySQL and confirm settings persisted:
# Restart MySQL service
sudo systemctl restart mysql
# Verify MySQL is running
sudo systemctl status mysql
# Check that new tmpdir setting is active
mysql -u root -p -e "SHOW VARIABLES LIKE 'tmpdir';"
# Monitor error log for any startup errors
tail -f /var/log/mysql/error.log &
# Run a workload test
# (run your typical queries)
# Kill the tail process when done
pkill tailMySQL should start cleanly without "Error writing file" messages in the error log.
Understanding MySQL Path Resolution:
When MySQL fails to access a path, it may show different error messages:
- EE_WRITE (3): Usually means path doesn't exist or is inaccessible
- EE_WRITE (13): Permission denied (EACCES)
- EE_WRITE (28): No space left on device (covered by EE_DISK_FULL)
The specific errno (number in parentheses) helps pinpoint the exact filesystem issue.
Custom tmpdir for Different Query Types:
You can optimize by using different tempdirs for different purposes (MySQL 8.0.16+):
SET SESSION tmpdir = '/var/lib/mysql/tmp';
-- Query uses this tmpdir for this session only
SELECT * FROM large_table GROUP BY column ORDER BY COUNT(*);NFS and Network Filesystem Considerations:
If tmpdir is on NFS (network-mounted):
- NFS can be slower for temp file I/O
- Connection issues cause "Error writing file"
- Consider moving tmpdir to local SSD if NFS is unreliable
- Add mount options like nolock,soft,timeo=100 for better reliability
Monitoring tmpdir Usage:
Track how much space temporary files consume:
# Monitor tmpdir in real-time
watch -n 1 'du -sh /tmp && echo "---" && ls -la /tmp | head -10'SELinux and AppArmor Restrictions:
If running with SELinux or AppArmor enforced:
- Custom tmpdir paths may be blocked by security policy
- Check logs: sudo ausearch -m app_armor
- Either add SELinux policy for new tmpdir or use standard /tmp
- Easier solution: stick with /tmp or /var/tmp
CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters
How to fix "CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters" in MySQL
CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed
How to fix "CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed" in MySQL
ERROR 1146: Table 'database.table' doesn't exist
How to fix "ERROR 1146: Table doesn't exist" in MySQL
ERROR 1040: Too many connections
How to fix "ERROR 1040: Too many connections" in MySQL
EE_READ (2): Error reading file
How to fix "EE_READ (2): Error reading file" in MySQL