Nginx: stat () falló (13: permiso denegado)

Estoy usando la configuración predeterminada mientras agrego el directorio específico con nginx instalado en mi máquina ubuntu 12.04.

server {
        #listen   80; ## listen for ipv4; this line is default and implied
        #listen   [::]:80 default ipv6only=on; ## listen for ipv6

        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to index.html
                root /username/test/static;
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }
...

...
}

Solo quiero un servidor nginx estático simple para servir archivos desde ese directorio. Sin embargo, comprobando el error.logveo

2014/09/10 16:55:16 [crit] 10808#0: *2 stat() "/username/test/static/index.html" failed (13: Permission denied), client:, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "domain"
2014/09/10 16:55:16 [error] 10808#0: *2 rewrite or internal redirection cycle while internally redirecting to "/index.html

Ya he hecho chown -R www-data:www-dataen /username/test/static, yo los he puesto a chmod 755. No sé qué más se necesita configurar.

Nginx opera dentro del directorio, por lo que si no puede acceder cda ese directorio desde el usuario de nginx, fallará (al igual que el statcomando en su registro). Asegúrate de que la www-userlata cdllegue hasta el /username/test/static. Puede confirmar que statfallará o tendrá éxito ejecutando

sudo -u www-data stat /username/test/static

En su caso, probablemente el /usernamedirectorio sea el problema aquí. Por www-datalo general , no tiene permisos para cdlos directorios de inicio de otros usuarios.

La mejor solución en ese caso sería agregar www-dataal usernamegrupo:

gpasswd -a www-data username

y asegúrese de que ese usernamegrupo pueda ingresar a todos los directorios a lo largo de la ruta:

chmod g+x /username && chmod g+x /username/test && chmod g+x /username/test/static

Para que sus cambios funcionen, reinicie nginx

nginx -s reload

Acabo de tener el mismo problema en una caja CentOS 7.

Parece que golpeé Selinux. Poner selinux en modo permisivo ( setenforce permissive) ha solucionado el problema por ahora. Intentaré volver con una solución adecuada.

Nginx debe tener acceso + x en todos los directorios que conducen al directorio raíz del sitio.

Asegúrese de tener + x en todos los directorios de la ruta que conduce a la raíz del sitio. Por ejemplo, si la raíz del sitio es / home / username / siteroot:

chmod +x /home/
chmod +x /home/username
chmod +x /home/username/siteroot

En CentOS 7.0 tuve este Access Deinedproblema causado por SELinux y estos pasos resolvieron el problema:

yum install -y policycoreutils-devel
grep nginx /var/log/audit/audit.log | audit2allow -M nginx
semodule -i nginx.pp

Actualización: solo una nota al margen de lo que aprendí mientras usaba los servidores Linux virtuales de digitalocean, o como los llaman Droplets . El uso de SELinux requiere una buena cantidad de RAM. Lo más probable es que no pueda ejecutar y administrar SELinux en una gota con menos de 2 GB de RAM.

Es posible que tenga Linux con seguridad mejorada en ejecución, así que agregue una regla para eso. Tenía 13 errores de permiso, a pesar de que se establecieron permisos y el usuario existía.

chcon -Rt httpd_sys_content_t /username/test/static

Síntoma:

No se pudieron cargar imágenes a la biblioteca multimedia de WordPress.

Porque:

(CentOS) yum update

Error:

2014/10/22 18:08:50 [crit] 23286#0: *5332 open() "/var/lib/nginx/tmp/client_body/0000000003" failed (13: Permission denied), client: 1.2.3.4, server: _, request: "POST /wp-admin/media-new.php HTTP/1.1", host: "example.com", referrer: "http://example/wp-admin/media-new.php"

Solución:

chown -R www-data:www-data /var/lib/nginx

Por defecto, los datos estáticos, cuando instale el nginx, estarán en / var / www / html. Entonces puede copiar su carpeta estática en / var / html / y configurar el

root /var/www/<your static folder>

en ngix.conf (o / etc / nginx / sites-available / default)

Esto funcionó para mí en ubuntu, pero supongo que no debería ser muy diferente para otras distribuciones.

Espero eso ayude.

Cambie su nginx.conf userpropiedad a www-staticpropietario de archivos.

#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user your_user_name;

# same other config

Enfrenté este problema, lo resolví para otorgar permisos al usuario y grupo de nginx algo como esto:

chown -R nginx:nginx /username/test/static

En mi caso, la carpeta que servía los archivos era un enlace simbólico a otra carpeta, hecho con

ln -sf /origin /var/www/destination

Aunque los permisos (usuario y grupo) eran correctos en la carpeta de destino (el enlace simbólico), todavía tenía el error porque Nginx también necesitaba tener permisos para la jerarquía completa de la carpeta de origen.

Finalmente encontré mi camino. En resumen, digamos que su nombre de usuario es joey tiene un sitio web en su sistema de archivos personal /home/joe/path/to/website.

Literalmente tienes que decirle al sistema que nginxes tu amigo.
Colocar nginxen joegrupo:

sudo gpasswd -a nginx joe

Después de eso, si aún no funciona, verifique el acceso correcto al /home/joedirectorio. Esa es probablemente la razón por la que nginx no puede acceder al archivo porque incluso si ahora es tu amigo, tienes que abrirle la puerta de tu casa:

sudo chmod g+x /home/joe

Eso es. Eso es, literalmente, todo lo que tiene que hacer para que nginx acceda a sus archivos locales :)

No creo que haya problemas de seguridad con este método porque nginxes la máxima autoridad y solo un administrador puede cambiar el grupo. nginxahora puede leer lo que hay en los joedirectorios. Es solo una brecha de seguridad si el titular de la nginxcuenta es diferente con el usuario desde el que abre el acceso al directorio, pero en mi caso soy el titular de ambas partes, es decir, en un contexto local.

Tuve el mismo problema, estoy usando Plesk Onyx 17 con Centos7. Pude ver este error en proxy_error_log en los registros del dominio afectado. Todos los directorios / archivos en / var / www / vhosts / son propiedad de sus respectivos usuarios (propietarios de dominio) y puede ver que todos ellos están en el grupo psacln. Entonces, la solución fue agregar nginx también a este grupo, para que pueda ver lo que necesita:

usermod -aG psacln nginx

Y, de hecho, reinicie nginx y vuelva a cargar la página con Ctrl + F5.

Encontré una solución alternativa: moví la carpeta a la carpeta de configuración de nginx, en mi caso "/ etc / nginx / my-web-app". Y luego cambió los permisos al usuario root "sudo chown -R root: root" my-web-app ".

También puede agregar qué usuario ejecutará nginx. En el archivo nginx.conf, realice los siguientes cambios:

user root;

Puede agregar la línea anterior como la primera línea en su nginx conf. Puede escribir el nombre de cualquier usuario que tenga permiso para escribir en ese directorio.

Este suele ser el problema de los privilegios ... Para mí, es porque uso / root / ** como raíz de nginx, necesita un mayor privilegio. Una forma sencilla es mover el proyecto a un directorio creado por usted mismo.