INSERT command denied to user...

[gnzsoloyo]

Por lo que veo, todo bien, ¿no?

No.
En la lista que muestra no está el permiso de FILE, por lo que puedo suponer que el usuario de que dispones para crear usuarios no lo tiene, y por tanto no lo puede otorgar.

Vamos a leer lo que dice el link que ya te pasé al respecto:

Los permisos FILE, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHUTDOWN, y SUPER son permisos administrativos que sólo pueden darse globalmente (usando sintaxis ON *.* ).

Para los niveles global, base de datos, tabla y rutina, GRANT ALL asigna sólo los permisos que existen en el nivel que está otorgándolos. Por ejemplo, si usa GRANT ALL ON db_name.*, este es un comando de nivel de base de datos, así que ninguno de los permisos únicamente globales tales como FILE se otorgan.

Esto último quiere decir que lo que haces:

Código MySQL:

GRANT USAGE ON *.* TO 'bmx'@'localhost' IDENTIFIED BY PASSWORD '*AB1BA23DE35FD9D157B5445DB97253EBCF82AA53'
GRANT ALL PRIVILEGES ON `bmx\_tabla1`.* TO 'bmx'@'localhost'
GRANT ALL PRIVILEGES ON `bmx\_tabla2`.* TO 'bmx'@'localhost'
GRANT ALL PRIVILEGES ON `bmx\_tabla3`.* TO 'bmx'@'localhost'
GRANT ALL PRIVILEGES ON `bmx\_%`.* TO 'bmx'@'localhos
 

no otorga el privilegio de FILE, ni aunque lo tuvieses.

Haz una cosa básica:
Ejecuta un

Código MySQL:

SHOW GRANTS FOR CURRENT_USER;
 

Y veamos cuáles son los permisos que tiene el usuario que estás usando para crear y dar permisos.

Sin el permiso de FILE, no se puede leer un script de inserciones ni en localhost ni en el servidor. Es requisito indispensable para eso.
No es un permiso habitual en los hostings tercerizados (no lo suelen dar), precisamente porque se trata de un permiso peligroso´, ya que le permite al usuario ejecutar cualquier script nocivo.
Por eso no es habitual que se lo tenga.