nginx - successful - no tienes autorización para ver esta página. http error 403 chrome

¿Por qué Nginx devuelve un 403 a pesar de que todos los permisos están configurados correctamente?

Question

Tengo configuración Nginx y mostrar la página de prueba correctamente. Si trato de cambiar la ruta de la raíz, recibo un error 403 Prohibido, aunque todos los permisos son idénticos. Además, el usuario nginx existe.

nginx.conf:

user nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log;

pid        /run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    index   index.html index.htm;

    server {
        listen       80;
        server_name  localhost;
        root         /var/www/html; #changed from the default /usr/share/nginx/html
    }
}

namei -om /usr/share/nginx/html/index.html

f: /usr/share/nginx/html/index.html
dr-xr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root share
drwxr-xr-x root root nginx
drwxr-xr-x root root html
-rw-r--r-- root root index.html

namei -om /var/www/html/index.html

f: /var/www/html/index.html
dr-xr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-xr-x root root html
-rw-r--r-- root root index.html

registro de errores

2014/03/23 12:45:08 [error] 5490 # 0: * 13 open () "/var/www/html/index.html" failed (13: Permiso denegado), cliente: XXX.XX.XXX. XXX, servidor: localhost, solicitud: "GET /index.html HTTP / 1.1", host: "ec2-XXX-XX-XXX-XXX.compute-1.amazonaws.com"

Answer 1

¡Modifique el archivo nginx.conf, cambie el nombre de usuario a su nombre de cuenta y reinicie nginx.it!

Answer 2

En primer lugar, debe ejecutar el siguiente comando para permitir que nginx acceda al sistema de archivos

sudo setsebool -P httpd_read_user_content 1

Puede verificar si los archivos o el directorio con el siguiente comando:

ls -Z

Si aún no es accesible, puede intentar cambiar la propiedad SELinux de los archivos y la carpeta con el siguiente comando:

chcon -Rt httpd_sys_content_t /path/to/www

Sin embargo, el comando anterior no se puede aplicar a archivos bajo el sistema FUSE o NFS.

Para habilitar el servicio de archivos desde soportes FUSE, puede usar:

setsebool httpd_use_fusefs 1

Para habilitar el servicio de archivos desde montajes NFS, puede usar:

setsebool httpd_use_nfs 1

Answer 3

Estaba usando:

sudo service nginx start

Si uso:

sudo nginx 

... todo funciona bien ¿Alguien puede explicar la diferencia entre estos dos?

Answer 4

Esto es una adición a la respuesta de Prowlas, pero no tengo suficiente reputación para comentar: si / path / to / www es un directorio de inicio de un usuario. Deberías intentarlo:

setsebool -P httpd_enable_homedirs=1

Esto resolvió mi problema

Fuente: http://forums.fedoraforum.org/archive/index.php/t-250779.html

Answer 5

Experimenté el mismo problema y fue debido a SELinux .

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. Si desea alterar permanentemente la configuración, puede editar /etc/sysconfig/selinux

Si su problema es SELinux, puede ejecutar lo siguiente 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

Si todavía tiene problemas, eche un vistazo a los indicadores booleanos en getsebool -a , en particular, es posible que deba activar httpd_can_network_connect para obtener acceso a la red

# setsebool -P httpd_can_network_connect on

Para mí, fue suficiente para permitir que http sirviera a mi directorio www.

Answer 6

Hay dos posibles razones para denegar el acceso:

1. El acceso es denegado por DAC . Verifique los permisos de usuario, grupo y archivo. Asegúrese de que el proceso nginx, cuando se ejecuta como el usuario especificado en su archivo de configuración, pueda acceder a la nueva ruta raíz de html.

2. El acceso es denegado por MAC . El más utilizado de estos es SELinux. Para verificar si causó el problema, puede detener el proceso nginx y ejecutar este comando:

   setenforce Permissive

   A continuación, inicie nginx nuevamente para ver si se concede el acceso.

   Alternativamente, puede verificar el contexto del archivo:

   setenforce Enforcing
   ls -Zd /usr/share/nginx/html /var/www/html

   Si los dos contextos son diferentes, puede que necesite cambiar el contexto de la nueva ruta de acceso html:

   chcon -R -t httpd_sys_content_t /var/www/html

   Reinicie nginx y vea si funciona bien. Si es así, puede hacer que el cambio sea permanente:

   semanage fcontext -a -t httpd_sys_content_t ''/var/www/html(/.*)?''
   restorecon -Rv /var/www/html

   Algunos de estos comandos deben ejecutarse como root.

Answer 7

He encontrado este problema cuando agregué un nuevo usuario con una carpeta /home/new_user como un nuevo host virtual. Asegúrese de que estas carpetas ( /home , /home/new_user , /home/new_user/xxx ...) sean 755 para que resuelva mi problema. Por fin, encontré que mi problema estaba correctamente de acuerdo con el archivo /var/log/nginx/error.log .

Answer 8

Recuerde que debe permitir que otros usuarios lean toda la ruta. Recuerde también que Dropbox establecerá 700 en su directorio raíz. Entonces chmod 755 ~/Dropbox resolvió mi problema.

Answer 9

Tuve el mismo problema. Si está usando Fedora / RedHat / CentOS, esto podría ayudarlo a:

• De acuerdo con SELinux: setsebool -P httpd_read_user_content 1

Espero que esto ayude.

Answer 10

Tuve el mismo problema:

• Comprobado nginx.conf para verificar el usuario
• Los permisos se establecieron correctamente
• Se aseguró de que "x" a la derecha estuviera configurada para toda la ruta

Hice un reinicio desde la línea de comando (he estado usando Webmin todo este tiempo) y noté este error:

 aed@aed:/var/www/test.local$ sudo service nginx restart
 * Restarting nginx nginx 
nginx: [warn] conflicting server name "test.local" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "test.local" on 0.0.0.0:80, ignored

Aparentemente había una definición duplicada y, por lo tanto, mi intento de acceder a "test.local" falló.

Answer 11

esto resolvió el mismo problema:

reinicie Nginx y vuelva a intentarlo. Si falla, verifique nuevamente los registros. Esto funcionó para mí

Answer 12

parece lógico, todos los archivos son usuarios root, intente cambiarlo a usuario nginx, solo quería asegurarse de que no se deniega primero el permiso de publicación.

sudo chown -R nginx:nginx /var/www/html