tienes - nginx static files 403

Nginx 403 prohibido para todos los archivos

Question

Tengo nginx instalado con PHP-FPM en un cuadro de CentOS 5, pero estoy luchando para que sirva 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 de inclusión 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 archivo, 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 403 desde nginx, pero la mayoría de las que he visto involucran configuraciones más complejas con Ruby / Passenger (que en el pasado lo he logrado) o solo están recibiendo errores cuando el PHP upstream -FPM está involucrado, por lo que parecen ser de poca ayuda.

¿He hecho algo tonto aquí?

Answer 1

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

Answer 2

Me metí en una ligera variante de este problema al ejecutar erróneamente el comando setfacl . Corrí:

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

Abandoné esta ruta a favor de agregar nginx al grupo foo , pero esa ACL personalizada frustraba los intentos de nginx de acceder al archivo. Lo borré ejecutando:

sudo setfacl -b /home/foo/bar

Y luego nginx pudo acceder a los archivos.

Answer 3

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.

Answer 4

Si aún ve el permission denied después de verificar los permisos de las carpetas principales, es posible que SELinux restrinja 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 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

Ver mi respuesta aquí para más detalles

Answer 5

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

restorecon -r /var/www/html

El problema se produce cuando mezclas algo de un lugar a otro. Conserva el contexto selinux del original cuando lo mueves, así que si desatascas algo en / home o / tmp se le da un contexto selinux que coincide con su ubicación. Ahora mv eso a / var / www / html y toma el contexto diciendo que pertenece en / tmp o / home con él y httpd no está permitido por la política para acceder a esos archivos.

Si copia los archivos en lugar de mv ellos, el contexto de selinux se asigna de acuerdo con la ubicación en la que está copiando, no de dónde proviene. Al ejecutar restaurarcon, el contexto vuelve a su configuración predeterminada y también lo corrige.

Answer 6

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

usermod -aG psacln nginx

Ahora nginx tiene los 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 recarga páginas con Ctrl-F5)

Answer 7

Un requisito de permiso que a menudo se pasa por alto es que el usuario necesita x permisos en cada directorio principal de un archivo para acceder a ese archivo. Compruebe los permisos en /, / home, / home / demo, etc. para acceder a www-data x. Mi suposición es que / home es probablemente 770 y www-data no puede atravesarlo para llegar a ningún subdirectorio. Si lo es, 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

Answer 8

Una vieja pregunta, pero tuve el mismo problema. Intenté cada respuesta anterior, nada funcionó. Sin embargo, lo que me arregló fue eliminar el dominio y volverlo a agregar. Estoy usando Plesk e instalé Nginx DESPUÉS de que el dominio ya estaba allí.

Hizo primero una copia de seguridad local a / var / www / backups. Así que podría copiar fácilmente los archivos.

Extraño problema ...