Error 1449 de MySQL: el usuario especificado como definidor no existe


354

Cuando ejecuto la siguiente consulta me sale un error:

SELECT
  `a`.`sl_id`                     AS `sl_id`,
  `a`.`quote_id`                  AS `quote_id`,
  `a`.`sl_date`                   AS `sl_date`,
  `a`.`sl_type`                   AS `sl_type`,
  `a`.`sl_status`                 AS `sl_status`,
  `b`.`client_id`                 AS `client_id`,
  `b`.`business`                  AS `business`,
  `b`.`affaire_type`              AS `affaire_type`,
  `b`.`quotation_date`            AS `quotation_date`,
  `b`.`total_sale_price_with_tax` AS `total_sale_price_with_tax`,
  `b`.`STATUS`                    AS `status`,
  `b`.`customer_name`             AS `customer_name`
FROM `tbl_supplier_list` `a`
  LEFT JOIN `view_quotes` `b`
    ON (`b`.`quote_id` = `a`.`quote_id`)
LIMIT 0, 30

El mensaje de error es:

#1449 - The user specified as a definer ('web2vi'@'%') does not exist

¿Por qué recibo ese error? ¿Cómo lo soluciono?


77
Muéstrenos su SHOW CREATE VIEW 'view_quotes'
jordeu

El error debe estar en la condición de view_quotesvista.
Shell

Después de pensar en esto un momento y el curso de acción más simple fue agregar la cuenta que faltaba a la base de datos y el error desapareció. No se necesita un procedimiento complicado. Si puede agregar la cuenta, intente eso primero.
user1794918

Respuestas:


540

Esto ocurre comúnmente al exportar vistas / disparadores / procedimientos de una base de datos o servidor a otro, ya que el usuario que creó ese objeto ya no existe.

Tienes dos opciones:

1. Cambiar el DEFINER

Esto es posiblemente más fácil de hacer cuando se importan inicialmente los objetos de la base de datos, eliminando las DEFINERdeclaraciones del volcado.

Cambiar el definidor más tarde es un poco más complicado:

Cómo cambiar el definidor de vistas

  1. Ejecute este SQL para generar las declaraciones ALTER necesarias

    SELECT CONCAT("ALTER DEFINER=`youruser`@`host` VIEW ", 
    table_name, " AS ", view_definition, ";") 
    FROM information_schema.views 
    WHERE table_schema='your-database-name';
    
  2. Copie y ejecute las declaraciones ALTER

Cómo cambiar el definidor para procedimientos almacenados

Ejemplo:

UPDATE `mysql`.`proc` p SET definer = 'user@%' WHERE definer='root@%'

Tenga cuidado, porque esto cambiará todos los definidores para todas las bases de datos.

2. Crear el usuario perdido

Si ha encontrado el siguiente error al usar la base de datos MySQL:

