Error 1018 occurs when MySQL cannot read a database or directory path because of missing file system permissions or OS security restrictions.
MySQL Error 1018: ER_CANT_READ_DIR signals that the server cannot read the specified directory, usually due to incorrect file permissions or SELinux/AppArmor blocks. Fix the issue by giving the MySQL user read-execute rights on the directory or adjusting security policies.
Can't read dir of '%s' (errno: %d - %s)
MySQL raises error 1018 when it fails to list or access the directory that stores a database or data file.
The message includes the directory path, the operating system errno, and a human-readable reason, revealing that the problem originates at the file-system layer.
Because MySQL needs read and execute permissions on every directory in the path to the data file, any OS-level restriction immediately blocks queries, backups, or replication tasks that touch that directory.
Missing UNIX permissions on the database directory are the most common trigger.
If you copy a database folder from another server without fixing ownership, MySQL cannot read it and returns error 1018.
SELinux or AppArmor profiles frequently deny directory access even when POSIX permissions look correct. Disk corruption, deleted directories, and wrong datadir settings also provoke the error.
Start by identifying the real directory path listed in the error.
Check that the mysql (or mariadb) system user owns the directory and has at least 750 permissions throughout the entire path.
If SELinux is enforcing, run `ausearch -m avc -ts recent` to surface denials, then add a boolean or custom policy to permit the read. For AppArmor, either place the directory under `/var/lib/mysql` or update the profile.
After copying a database folder, ownership often remains with root.
A quick `chown -R mysql:mysql /var/lib/mysql/dbname` resolves the error immediately.
On Ubuntu, AppArmor blocks `LOAD DATA INFILE` from arbitrary paths. Editing `/etc/apparmor.d/usr.sbin.mysqld` and reloading the profile unblocks the operation without weakening security.
Use native MySQL backups (mysqldump or mysqlpump) instead of manual file copies to preserve permissions. Keep all database directories inside the configured datadir.
Automate permission verification in deployment scripts and enable monitoring for OS security denials.
Regularly test restores on a staging server to catch directory permission issues early.
Galaxy’s desktop SQL editor surfaces server-side errors instantly, including full errno details, so engineers can debug 1018 in context. Integrated SSH workflows let users open the offending directory and fix permissions without leaving the editor.
.
The database directory or one of its parent folders is not owned by the MySQL service account, blocking read access.
A parent directory lacks the execute bit, preventing traversal even if the target folder itself is readable.
Mandatory access control systems deny mysqld from reaching directories outside the allowed policy paths.
The directory referenced in the error no longer exists or the file system is corrupted, making it unreadable.
The server points to a non-existent or moved datadir after an upgrade or migration, leading to error 1018 at startup.
.
Yes, if the original directory is corrupted or unreachable. Update my.cnf with a valid datadir, copy data, set correct permissions, and restart MySQL.
Disabling SELinux removes protections and is discouraged. Instead, add an allow rule for the specific directory.
No. GRANT manages database privileges inside MySQL but error 1018 stems from operating system permissions.
Galaxy displays the full MySQL error stack in-editor and links to documentation, so engineers can immediately address OS-level problems.
.avif)
.avif){kind=logo}
