Nginx 403 prohibido para todos los archivos
Tengo nginx instalado con PHP-FPM en una caja 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 de nginx tiene una directiva include para /etc/nginx/sites-enabled/*.conf, y tengo un archivo de configuración ejemplo.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 public_html siendo 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 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 desarrollador principal PHP-FPM está involucrado, por lo que parecen ser de poca ayuda.
He hecho algo tonto aquí?
9 answers
Un requisito de permiso que a menudo se pasa por alto es que un usuario necesita permisos x en cada directorio padre de un archivo para acceder a ese archivo. Comprobar los permisos en /, /home, /home/demo, etc. para acceso www-data x. Mi conjetura es que / home es probablemente 770 y www-data no puede chdir a través de él para llegar a cualquier subdir. Si lo es, pruebe chmod o + x / home (o lo que sea que dir esté denegando la solicitud).
EDITAR: Para mostrar fácilmente todos los permisos en una ruta, puede usar namei -om /path/to/check
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-12-06 12:35:04
Si todavía ve permission denied después de verificar los permisos de las carpetas padre, puede ser SELinux restringiendo el acceso.
Para comprobar si SELinux se está ejecutando:
# getenforce
Para desactivar SELinux hasta el siguiente 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. i. e, setenforce Enforcing)
# chcon -Rt httpd_sys_content_t /path/to/www
Ver mi respuesta aquí para más detalles
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:18:14
Resolví este problema agregando la configuración del usuario.
En nginx.conf
worker_processes 4;
user username
Cambie el 'nombre de usuario' por el nombre de usuario de linux.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-12-16 07:11:53
Tengo este error y finalmente lo resolví con el comando a continuación.
restorecon -r /var/www/html
El problema es causado cuando mv algo de un lugar a otro. Preserva el contexto selinux del original cuando lo mueves, así que si eliminas algo en / home o / tmp se le da un contexto selinux que coincide con su ubicación. Ahora mv que 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 usted cp los archivos en lugar de mv ellos, el contexto selinux se asigna de acuerdo a la ubicación que está copiando a, no de donde viene. Ejecutar restorecon devuelve el contexto a su valor predeterminado y también lo corrige.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-04-03 17:56:11
He intentado diferentes casos y solo cuando el propietario se estableció en nginx (chown -R nginx:nginx "/var/www/myfolder") - comenzó a funcionar como se esperaba.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-20 16:50:04
Vieja pregunta, pero yo tenía el mismo problema. Probé todas las respuestas anteriores, nada funcionó. Lo que lo arregló para mí fue eliminar el dominio y agregarlo de nuevo. Estoy usando Plesk, e instalé Nginx DESPUÉS de que el dominio ya estaba allí.
Hizo una copia de seguridad local en /var/www/backups primero. Así que podría copiar fácilmente los archivos.
Extraño problema....
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-04-30 02:13:54
Me adentré 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 en favor de agregar nginx al grupo foo, pero esa ACL personalizada estaba frustrando los intentos de nginx de acceder al archivo. Lo limpié corriendo:
sudo setfacl -b /home/foo/bar
Y luego nginx fue capaz de acceder a los archivos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-11-05 17:24:42
Tuvimos el mismo problema, usando Plesk Onyx 17. En lugar de meter la pata con los derechos, etc., la solución fue agregar el usuario nginx al grupo psacln, en el que todos los demás propietarios de dominios (usuarios) eran:
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 el grupo psaserv, para servir contenido estático:
usermod -aG psaserv apache
Y no se olvide de reiniciar Apache y Nginx en Plesk después! (y recargar páginas con Ctrl-F5)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-03-22 23:29:53
Si está utilizando PHP, asegúrese de que la directiva index NGINX en el bloque del servidor contiene un índice.php:
index index.php index.html;
Para obtener más información, consulte la directiva index en la documentación oficial.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-06-11 20:39:59