How to fix EE_WRITE (3): Error writing file in MySQL

MySQLADVANCEDHIGHUpdated Dec 29, 2025· 110 views

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.

Quick fix

Fixes EE_WRITE (3): Error writing file

-- View the tmpdir setting
SHOW VARIABLES LIKE 'tmpdir';

-- Also check related temp settings
SHOW VARIABLES LIKE '%temp%';
SHOW VARIABLES LIKE '%tmp%';
  1. Check the current tmpdir configuration
  2. Verify the tmpdir directory exists and is accessible
  3. Create tmpdir if it does not exist
  4. Fix permissions on tmpdir for MySQL user
mysql — error
-- View the tmpdir setting
SHOW VARIABLES LIKE 'tmpdir';
-- Also check related temp settings
SHOW VARIABLES LIKE '%temp%';
SHOW VARIABLES LIKE '%tmp%';
EE_WRITE (3): Error writing file

What this error means

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.

Typical symptoms

  • Large SELECT queries with GROUP BY, ORDER BY, or JOIN fail with "Error writing file"
  • CREATE TEMPORARY TABLE operations fail midway
  • ALTER TABLE or online DDL operations fail during temp file creation
  • Error message shows: "Got error: X 'EE_WRITE (3): Error writing file' from storage engine"
  • InnoDB temp tablespace cannot expand or initialize
  • Binary log operations fail with write errors
  • MySQL error log shows repeated "Error writing file" messages with specific directory paths
  • Application queries work for small datasets but fail when MySQL needs to use tmpdir for large result sets

Common causes

  1. tmpdir configuration points to a non-existent directory
  2. tmpdir directory deleted or moved after MySQL startup
  3. Insufficient permissions on tmpdir for the MySQL system user
  4. tmpdir mounted as read-only or on a filesystem with selinux restrictions
  5. tmpdir is on a different partition that is full (while data partition has space)
  6. Symbolic link in tmpdir path is broken or points to deleted location
  7. Network filesystem (NFS) mount for tmpdir is disconnected or unresponsive
  8. InnoDB temp tablespace path (innodb_temp_data_file_path) configured incorrectly
  9. Data directory path is invalid or inaccessible during initialization
  10. MySQL running as incorrect system user without read/write access to configured paths

How to fix "EE_WRITE (3): Error writing file"

1Check the current tmpdir configuration

Log into MySQL and check where temporary files are supposed to be created:

sql
-- 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.

2Verify the tmpdir directory exists and is accessible

From the shell, check if the tmpdir directory exists and has proper permissions:

bash
# 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 target

Look 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

3Create tmpdir if it does not exist

If the directory is missing, create it with proper permissions:

bash
# 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/tmpdir

The 1777 permission means:
- Sticky bit (1): prevents users from deleting other users' temp files
- Full read/write/execute (777): for owner, group, and others

4Fix permissions on tmpdir for MySQL user

Ensure the MySQL system user can write to tmpdir:

bash
# 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/tmpdir

MySQL 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).

5Change tmpdir if the current path is problematic

If the tmpdir is on a problematic filesystem or too small, reconfigure it:

bash
# 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)

6Check InnoDB temp tablespace configuration

If the error occurs during InnoDB operations, verify the temp tablespace:

sql
-- 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:

bash
# 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/dir
7Check filesystem and disk space

Verify that all filesystems have adequate space and are not in error state:

bash
# 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

8Test the fix with a simple query

After making changes, test that MySQL can write files again:

sql
-- 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.

9Restart MySQL and verify permanent fix

After configuration changes, restart MySQL and confirm settings persisted:

bash
# 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 tail

MySQL should start cleanly without "Error writing file" messages in the error log.

Advanced notes

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+):

sql
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:

bash
# 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

Frequently asked questions

What does "EE_WRITE (3): Error writing file" mean?
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.
How do I fix "EE_WRITE (3): Error writing file"?
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.
What causes "EE_WRITE (3): Error writing file"?
tmpdir configuration points to a non-existent directory tmpdir directory deleted or moved after MySQL startup Insufficient permissions on tmpdir for the MySQL system user
Is the "EE_WRITE (3): Error writing 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