tl;dr Breaking change introduced in minor MySQL update, use
--no-tablespaces option in
mysqldump from now on (recommended) or add the global
PROCESS privilege to the user running the command.
I experienced the same issue on some of my machines. Not all at once, not on all commands, not on all users.
Why not all at once?
Turns out this is a breaking change introduced in MySQL minor updates 5.7.31 and 8.0.21 in 2020/07.
See 5.7.31 Release Notes / 8.0.21 Release Notes
Incompatible Change: Access to the INFORMATION_SCHEMA.FILES table now requires the PROCESS privilege.
This change affects users of the mysqldump command, which accesses tablespace information in the FILES table, and thus now requires the PROCESS privilege as well. Users who do not need to dump tablespace information can work around this requirement by invoking mysqldump with the --no-tablespaces option. (Bug #30350829)
The said issue number should be available here http://mybug.no.oracle.com/orabugs/bug.php?id=30350829. Oracles bug tracker seems to be down however. Another public issue is https://bugs.mysql.com/bug.php?id=100219.
So this issue has to happen on all machines having MySQL >= 5.7 and getting system updates eventually.
Breaking Changes in minor updates are unexpected. This is a security issue however. It's a pity that this issue and how to solve it is not communicated better. Imho a more practical solution for this breaking change would be to removed tablespaces in
mysqldump by default and add a
--add-tablespaces option instead.
Why not on all commands?
The said privilege
PROCESS is not needed for most use cases.
mysqldump however tries to access the
INFORMATION_SCHEMA.FILES table, which - as said above - now requires the PROCESS privilege.
mysqldump now needs to be started by a user with enough privileges or using the
See mysqldump documentation
mysqldump requires at least the SELECT privilege for dumped tables, SHOW VIEW for dumped views, TRIGGER for dumped triggers, LOCK TABLES if the --single-transaction option is not used, and (as of MySQL 5.7.31) PROCESS if the --no-tablespaces option is not used. Certain options might require other privileges as noted in the option descriptions.
See --no-tablespaces documentation
This option suppresses all CREATE LOGFILE GROUP and CREATE TABLESPACE statements in the output of mysqldump.
See process documentation
The PROCESS privilege controls access to information about threads executing within the server (that is, information about statements being executed by sessions).
The PROCESS privilege also enables use of the SHOW ENGINE statement, access to the INFORMATION_SCHEMA InnoDB tables (tables with names that begin with INNODB_), and (as of MySQL 5.7.31) access to the INFORMATION_SCHEMA FILES table.
What a MySQL tablespace is why it is used is explained very well in another question on StackOverflow already.
General advice: Most users do not need the tablespace information and may therefore safely ignore it using the
If tablespaces are configured knowingly and willingly, then the user doing the mysqldumps should get sufficient privileges.
Why not on all users?
root user is not affected of course. Other users may or may not be affected depending on the way they are given privileges.
GRANT option adds privileges on a global level, or a single database, a single table, or even columns or routines. Some privileges, like the said
PROCESS privilege, need to be added on a global level.
See grant documentation
The following table summarizes the permissible privilege types that can be specified for the GRANT and REVOKE statements, and the levels at which each privilege can be granted.
| Privilege | Meaning and Grantable Levels |
| PROCESS | Enable the user to see all processes with SHOW PROCESSLIST. Level: Global. |
So the sql command
GRANT ALL PRIVILEGES ON somedatabase.* TO someuser@localhost; will add all available privileges to the user on one database only. Global privileges are added using
In my case most databases users had privileges for selected databases only. Check the users privileges with
SHOW GRANTS for someuser@localhost;.
To add the global privilege use the SQL command
GRANT PROCESS ON *.* TO someuser@localhost;. Don't do this unless you know about the consequences of this privilege. To the revoke the privilege use
REVOKE PROCESS ON *.* FROM someuser@localhost;.