Odmowa dostępu podczas czytania w górę

Wdrożyliśmy naszą aplikację Railsową na Nginxie i pasażerze. Czasami strony aplikacji są ładowane częściowo. W dzienniku aplikacji nie ma błędów.

2011/02/14 05:49:34 [crit] 25389#0: *645 open() "/opt/nginx/proxy_temp/2/02/0000000022" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: y.y.y.y, request: "GET /signup/procedures?count=0 HTTP/1.1", upstream: "passenger:unix:/passenger_helper_server:", host: "y.y.y.y", referrer: "http://y.y.y.y/signup/procedures"

Miałem ten sam problem z instalacją NGINX / PHP-FPM (php-fpm = ulepszone fcgi dla php).

Możesz dowiedzieć się, który użytkownik uruchamia procesy nginx

ps aux | grep "nginx: worker process"

A następnie sprawdź, czy uprawnienia w plikach proxy są prawidłowe

ls -l /opt/nginx/proxy_temp/

W moim przypadku nginx działał jako, www-dataa dwa katalogi w moim katalogu proxy należały do ​​katalogu głównego.

Nie wiem jeszcze, jak to się stało, ale naprawiłem to, wykonując (jako root)

chown www-data.www-data /opt/nginx/proxy_temp

Prawdopodobnie zacząłeś od użytkownika root, a następnie go zmieniłeś. Problem polega na tym, że foldery pamięci podręcznej, tj

/var/cache/nginx/client_temp
/var/cache/nginx/fastcgi_temp
/var/cache/nginx/proxy_temp
/var/cache/nginx/scgi_temp
/var/cache/nginx/uwsgi_temp

są już własnością użytkownika root, więc użytkownik nginx (lub cokolwiek, na co próbujesz się przełączyć) nie może uzyskać do nich dostępu, ponieważ ma pozwolenie 700.

Więc rozwiązanie jest łatwe. Zatrzymaj nginx, a następnie:

rm -rf /var/cache/nginx/*

lub jakąkolwiek ścieżką jest twoja dystrybucja i wydanie. Następnie uruchom ponownie nginx, który ponownie utworzy te foldery z odpowiednimi uprawnieniami.

Sprawdź także plik nginx.conf, aby upewnić się, że określasz poprawnego użytkownika ORAZ grupę.

Miałem problem z tym, że uprawnienia do katalogu były skonfigurowane dla nazwy użytkownika / nginx, ale użytkownik nginx.conf podał tylko nazwę użytkownika. Domyślnie, jeśli żadna grupa nie jest podana w dyrektywie użytkownika, używa tej samej nazwy co użytkownik. Więc nazwa użytkownika / nazwa użytkownika próbowała uzyskać dostęp do katalogu zamiast nazwy użytkownika / nginx. Aktualizacja konfiguracji rozwiązała moje problemy.

Zobacz: http://nginx.org/en/docs/ngx_core_module.html#user

Zrobiłem więc wszystkie powyższe i niestety dla mnie to dawało ten sam błąd. Korzystam z aplikacji railsowej spakowanej do pliku jar z torquebox na maszynie centos 6.7 z nginx. Walczyłem z tym przez około 3 godziny, aż znalazłem inne rozwiązanie i mam nadzieję, że to pomoże komuś innemu. Zgodnie z tym artykułem nginx może działać w trybie wymuszania. Właśnie zmieniłem nginx na tryb zezwalający

setenforce 0

Dzięki temu błąd zniknął i mogłem uruchomić moją aplikację w środowisku testowym / produkcyjnym.

Nie miałem pojęcia, dopóki nie znalazłem błędu w pliku audit.log

type=AVC msg=audit(1444454198.438:466): avc:  denied  { name_connect } for  pid=3201 comm="nginx" dest=8080 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket

Naprawdę mam nadzieję, że to kogoś uratuje 3 godziny, które właśnie straciłem.

Podczas uruchamiania nginx z nieuprzywilejowanego konta use_temp_path=off.

proxy_cache_path ... use_temp_path=off;

Musiało to zapobiec próbom umieszczenia plików przez Nginx w ustawieniach domyślnych proxy_temp_path. Z dokumentów nginx:

Katalog plików tymczasowych jest ustawiany na podstawie parametru use_temp_path (1.7.10). Jeśli ten parametr zostanie pominięty lub ustawiony na wartość on, zostanie użyty katalog ustawiony przez dyrektywę proxy_temp_path dla danej lokalizacji. Jeśli wartość jest wyłączona, pliki tymczasowe zostaną umieszczone bezpośrednio w katalogu pamięci podręcznej.

chmod 777 /opt/nginx/proxy_temp/

Miałem ten sam problem i rozwiązany przez chmod do tego katalogu.