ver tienes successful solucionar solucion página prohibido para not miarroba home google gdrive forbidden flvto files esta español error denegado corregir como code chrome check celular autorización acceso nginx installation http-status-code-403

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? (12)

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"


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


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


Estaba usando:

sudo service nginx start

Si uso:

sudo nginx

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


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


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.


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.


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 .


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.


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.


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ó.


esto resolvió el mismo problema:

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


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