He nginx instalado con PHP-FPM en un CentOS 5 cuadro, pero estoy luchando para llegar a servir alguno de mis archivos ya sea PHP o no.

Nginx se ejecuta como www-data:www-data, y el defecto «Welcome to nginx en EPEL» sitio (propiedad de root:root con permisos 644) carga bien.

El archivo de configuración de nginx tiene una directiva include para /etc/nginx/sites-enabled/*.conf, y tengo un archivo de configuración ejemplo.com.conf, así:

server {
 listen 80;

 Virtual Host Name
 server_name www.example.com example.com;


 location / {
   root /home/demo/sites/example.com/public_html;
   index index.php index.htm index.html;
 }

 location ~ \.php$ {
  fastcgi_pass   127.0.0.1:9000;
  fastcgi_index  index.php;
  fastcgi_param  PATH_INFO $fastcgi_script_name;
  fastcgi_param  SCRIPT_FILENAME  /home/demo/sites/example.com/public_html$fastcgi_script_name;
  include        fastcgi_params;
 }
}

A pesar de public_html siendo propiedad de www-data:www-data con 2777 permisos de archivo, este sitio no sirve cualquier contenido

 [error] 4167#0: *4 open() "/home/demo/sites/example.com/public_html/index.html" failed (13: Permission denied), client: XX.XXX.XXX.XX, server: www.example.com, request: "GET /index.html HTTP/1.1", host: "www.example.com"

He encontrado muchos otros con los mensajes de los usuarios 403s de nginx, pero la mayoría que he visto implicar más complejas configuraciones con Ruby/Pasajero (que en el pasado la verdad es que he conseguido con) o sólo están recibiendo errores cuando la parte de arriba de PHP-FPM está involucrado, por lo que parecen ser de poca ayuda.

He hecho algo tonto aquí?

11 Comentarios

  1. 316

    Un requisito de permiso que es a menudo pasado por alto es una de las necesidades del usuario x permisos en cada directorio principal de un archivo para acceder a ese archivo. Comprobar los permisos en /, /home, /home/demo, etc. para www-data x acceso. Mi conjetura es que /en casa es probablemente 770 y www-data no puede chdir a través de ella para llegar a cualquier subdir. Si es así, intente chmod o+x /home (o lo que dir es negar la petición).

    EDIT: Para mostrar fácilmente todos los permisos en una ruta, puede utilizar namei -om /path/to/check

    • Mismo aquí. En mi instalación de CentOS 6, /home/usuario dirs se establecen a 700 por defecto.
    • Este chico habla demasiado: (chmod -4 +x /mypath trabajado para mí) nginxlibrary.com/403-forbidden-error
    • Alguien puede explicar por qué este comportamiento es diferente de apache que NO requiere que cada padre directorio de tener «x» de los permisos?!?
    • No es ningún diferente. La única razón por la que apache no requieren también x el permiso de los padres de los directorios es si se está ejecutando como root.
    • Terminé la adición de la www-data usuario a mi personal de grupo de usuario y hacer un chmod 710 a mi la raíz de la carpeta de usuario. Trabajó como un encanto. (En una distro basada en debian)
    • impresionante!!! me ha ayudado mucho!
    • Esta sugerencia ha sido útil dos veces hasta ahora. Gracias!
    • tanto el requisito de permiso y el namei consejo me ayudó a resolver mi problema.
    • Yo REALMENTE deseo que tenía de leer este hace 4 horas. Gracias.
    • He tenido que añadir +x a una carpeta principal de www/ aunque todas las sub-carpetas de www/ tenía el x-conjunto de bits. Wow, esto tomó un tiempo para averiguar!

  2. 276

    Si aún se puede ver permission denied después de verificar los permisos de las carpetas, puede ser SELinux la restricción de acceso.

    Para comprobar si SELinux está funcionando:

    # getenforce

    Deshabilitar SELinux hasta el próximo reinicio:

    # setenforce Permissive

    Reiniciar Nginx y ver si el problema persiste. Para permitir nginx para servir a su directorio www (asegúrese de apagar SELinux antes de que las pruebas de este. yo.e, setenforce Enforcing)

    # chcon -Rt httpd_sys_content_t /path/to/www

    Ver a mi respuesta aquí para más detalles

    • Yo no podía entender por qué cada vez que empecé a nginx dijo open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied) después de revisar los permisos y se aseguró de que se está iniciando como root. Me encontré con este lugar y se encontró SELinux fue habilitado. He desactivado y ahora funciona sin problema. Gracias!
    • Gracias! Yo todavía tenía un problema con permiso denegado para los usuarios que poseen su propia FPM sockets con lo que yo era capaz de solucionar que uno cambiando el user de nginx a root en /var/nginx/nginx.conf – tal vez eso va a ayudar a alguien que viene a través de este problema. S/S DataPsyche para la segunda parte.
    • creo centos 6.6 tiene un error. Selinux rompe nginx.
    • Este es el comportamiento por defecto en CentOS 7 aswell.
    • Gracias gracias. El 95% De la información sobre esta son acerca de los permisos, pero cuando se establece 775, yo realmente estaba tirando de mi para escuchar (todos los 6 de ellos).
    • Im con todos los demás que comentaron. Yo estaba dispuesto a tirar mi ordenador por la ventana. Nginx fue configurado correctamente, los permisos de donde se configura correctamente, incluso me llegó a hacer todo 777 y todavía tiene permisos denegado.
    • La mejor SELinux comando es la siguiente: el comando semanage fcontext-a -t httpd_sys_rw_content_t «/path/to/www(/.)?»* y el comando restorecon-v /path/to/www esto le dará automáticamente todos los archivos en esta ruta de acceso correcta SELinux derechos. También cuando se agregan nuevos archivos. Uso httpd_sys_content_t si sólo necesita la lectura de derechos.
    • En Centos 7 (SELinux habilitado), la solución más sencilla para mí fue setsebool httpd_read_user_content on (Para los archivos estáticos alojado en un directorio de inicio chmod ed para legible por todo el mundo) – Aunque supongo que @KapiteinWitbaard del método anterior es más seguro.
    • Gracias, estaba buscando toda la noche para su solución, incluso chown a nginx y 777 a todos los archivos en el directorio, pero sin éxito! Eres genial!
    • Parece que no hay manera de que esto funciona en red hat enterprise linux 6.x (y probablemente centos 6). Hay algunos pasos adicionales en la configuración de selinux y tal vez incluso la modificación de las cosas acerca de Red Hat. Renunciar a cualquier intento de tratar de conseguir trabajo en red hat enterprise linux 6, he estado buscando por todas partes.
    • Sólo has salvado mi vida @Kurt
    • Eso es un salvavidas. Gracias, Hombre!
    • Me salvó la vida + 1!!! @Kurt
    • Kurt, has salvado mi pellejo. He pasado muchas horas tratando de arreglar un error 403, y esta fue la solución.
    • usted salvó mi día:)
    • Esta es la respuesta correcta.

  3. 51

    He resuelto este problema mediante la adición de la configuración de usuario.

    en nginx.conf

    worker_processes 4;
    user username;

    cambiar el nombre de usuario con nombre de usuario de linux.

    • Yo creo que esta respuesta es mejor en materia de seguridad de la aceptación de la respuesta. Usted no tiene que ir jugando con los permisos en la carpeta de inicio (que podría contener información confidencial) y si vas a hacer un desarrollo con nginx, que le ahorra de tener que cargar extraño permisos de archivo para SCM.
    • El agregado de los permisos en el directorio de inicio ejecutar, no se lee, por lo tanto no hay información sensible es (en teoría) revelado (con la excepción, en este caso, tal vez a un malicioso script PHP que recorre el árbol hacia arriba y conoce la ubicación de los archivos sensibles dentro de otro directorio accesible a www-data). También te darás cuenta de que en la pregunta original, mi nginx estaba corriendo como «www-data» – los valores de configuración aquí ya estaban configurar como se desee.
    • Tenía que agregar grupo de usuarios así: usuario usegroup.
    • Trabajó para mí también (como chmodding la dir a nginx:nginx). Yo prefiero esta solución, aunque para que yo pueda tener mi raíz del documento de propiedad de otro usuario de nginx. Gracias Anderson para señalar esto.
    • Gracias trabajó para mí.
    • me salvó el día. por cierto lo que si la máquina tiene varios usuarios y cada usuario tiene su propio sitio web, ¿cómo puedo lidiar con él?
    • Este debe ser marcado como aceptado respuesta. Gracias

  4. 29

    Tengo este error y finalmente se resolvió con el siguiente comando.

    restorecon -r /var/www/html

    El problema se produce cuando se mv algo de un lugar a otro. Conserva el contexto de selinux de la original cuando se mueve, así que si usted untar algo en /home o /tmp se obtiene dado un contexto de selinux que coincida con su ubicación. Ahora usted mv que el directorio /var/www/html y toma el contexto diciendo que pertenece en /tmp o /casa con él, y httpd no está permitido por la política de acceso a esos archivos.

    Si usted cp de los archivos en lugar de mv ellos, el contexto de selinux se asigna de acuerdo a la ubicación en la que está copiando, no se de dónde viene. Ejecutando el comando restorecon pone el contexto por defecto y lo arregla demasiado.

    • Gracias @jsina, esto me ayudó mucho
    • Maldita sea, +1, a mí también.
  5. 21

    He intentado varias veces, y sólo cuando el dueño estaba a nginx (chown -R nginx:nginx "/var/www/myfolder") – que comenzó a funcionar como se esperaba.

    • Trabajó para mí también. Sospecho que esto sucede porque a pesar de que nginx es ejecutado como root, genera procesos en el marco del usuario que se especifica en el nginx.conf archivo, que es «usuario nginx;» por defecto. Cambiar el usuario para el usuario que posee la raíz del documento debe también funcionar como Anderson sugirió.
    • El Señor Anderson? No! Andron 😉
    • Disculpas Señor Andron 😉 me parece que no puede editar el comentario anterior, ya aunque…
    • Claro, no es un problema. Ahora yo estaba como Anderson 🙂 y la necesidad de escribir algunos de los cuentos de hadas…
    • No es este un problema de seguridad ?
  6. 1

    Vieja pregunta, pero yo tenía el mismo problema. Traté de cada respuesta anterior, nada funcionó. Lo que fija para mí, aunque estaba quitando el dominio, y agregarlo de nuevo. Estoy usando Plesk, y he instalado Nginx DESPUÉS de que el dominio ya estaba allí.

    Hizo una copia de seguridad local en el directorio /var/www/copias de seguridad en primer lugar. Así que fácilmente podría copiar de nuevo los archivos.

    Problema extraño….

  7. 0

    Saqué yo en una ligera variante del problema de error de ejecución de la setfacl comando. Me encontré:

    sudo setfacl -m user:nginx:r /home/foo/bar

    He abandonado esta ruta en favor de la adición de nginx a la foo grupo, pero que las ACL fue frustrar nginx intentos de acceso al archivo. Me aclaró corriendo:

    sudo setfacl -b /home/foo/bar

    Y, a continuación, nginx fue capaz de acceder a los archivos.

  8. 0

    Hemos tenido el mismo problema, usando Plesk Onyx 17. En vez de jugar con los derechos etc., la solución fue añadir nginx usuario en psacln grupo, en el que todos los otros propietarios de dominio (usuarios) fueron:

    usermod -aG psacln nginx

    Ahora nginx tiene derechos de acceso .htaccess o cualquier otro archivo necesario para mostrar correctamente el contenido.

    Por otro lado, también asegúrese de que Apache está en psaserv grupo, para servir contenido estático:

    usermod -aG psaserv apache

    Y no te olvides de reiniciar Apache y Nginx en Plesk después! (y volver a cargar las páginas con Ctrl-F5)

  9. 0

    Si eres el uso de SELinux, sólo tienes que escribir:

    sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/

    Esto solucione problema de permisos.

  10. -1

    Me estaba enfrentando el mismo problema, pero por encima de las soluciones no ayudan.

    Así que, después de mucha lucha me enteré de que sestatus se establece en exigir que bloquea todos los puertos y mediante el establecimiento de permisivo todos los problemas se han resuelto.

    sudo setenforce 0

    Espero que esto ayude a alguien como yo.

    • Mientras que podría haber corregido su problema – felicidades! – eso es un poco triste 🙁 Ver stopdisablingselinux.com – podría encontrar una solución diferente?

Dejar respuesta

Please enter your comment!
Please enter your name here