The MySQL server failed to change the ownership of a data file because the operating system returned a permission-related error.
MySQL Error 31: EE_CHANGE_OWNERSHIP occurs when the server cannot change the file owner on disk, often due to restrictive OS permissions, mismatched UID/GID, or a read-only filesystem. Grant correct OS privileges or move the data directory to a writable location to resolve the issue.
Cannot change ownership of the file '%s' (OS errno %d - %s)
The error message "Cannot change ownership of the file '%s' (OS errno %d - %s)" means MySQL attempted to call chown on a data or log file and the operating system rejected the request. The server surfaces this failure as global error code 31 with condition name EE_CHANGE_OWNERSHIP.
The check usually happens when MySQL creates a new table, moves a tablespace, or initializes a new data directory.
Because the server must ensure that the mysqld user owns every database file, a failed ownership change blocks the entire operation.
Operating systems deny chown when the running user lacks CAP_CHOWN capability, when the target file resides on a read-only or root-squashed NFS mount, or when the file system is mounted with the nosuid or noacl options.
SELinux or AppArmor profiles can also intercept the call.
MySQL throws the same error if the mysqld process is running inside a container without the correct user namespace mapping. A mismatch between host UID/GID and container UID/GID prevents ownership updates.
First, verify that the mysqld user owns the entire datadir: ls -l /var/lib/mysql. If not, run chown -R mysql:mysql /var/lib/mysql as root.
Restart the server and retry the operation.
If chown still fails, confirm the file system is writable: mount | grep /var/lib/mysql. Remount with rw or relocate the datadir to a writable volume. When using Docker, add --userns=host or align UID/GID between host and container.
NFS mount: Mount with no_root_squash and ensure uid/gid mapping.
Alternatively, disable file-per-table and keep the InnoDB system tablespace on local storage.
SELinux/AppArmor: Set the correct context using chcon -R -t mysqld_db_t /var/lib/mysql or update /etc/apparmor.d/usr.sbin.mysqld.
Run mysqld under a dedicated system user that owns all database files. Validate permissions during deployment pipelines and CI/CD. Use Galaxy’s pre-run linting to flag writable path issues before executing DDL.
Prefer local or block storage for production data.
If containers are required, use consistent UID/GID mapping or rootless podman with delegated capabilities.
Error 1: ER_CANT_CREATE_FILE arises when MySQL cannot create a file, often due to similar permission problems. Fix by ensuring write access to the datadir.
Error 1018: ER_CANNOT_ADD_FOREIGN surfaces when foreign-key indexes cannot be created, sometimes caused by failed file operations. Verify permissions and path validity.
.
Yes. Changing file ownership needs root or CAP_CHOWN. A non-privileged user cannot resolve EE_CHANGE_OWNERSHIP.
No. Skipping ownership alignment risks data loss and security issues. Fix permissions immediately.
Galaxy surfaces permission warnings before it runs DDL. However, OS-level fixes still require administrator action outside Galaxy.
Mostly, but MyISAM and other engines also call chown when creating files, so the error can appear across storage engines.
.avif)
.avif){kind=logo}
