Apagado del servidor de fallo de alimentación.

Mysql no va a empezar ahora.

El disco no esté lleno.
Syslog está por debajo de

Oct 11 15:03:31 joe mysqld_safe[24757]: started
Oct 11 15:03:31 joe mysqld[24760]: 101011 15:03:31  InnoDB: Operating system error number 13 in a file operation.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: The error means mysqld does not have the access rights to
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: the directory.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File name ./ibdata1
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: File operation call: 'create'.
Oct 11 15:03:31 joe mysqld[24760]: InnoDB: Cannot continue operation.
  • Comprueba los permisos para ibdata1 supongo? En /var/lib/mysql en debian y sus derivados, creo
  • Sí no ha cambiado nada. Los permisos son propiedad de mysql. El archivo debe estar dañado. Es la única cosa que puedo pensar en este momento.
InformationsquelleAutor eat_a_lemon | 2010-10-11

14 Comentarios

  1. 16

    El archivo no está corrupto. Usted puede encontrar la fuente de estos errores con ‘perror’. es decir,

    toaster:~ morgo$ perror 13
    OS error code  13:  Permission denied

    InnoDB ha corrupción de detección (sumas de comprobación de página) y volvería a decirle que si ese fuera el problema.

    Cualquiera de los permisos de directorio han cambiado, o tu a mi.cnf archivo ha sido una manguera, y un intento de recrear los archivos de datos en alguna otra parte.

    • Ok, así que ¿cómo puedo ajustar el permiso correcto para este archivo?
    • Es más probable que un usuario incorrecto/grupo que es r/w. De los oficiales de INSTALAR BINARIOS: shell> chown -R mysql . shell> chgrp -R mysql . shell> scripts/mysql_install_db –user=mysql # quitar este paso. shell> chown -R root . shell> chown -R de datos mysql
    • esta no es una solución
  2. 94

    Si usted está usando ubuntu o apparmor debe permitir este cambio en apparmor.

    Editar /etc/apparmor.d/usr.sbin.mysqld y cambio /var/lib/mysql con la nueva DATADIR.

    Se debe trabajar.

    • +1, me perdí el final / en el directorio nuevo en este archivo.
    • Gracias. Los directorios en apparmor conf no pueden ser enlaces y comando «servicio de apparmor reiniciar» también era necesario.
    • Tenía el mismo problema que el autor, pero usando CentOS. Esta respuesta me salvó. Deshabilitar selinux resuelto el problema.
    • Ubuntu 13.10, me salvó el día. No tiene SELinux instalado, pero no tienen apparmor. Gracias!
    • woooow gracias hombre.
    • apparmor perdido mi todo el día.
    • Después de la edición de la aplicación de la armadura de configuración asegúrese de reiniciar apparmor para que surta efecto
    • No veo cómo esta respuesta se refieren a la pregunta: ¿cuál es la nueva DATADIR ? que cambio son u hablando? la respuesta es acerca de un reinicio – no hubo ningún cambio?
    • Ubuntu 14.04, me salvó el día, también. Muchas gracias!
    • Me he perdido el final barra del nuevo directorio de datos. Muchas gracias.
    • Mira /var/log/kernl.log para ver que el archivo de acceso apparmor es el bloqueo. Esto puede no ser totalmente fácil de averiguar si, por ejemplo, tiene enlaces simbólicos de salir de su /var/lib/mysql carpeta. Por CIERTO, creo que el comportamiento en relación con los enlaces simbólicos cambiado desde ubuntu 14.04 a 16.04.

  3. 17

    De Error:

    101130 14:42:51 mysqld_safe mysqld del pid archivo /var/run/mysqld/mysqld.pid terminó 
    101130 18:07:58 mysqld_safe de Partida demonio mysqld con bases de datos desde /var/lib/mysql 
    101130 18:07:58 InnoDB: error del sistema Operativo número 13 en una operación de archivo. 
    InnoDB: El error medio mysqld no tiene los derechos de acceso a 
    InnoDB: el directorio. 
    InnoDB: nombre de Archivo ./ibdata1 
    InnoDB: operación de Archivo de la llamada: 'abrir'. 
    InnoDB: No se puede continuar la operación. 
    

    Solución de SeLinux de seguridad de SeLinux:

    [[email protected] ~]# service mysqld restart 
    Deteniendo mysqld: [ OK ] 
    Iniciando mysqld: [ FALLÓ ] 
    [[email protected] ~]# el comando restorecon-R /var/lib/mysql/
    [[email protected] ~]# service mysqld restart 
    Deteniendo mysqld: [ OK ] 
    Iniciando mysqld: [ OK ] 
    [[email protected] ~]# 
    
    • Acabo de selinux deshabilitado en el equipo y el problema desapareció. Gracias por señalarme a la dirección correcta!
  4. 13

    Para mí, restaurar el contexto de seguridad selinux () hizo el truco

    restorecon -R /var/lib/mysql/

    • He creado una nueva partición y montado /var/lib/mysql a ella. No iba a funcionar hasta que lo probé. Algo tiene sentido, supongo?
  5. 9

    por favor revise esta:

    chown -R mysql:mysql /var/lib/mysql
    • en OS X instalado con macports el usuario se _mysql y el directorio /opt/local/var/db/mysql5/, pero esto parece haber funcionado bien, muchas gracias.
    • Esto funcionó a la perfección para mí. El error me ocurrió mientras yo estaba jugando con /var/www carpeta que dan a los clientes el acceso a su carpeta de la aplicación.
  6. 5

    Yo tenía exactamente el mismo problema en mi CentOS cuadro. Después de mudarse de datos mysql directorio de alrededor no podía iniciar el servicio más, como yo había copiado los archivos con el mismo propietario y los permisos.

    He tenido un problema con el contexto de seguridad SELinux. Si ejecuta su CentOS stock tiene buena oportunidad para ser activado y no me deja hacer lo que quieras con MySQL. Para solucionar este problema :

    Primera comparar la edad de directorios y directorios nuevo utilizando

    ls -Z /var/lib/mysql 

    y

    ls -Z /new/mysql/dir

    Si usted ve alguna diferencia es probable que sea su problema.
    Para modificar esto :

    chcon -R --type=mysql_db_t /new/mysql/dir

    El modificador-R es la recursión. Si usted sólo necesita cambiar un archivo puede omitirlo.
    Si el contexto es diferente al mío(tal vez una diferente distribución), el uso de la indicada por la salida de la primera (que debe ser el 3er campo de la SELinux cosas)

    ls -Z /var/lib/mysql 
    • Después me encontré chcon -R --type=mysql_db_t /var/lib/mysql, yo tengo un montón de chcon: can't apply partial context to unlabeled file 'xxxxxx'. ¿Qué significa eso?
  7. 4

    En corto, (especialmente en RHEL/CentOS/Fedora) intentar

    getenforce

    si se responde con Enforcing tiene SELinux en marcha y funcionando. Desactivar temporalmente con setenforce 0 y ver si MariaDB empieza ahora! Bastante común, especialmente en RHEL/CentOS/Fedora.

    Hay más sobre esto más abajo, así como en este artículo.

    En general

    Hay más cosas en un entorno UNIX que podrían impedir el acceso a archivos, que acaba de derechos de acceso de usuario.

    • Módulos de seguridad como SELinux (ver arriba) o AppArmor (como se mencionó Dan) podría no permitir que
    • Listas de Control de acceso (ACL) podría ser establecido en concreto, para los archivos/directorios
    • Cualquiera de las carpetas puede ser propiedad de otro usuario, y no tienen x (=»dir acceso») establecido para los demás

    Además, podría haber otros factores inesperados, como …

    • El mysql datadir se establece en un lugar, donde mysql no tiene permisos (ver /etc/my.cnf)
    • Mysql podría (extrañamente) se ejecuta como un usuario diferente, o que el archivo podría ser simplemente la propiedad de alguien más

    Sólo para mencionar una manera de ver las cosas fuera de la parte superior de mi cabeza (siéntase libre de editar/añadir a esta respuesta por cierto).

    En el caso, SELinux es «el problema»

    Para una solución permanente, usted podría tratar de restaurar el contexto de seguridad adecuado, …

    restorecon -R /var/lib/mysql/

    … o simplemente desactivar SELinux (pero creo que esta un poco antes de hacerlo), por la edición de la configuración (normalmente en /etc/selinux/config) y la configuración de SELINUX=disabled como se sugiere en el artículo siguiente.

    Obviamente los que son aplicables a MySQL de la misma manera.

  8. 3

    Yo tenía el mismo problema y fijar por debajo de los pasos

    De trabajo del directorio /var/lib/mysql

    Anterior /var/lib/mysql era propiedad de algunos de usuario desconocido

    Cambió a mysql

    mysql]# chown -R mysql:mysql *

    mysql]# service mariadb start

    Redirecting to /bin/systemctl start mariadb.service

    Funciona como un encanto

    • funciona como un encanto 😉
  9. 2

    Cuando este apareció para mí, he encontrado la respuesta en el /etc/mysql/my.cnf archivo de configuración. El datadir línea no apuntan a la /var/lib/mysql directorio (donde las bases de datos). Una vez que me puse este camino, el servidor se reinicia no hay problema.

  10. 1

    Yo tenía exactamente el mismo problema en mi CentOS cuadro. Después de mudarse de datos mysql directorio de alrededor no podía iniciar el servicio más, como yo había copiado los archivos con el mismo propietario y los permisos.

    He tenido un problema con el contexto de seguridad SELinux. Si ejecuta su CentOS stock tiene buena oportunidad para ser activado y no me deja hacer lo que quieras con MySQL. Para solucionar este problema :

    Primera comparar la edad de directorios y directorios nuevo utilizando

    ls -Z /var/lib/mysql 

    y

    ls -Z /new/mysql/dir

    Si usted ve alguna diferencia es probable que sea su problema.
    Para modificar esto :

    chcon -R --type=mysql_db_t /new/mysql/dir

    El modificador-R es la recursión. Si usted sólo necesita cambiar un archivo puede omitirlo.

  11. 1

    Si utiliza SEL Linux

    Intall semanage

    yum whatprovides /usr/sbin/semanage usted obtener policycoreutils-python-2.5-22.el7.x86_64

    Ver mysqld contexto de seguridad

    Después de la instalación yum install policycoreutils-python sólo puede ver lo diferente contexto de seguridad mysqld tiene.

    semanage fcontext -l | grep mysqld
    /etc/mysql(/.*)?                       all files    system_u:object_r:mysqld_etc_t:s0
    /etc/my\.cnf\.d(/.*)?                  all files    system_u:object_r:mysqld_etc_t:s0
    /var/log/mysql.*                       regular file system_u:object_r:mysqld_log_t:s0
    /var/lib/mysql(-files|-keyring)?(/.*)? all files    system_u:object_r:mysqld_db_t:s0
    /var/run/mysqld(/.*)?                  all files    system_u:object_r:mysqld_var_run_t:s0
    /var/log/mariadb(/.*)?                 all file     system_u:object_r:mysqld_log_t:s0
    /var/run/mariadb(/.*)?                 all files    system_u:object_r:mysqld_var_run_t:s0
    /usr/sbin/mysqld(-max)?                regular file system_u:object_r:mysqld_exec_t:s0
    /var/run/mysqld/mysqlmanager.*         regular file system_u:object_r:mysqlmanagerd_var_run_t:s0
    /usr/lib/systemd/system/mysqld.*       regular file system_u:object_r:mysqld_unit_file_t:s0
    /usr/lib/systemd/system/mariadb.*      regular file system_u:object_r:mysqld_unit_file_t:s0
    /etc/my\.cnf                           regular file system_u:object_r:mysqld_etc_t:s0
    /root/\.my\.cnf                        regular file system_u:object_r:mysqld_home_t:s0
    /usr/sbin/ndbd                         regular file system_u:object_r:mysqld_exec_t:s0
    /usr/libexec/mysqld                    regular file system_u:object_r:mysqld_exec_t:s0
    /usr/bin/mysqld_safe                   regular file system_u:object_r:mysqld_safe_exec_t:s0
    /usr/bin/mysql_upgrade                 regular file system_u:object_r:mysqld_exec_t:s0
    /etc/rc\.d/init\.d/mysqld              regular file system_u:object_r:mysqld_initrc_exec_t:s0
    /var/lib/mysql/mysql\.sock             socket       system_u:object_r:mysqld_var_run_t:s0
    /usr/libexec/mysqld_safe-scl-helper    regular file system_u:object_r:mysqld_safe_exec_t:s0
    /home/[^/]+/\.my\.cnf                  regular file unconfined_u:object_r:mysqld_home_t:s0

    Aquí puedes ver todo el contexto para mysqld una lista corta con la explicación

    1. mysqld_etc_t – archivos de configuración
    2. mysqld_db_t de datos de ficheros de base de datos
    3. mysqld_log_t – archivos de registro
    4. mysqld_exec_t de ejecución de archivos

    Así que si usted tiene el mal contexto de seguridad de sus archivos de obtener un permiso denegado (13 de error)

    Solución

    chcon -R -u system_u -t mysqld_db_t  /var/lib/mysql

    Pero verificación de la «normal» de los permisos, también. He tenido este problema con centos. Usted tiene que systemctl restart mysql para los cambios.

  12. 0

    En mi siuation es Selinux del problema. Y el

    chcon -R --type=mysql_db_t /new/mysql/dir viene de error:

    chcon: failed to change context of /new/mysql/dir to root:object_r:mysql_db_t: Invalid argument.

    Por lo que utilizar el comando:chcon -R root:object_r:mysqld_db_t /new/mysql/dir.

  13. 0

    Si usted tiene este problema en un servidor NAS de Synology se puede solucionar siguiendo los consejos de Synology equipo de apoyo:

    Estimado Usuario,

    Esto ha sido confirmado como un problema conocido y vamos a intentar solucionar este problema en más MariaDB liberación. Lo siento por su inconveniencia.

    Aquí está la solución:

    • Por favor intente telnet a tu DS con la «raíz» de la cuenta y la contraseña (la misma del administrador)
    • ejecutar el comando «echo 1 > /var/servicios/mysql/VERSIÓN»
    • abrir MariaDB paquete de DSM se disparará de nuevo la actualización
    • tipo en la base de datos de contraseña y haga clic en Actualización de solucionar este problema

    Más info: Foro de Synology

  14. -9

    Yo tenía el mismo problema.
    Hice un montón de investigación y encontré esta solución.
    Usted necesita para ejecutar este comando en ibdata1
    sudo shadowprotect -u root | root

    No sé lo que esto hace.. pero a mí me funcionó.

    Buena suerte.

    • Usted debe abstenerse de añadir soluciones cuando los que no saben lo que hacen. Usted podría pedir a la gente a realizar las operaciones que provocan daños en el sistema.

Dejar respuesta

Please enter your comment!
Please enter your name here