Nginx 403 prohibido para todos los archivos

Tengo instalado nginx con PHP-FPM en una caja de CentOS 5, pero estoy luchando para que sirva a cualquiera de mis archivos, ya sea PHP o no.

Nginx se ejecuta como www-data: www-data, y el sitio predeterminado "Bienvenido a nginx en EPEL" (propiedad de root: root con 644 permisos) se carga bien.

El archivo de configuración nginx tiene una directiva include para /etc/nginx/sites-enabled/*.conf, y tengo un archivo de configuración example.com.conf , por lo tanto:

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 que public_html es propiedad de www-data: www-data con 2777 permisos de archivos, este sitio no sirve ningún 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 muchas otras publicaciones con usuarios que obtienen 403s de nginx, pero la mayoría de las que he visto involucran configuraciones más complejas con Ruby / Passenger (que en el pasado he tenido éxito) o solo están recibiendo errores cuando el PHP ascendente -FPM está involucrado, por lo que parecen ser de poca ayuda.

¿He hecho algo tonto aquí?

Un requisito de permiso que a menudo se pasa por alto es que un usuario necesita x permisos en cada directorio padre de un archivo para acceder a ese archivo. Verifique los permisos en /, / home, / home / demo, etc. para acceder a www-data x. Supongo que / home es probablemente 770 y www-data no puede atravesarlo para acceder a cualquier subdirectorio. Si es así, intente chmod o + x / home (o cualquier directorio que niegue la solicitud).

EDITAR: para mostrar fácilmente todos los permisos en una ruta, puede usar namei -om /path/to/check

Si aún ve permission denieddespués de verificar los permisos de las carpetas principales, puede ser SELinux restringir el acceso.

Para verificar si SELinux se está ejecutando:

# getenforce

Para deshabilitar SELinux hasta el próximo reinicio:

# setenforce Permissive

Reinicie Nginx y vea si el problema persiste. Para permitir que nginx sirva a su directorio www (asegúrese de volver a activar SELinux antes de probar esto, es decir, setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

Vea mi respuesta aquí para más detalles.

Resolví este problema agregando configuraciones de usuario.

en nginx.conf

worker_processes 4;
user username;

cambie el 'nombre de usuario' con el nombre de usuario de Linux

Tengo este error y finalmente lo resolví con el siguiente comando.

restorecon -r /var/www/html

El problema se produce cuando mueves algo de un lugar a otro. Conserva el contexto de selinux del original cuando lo mueve, por lo que si descomprime algo en / home o / tmp, se le dará un contexto de selinux que coincide con su ubicación. Ahora envía esto a / var / www / html y toma el contexto que dice que pertenece a / tmp o / home con él y que la política no permite que httpd acceda a esos archivos.

Si copia los archivos en lugar de mv, el contexto de selinux se asigna de acuerdo con la ubicación a la que está copiando, no de dónde proviene. La ejecución de restorecon restablece el contexto a su valor predeterminado y también lo corrige.

He probado diferentes casos y solo cuando el propietario se configuró en nginx ( chown -R nginx:nginx "/var/www/myfolder"), comenzó a funcionar como se esperaba.

Si está utilizando SELinux, simplemente escriba:

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

Esto solucionará el problema de permiso.

Antigua pregunta, pero tuve el mismo problema. Intenté todas las respuestas anteriores, nada funcionó. Sin embargo, lo que me solucionó fue eliminar el dominio y agregarlo nuevamente. Estoy usando Plesk e instalé Nginx DESPUÉS de que el dominio ya estaba allí.

Sin embargo, primero hice una copia de seguridad local en / var / www / backups. Entonces podría copiar fácilmente los archivos.

Extraño problema ...

Tuvimos el mismo problema al usar Plesk Onyx 17. En lugar de perder el tiempo con los derechos, etc., la solución fue agregar un usuario nginx al grupo psacln, en el que todos los demás propietarios del dominio (usuarios) eran:

usermod -aG psacln nginx

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

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

usermod -aG psaserv apache

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

Me metí en una ligera variante de este problema al ejecutar el setfaclcomando por error . Corrí:

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

Abandoné esta ruta a favor de agregar nginxal foogrupo, pero esa ACL personalizada estaba frustrando los intentos de nginx de acceder al archivo. Lo borré ejecutando:

sudo setfacl -b /home/foo/bar

Y entonces nginx pudo acceder a los archivos.

Si está utilizando PHP, asegúrese de que la indexdirectiva NGINX en el bloque del servidor contenga un index.php:

index index.php index.html;

Para obtener más información, consulte la directiva de índice en la documentación oficial.

Estaba enfrentando el mismo problema, pero las soluciones anteriores no ayudaron.

Entonces, después de mucha lucha, descubrí que sestatus estaba configurado para hacer cumplir lo que bloquea todos los puertos y al establecerlo en permisivo se resolvieron todos los problemas.

sudo setenforce 0

Espero que esto ayude a alguien como yo.