The user specified as a definer ('someuser'@'%') does not exist`

Entonces puedes resolverlo usando lo siguiente:

GRANT ALL ON *.* TO 'someuser'@'%' IDENTIFIED BY 'complex-password';
FLUSH PRIVILEGES;

De http://www.lynnnayko.com/2010/07/mysql-user-specified-as-definer-root.html

Esto funcionó a las mil maravillas: solo tiene que cambiar someuserel nombre del usuario perdido. En un servidor de desarrollo local, normalmente puede usarlo root.

Considere también si realmente necesita otorgar ALLpermisos de usuario o si podrían hacerlo con menos.


1
. y no se requieren opciones de subvención.
helpse

@ Simon East: Has realizado una edición encantadora, muchas gracias por mejorar tanto la respuesta.
Chococroc

Sugiero agregar, reiniciar la instancia de mySQL después de ejecutar la consulta "UPDATE mysql. procP SET definer = 'user @%' WHERE definer = 'root @%'" ya que los definidores de los procedimientos solo se actualizan en ese momento.
johan

1
Creo que es más fácil agregar usuarios sin sentido, porque la próxima vez que haga un dbdump y lo importe, no necesitará volver a editar las vistas / procedimientos
DarkMukke

1
Gracias, acabo de descartar la tabla con el problema, la eliminé DEFINER=`user`@`host`y la reimporté. Trabajado como un encanto. : ok_hand:
giovannipds

139

El usuario que creó originalmente la vista o procedimiento SQL ha sido eliminado. Si vuelve a crear ese usuario, debería abordar su error.


3
Además, deberá otorgar al menos los privilegios SELECTy EXECUTEal usuario agregado. Me encontré con esto cuando exporté una copia de seguridad de DB de un servidor a otro donde el usuario que creó las rutinas no existía en el servidor de prueba.
drew010

55
Gracias, esto fue útil. A menudo, al migrar o implementar usando mysqldump, el usuario que creó el VIEW, TRIGGER o PROCEDURE (el definidor) puede no ser el mismo en el sistema de destino. En ese caso, simplemente recrear el procedimiento, disparar o ver ( DROPluego volver a CREATEusar) un usuario válido en el sistema de destino debería ser el truco.
Eric Kigathi

38
También puede cambiar quién es el definidor para un usuario existente:UPDATE mysql.proc SET definer = 'my_new_user@localhost' WHERE db = 'mydatatbase';

1
Exactamente en mi caso, tenía una tabla con disparador que apuntaba a un usuario DEFINER que fue eliminado. La actualización del usuario desencadenante resolvió el problema.
Miguel

También es necesario dar permiso para que el usuario :) GRANT ALL ON *.* TO 'someuser'@'%' IDENTIFIED BY 'complex-password'; FLUSH PRIVILEGES;
Victor

50

Recibí el mismo error después de actualizar mysql.

El error se ha solucionado después de este comando:

mysql_upgrade -u root

mysql_upgrade debe ejecutarse cada vez que actualice MySQL. Comprueba todas las tablas en todas las bases de datos en busca de incompatibilidades con la versión actual de MySQL Server. Si se descubre que una tabla tiene una posible incompatibilidad, se verifica. Si se encuentran problemas, se repara la tabla. mysql_upgrade también actualiza las tablas del sistema para que pueda aprovechar los nuevos privilegios o capacidades que podrían haberse agregado.


No estoy seguro de por qué esto no funcionó para mí, tuve que eliminar manualmente todos los desencadenantes en el banco de trabajo mySQL.
user752746


34

Crea el usuario eliminado así:

mysql> create user 'web2vi';

o

mysql> create user 'web2vi'@'%';

3
después de crear ese usuario perdido, encontró otro error: ERROR 1142 (42000): TRIGGER command denied to user 'web2vi'@'%' for table 'foo'y debería agregar este comando grant all on *.* to 'web2vi'@'%' identified by ''después de crear el usuario
zhuguowei

31

Sigue estos pasos:

  1. Ir a PHPMyAdmin
  2. Seleccione su base de datos
  3. Selecciona tu mesa
  4. En el menú superior, haga clic en 'Activadores'
  5. Haga clic en 'Editar' para editar el disparador
  6. Cambie el definidor de [usuario @ localhost] a raíz @ localhost

Espero eso ayude


1
Esta es la solución real a la pregunta, en lugar de crear usuarios y otorgar permisos. solo cambia el definidor.
Ankit Chauhan

¿Hay alguna forma de encontrar todos los desencadenantes en la base de datos?
Mrugesh Mistry

1
Buscar todos los factores desencadenantes: SHOW
TRIGGERS

Desde la línea de comando 'show triggerss', desde PhpMyAdmin seleccione la base de datos y luego, en la parte superior derecha de la barra de navegación, haga clic en los activadores
hussainfrotan

21

La solución es solo una consulta de una sola línea como se muestra a continuación:

grant all on *.* to 'ROOT'@'%' identified by 'PASSWORD' with grant option;

Reemplace ROOTcon su nombre de usuario mysql. Reemplace PASSWORDcon su contraseña mysql.


1
Tenga cuidado: los usuarios de MySQL distinguen entre mayúsculas y minúsculas.
Alessio Cantarella

Necesitaba flush privilegesdespués de esto y funciona. Gracias.
Victor

14

Se solucionó ejecutando los siguientes comentarios.

grant all on *.* to 'web2vi'@'%' identified by 'root' with grant option;
FLUSH PRIVILEGES;

Si está obteniendo en some_otherlugar de web2vi, debe cambiar el nombre en consecuencia.


13

Para futuros googlers: recibí un mensaje similar al intentar actualizar una tabla en una base de datos que no contenía vistas. Después de investigar un poco, resultó que había importado disparadores en esa tabla, y esas fueron las cosas definidas por el usuario inexistente. Soltar los disparadores resolvió el problema.


El problema era disparadores, actualicé el definidor en la sección de disparadores. No más problemas.
Darius

Gracias, es muy útil. También es necesario actualizar las vistas.
toxxxa

De hecho, muy útil :) Nunca lo encontraría solo.
ElChupacabra


7

Solución rápida para evitar y volcar el archivo:

mysqldump --single-transaction -u root -p xyz_live_db > xyz_live_db_bkup110116.sql

1
esto no funciona. el definidor está contenido en el basurero.
phil294

Si usa mysqlpump con una "p" en lugar de una "d", puede usar --skip-definer
Wouter

@lyhong No tengo una explicación detallada, pero aparentemente --single-transactioncambia la forma en que se implementan las tablas de bloqueo durante un volcado. O algo así. No recuerdo dónde lo leí, pero eso me ayudó a sentirme cómodo "simplemente arrojando la bandera". También estoy incómodo con las inexplicables "solo haz esto" "respuestas". De cualquier manera, funcionó para mi caso.
SherylHohman

7
grant all on *.* to 'username'@'%' identified by 'password' with grant option;

ejemplo:

grant all on *.* to 'web2vi'@'%' identified by 'password' with grant option;

Si le otorgo todos los privilegios a un 'usuario' @ 'todos los ips', ¿qué pasa con la seguridad?
Mohsen Abasi

@MohsenAbasi Este es un ejemplo para el entorno de desarrollo. Este usuario puede ser el administrador del sistema. El entorno de producción debe ser más cuidadoso.
mesutpiskin

7

Esto me sucedió después de mover la base de datos de un servidor a otro. Inicialmente, el definidor estaba usando localhost y el usuario. En el nuevo servidor no tenemos ese usuario, y el host también había cambiado. Hice una copia de seguridad de esa tabla en particular y eliminé todos los desencadenantes manualmente de phpmyadmin . Después de eso, ha estado funcionando bien para mí.


Gracias por el consejo, pude eliminar manualmente todos los disparadores en mySQL workbench.
user752746

Esto era de hecho un problema gatillo para mí, tuve que quitar y volver a crear todos ellos
paul.ago

¿Hay alguna otra solución que recrear desencadenantes? Estoy usando volcados de prueba a veces dos veces al día. esto interrumpiría mis procesos principales
redestructa

@TS Guhan, ¿volvió a agregar los desencadenantes después de eliminarlos manualmente?
MailBlade

6

Tuve el mismo problema con el usuario root y funcionó para mí cuando reemplacé

root@%

por

root@localhost

Entonces, si el usuario 'web2vi' puede conectarse desde 'localhost', puede intentar:

web2vi@localhost

Estoy conectado de forma remota a la base de datos.


4

Mis 5 centavos

Tuve el mismo error mientras intentaba seleccionar desde una vista.

Sin embargo, el problema parece ser que esta vista, seleccionada desde otra vista que fue restaurada desde una copia de seguridad desde un servidor diferente.

y de hecho, SÍ, el usuario no era válido, pero no era obvio a dónde ir desde el primer vistazo.


4

Tuve el mismo problema hace unos minutos, me encontré con este problema después de eliminar un usuario no utilizado de la tabla mysql.user, pero al solucionar una vista alternativa, aquí hay un comando útil que lo hace muy simple:

SELECT CONCAT("ALTER DEFINER=`youruser`@`host` VIEW ",
table_name," AS ", view_definition,";") FROM 
information_schema.views WHERE table_schema='databasename'

Mezcle esto con la línea de comando mysql (suponiendo * nix, no familiarizado con windows):

> echo above_query | mysql -uuser -p > alterView.sql
> mysql -uuser -ppass databasename < alterView.sql

Nota: el comando genera un SELECT CONCAT adicional en el archivo, haciendo que mysql -uuser -ppass databasename < alterView.sqlfalle si no lo elimina.

Fuente: /dba/4129/modify-definer-on-many-views


4

Intenta establecer tu procedimiento como SECURITY INVOKER

El valor predeterminado de Mysql establece la seguridad de los procedimientos como "DEFINER" (CREATOR OF) .. debe establecer la seguridad en el "invocador".


3

Su vista, "view_quotes" puede haber sido copiada de una base de datos diferente donde "web2vi" es un usuario válido en una base de datos donde "web2vi" no es un usuario válido.
Agregue el usuario "web2vi" a la base de datos o modifique la vista (normalmente eliminar la parte DEFINER = 'web2vi' @ '%' y ejecutar el script hará el truco)


3

En mi caso, la tabla tenía un activador con un usuario DEFINER que no existía.


2
justo en el clavo, especialmente cuando la aplicación se transfiere de un servidor a otro
zardilior

2

De la referencia de MySQL de CREATE VIEW:

Las cláusulas DEFINER y SQL SECURITY especifican el contexto de seguridad que se utilizará al verificar los privilegios de acceso en el momento de la invocación de la vista.

Este usuario debe existir y siempre es mejor usar 'localhost' como nombre de host. Así que creo que si comprueba que el usuario existe y lo cambia a 'localhost' en la vista de creación, no tendrá este error.


2

El problema está claro: MySQL no puede encontrar el usuario especificado como el definidor.

Encontré este problema después de sincronizar el modelo de base de datos del servidor de desarrollo, aplicarlo a localhost, realizar cambios en el modelo y luego volver a aplicarlo a localhost. Aparentemente, había una vista (modifiqué) definida, por lo que no pude actualizar mi versión local.

Cómo arreglar (fácilmente) :

Nota: implica la eliminación, por lo que funciona bien para las vistas, pero asegúrese de tener una copia de seguridad de los datos si lo intenta en las tablas.

  1. Inicie sesión en la base de datos como root (o lo que tenga el poder suficiente para realizar cambios).
  2. Elimina la vista, la tabla o lo que sea que tengas problemas.
  3. Sincronice su nuevo modelo: no se quejará de algo que no existe ahora. Es posible que desee eliminar la parte del DEFINIDOR DE SEGURIDAD de SQL de la definición del elemento con el que tuvo problemas.

PD: Esta no es una solución adecuada ni la mejor solución. Acabo de publicarlo como una posible (y muy simple) solución.


estoy usando sapo, cn elimino y vuelvo a crear usando eso solo os debería iniciar sesión como rooy desde la terminal y luego solo hacerlo?
Vasanth Nag KV

2

Puedes probar esto:

$ mysql -u root -p 
> grant all privileges on *.* to `root`@`%` identified by 'password'; 
> flush privileges;

2

¿Por qué recibo ese error? ¿Cómo lo soluciono?

Pasé una hora antes de encontrar una decisión para un problema como este. Pero, en mi caso, ejecuté esto:

mysql> UPDATE `users` SET `somefield` = 1 WHERE `user_id` = 2;
ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist

Si realmente desea encontrar el problema, simplemente ejecute estos comandos uno por uno:

SHOW PROCEDURE STATUS;
SHOW FUNCTION STATUS;
SHOW TRIGGERS;
SHOW FULL TABLES IN database_name WHERE TABLE_TYPE LIKE 'VIEW';

... y, después de cada uno de ellos, busque el campo 'definidor'.

En mi caso, era un gatillo viejo con barba, que alguien de los desarrolladores olvidó eliminar.


1

Vaya a la sección de edición de rutina y, en la parte inferior, cambie el Tipo de seguridad de Definidor a Invoker.


44
¿Ir a dónde? ¿En qué software?
kenorb

@kenorb, en phpMyAdmin puede cambiar las rutinas almacenadas de MySQL (procedimientos y funciones), por ejemplo, Tipo de seguridad.
Mikl

1

Una o varias de sus vistas fueron creadas / registradas por otro usuario. Deberá verificar el propietario de la vista y:

  1. Recrea al usuario; como dicen las otras respuestas. o
  2. Recree las vistas que fueron creadas por el usuario 'web2vi'usando ALTER VIEW

Tuve este problema una vez.

Intenté migrar vistas, de BD1 a BD2, usando SQLYog. SQLYog recreó las vistas en el otro DataBase (DB2), pero mantuvo al usuario de BD1 (donde eran diferentes). Más tarde me di cuenta de que las vistas que estaba usando en mi consulta tenían el mismo error que usted, incluso cuando no estaba creando ninguna vista.

Espero que esto ayude.


1

Si este es un procedimiento almacenado, puede hacer:

UPDATE `mysql`.`proc` SET definer = 'YournewDefiner' WHERE definer='OldDefinerShownBefore'

Pero esto no es aconsejable.

Para mí, la mejor solución es crear el definidor:

create user 'myuser' identified by 'mypass';
grant all on `mytable`.* to 'myuser' identified by 'mypass';

Tiene un error en su sintaxis SQL; consulte el manual que corresponde a la versión de su servidor MySQL para obtener la sintaxis correcta para usar cerca de 'grant all en' mytable '. * a' myuser 'identificado por' mypass ';' en la línea 1
Cerin

@Cerin, solo cambia '' alrededor de mytable a ``. Mi respuesta tiene como objetivo ayudar a las personas con este problema .. Piense de reconsiderar su downvote ..
helpse

1

cuando mysql.proc está vacío, pero el sistema siempre nota "user@192.168.%" para table_name no existe, simplemente rootea en la línea de comando mysql y escribe:

CHECK TABLE `database`.`table_name` QUICK FAST MEDIUM CHANGED;
flush privileges;

¡terminado!


1

Esto me sucedió después de que importé un volcado en Windows 10 con MYSQL Workbench 6.3 Community, con "root @% no existe". A pesar de que el usuario existió. Primero traté de comentar el DEFINER, sin embargo, esto no funcionó. Luego hice un reemplazo de cadena en "root @%" con "root @ localhost" y reimporté el volcado. Esto hizo el truco para mí.



0

El usuario de la base de datos también parece ser sensible a mayúsculas y minúsculas, por lo que aunque tenía un usuario raíz '@'%, no tenía un usuario ROOT '@'%. ¡Cambié el usuario a mayúsculas a través de workbench y el problema se resolvió!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.