모든 파일에 대해 Nginx 403 금지

CentOS 5 상자에 PHP-FPM과 함께 nginx를 설치했지만 PHP 여부에 관계없이 파일을 제공하기 위해 고심하고 있습니다.

Nginx가 www-data : www-data로 실행 중이며 기본 "EPEL의 nginx에 오신 것을 환영합니다"사이트 (644 권한이있는 root : root 소유)가 정상적으로로드됩니다.

nginx 구성 파일에는 /etc/nginx/sites-enabled/*.conf에 대한 include 지시문 이 있으며 구성 파일 example.com.conf 가 있습니다.

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;
 }
}

2777 개의 파일 권한이있는 www-data : www-data가 public_html을 소유하고 있지만이 사이트는 어떤 콘텐츠도 제공하지 않습니다.

 [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"

사용자가 nginx에서 403을 얻는 다른 게시물을 많이 발견했지만 루비 / Passenger (이전에는 실제로 성공했습니다)를 사용하여 더 복잡한 설정이 포함되거나 업스트림 PHP가 발생했을 때만 오류가 발생하는 것을 보았습니다 -FPM이 관여하므로 도움이 거의없는 것 같습니다.

내가 여기서 어리석은 짓을 했습니까?

종종 간과되는 권한 요구 사항 중 하나는 사용자가 파일의 모든 상위 디렉토리에 해당 파일에 액세스하기위한 x 권한이 필요하다는 것입니다. www-data x 액세스에 대한 /, / home, / home / demo 등에 대한 권한을 확인하십시오. 내 생각에 / home은 아마도 770이고 www-data는 그것을 통해 어떤 하위 디렉토리에 도달 할 수 없습니다. 그렇다면 chmod o + x / home (또는 요청을 거부하는 디렉토리)을 시도하십시오.

편집 : 경로에 대한 모든 권한을 쉽게 표시하려면 namei -om /path/to/check

permission denied상위 폴더의 권한을 확인한 후에도 여전히 표시되면 SELinux가 액세스를 제한 하는 것일 수 있습니다 .

SELinux가 실행 중인지 확인하려면 다음을 수행하십시오.

# getenforce

다음에 재부팅 할 때까지 SELinux를 비활성화하려면 :

# setenforce Permissive

Nginx를 다시 시작하고 문제가 지속되는지 확인하십시오. nginx가 www 디렉토리를 제공 할 수있게하려면 (이를 테스트하기 전에 SELinux를 다시 켜십시오 (예 :) setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

자세한 내용은 여기 내 답변 을 참조하십시오

사용자 설정을 추가하여이 문제를 해결했습니다.

nginx.conf에서

worker_processes 4;
user username;

리눅스 사용자 이름으로 '사용자 이름'을 변경하십시오.

이 오류가 발생하여 마침내 아래 명령으로 해결했습니다.

restorecon -r /var/www/html

한 장소에서 다른 장소로 무언가를 측정 할 때 문제가 발생합니다. 이동시 원본의 selinux 컨텍스트를 유지하므로 / home 또는 / tmp에서 무언가를 untar하면 해당 위치와 일치하는 selinux 컨텍스트가 제공됩니다. 이제 / var / www / html로 mv를 지정하고 / tmp 또는 / home에 속하는 컨텍스트를 취하고 정책에 의해 httpd가 해당 파일에 액세스 할 수 없습니다.

mv 대신 파일을 cp로 만들면 selinux 컨텍스트는 원래 위치가 아니라 복사하는 위치에 따라 지정됩니다. restorecon을 실행하면 컨텍스트가 기본값으로 돌아가고 수정됩니다.

나는 다른 경우를 시도했으며 소유자가 nginx ( chown -R nginx:nginx "/var/www/myfolder") 로 설정되었을 때만 예상대로 작동하기 시작했습니다.

SELinux를 사용하는 경우 다음을 입력하십시오.

sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/

권한 문제가 해결됩니다.

오래된 질문이지만 같은 문제가있었습니다. 나는 위의 모든 대답을 시도했지만 아무것도 효과가 없었습니다. 도메인을 제거하고 다시 추가했지만 문제가 해결되었습니다. Plesk를 사용하고 있으며 도메인이 이미 존재 한 후에 Nginx를 설치했습니다.

그래도 먼저 / var / www / backups에 로컬 백업을 수행했습니다. 파일을 쉽게 다시 복사 할 수있었습니다.

이상한 문제 ....

우리는 Plesk Onyx 17을 사용하여 같은 문제를 겪었습니다. 권리 등을 엉망으로 만드는 대신 해결책은 nginx 사용자를 psacln 그룹에 추가하는 것이 었습니다. 다른 모든 도메인 소유자 (사용자)는 다음과 같습니다.

usermod -aG psacln nginx

이제 nginx는 .htaccess 또는 컨텐츠를 올바르게 표시하는 데 필요한 다른 파일에 액세스 할 수있는 권한이 있습니다.

한편, 정적 컨텐츠를 제공하기 위해 Apache가 psaserv 그룹에 있는지 확인하십시오.

usermod -aG psaserv apache

그리고 Plesk에서 Apache와 Nginx를 모두 다시 시작하는 것을 잊지 마십시오! (Ctrl-F5로 페이지를 다시로드하십시오)

실수로 setfacl명령을 실행 하여이 문제에 대한 약간의 변형을 발견했습니다 . 나는 달렸다 :

sudo setfacl -m user:nginx:r /home/foo/bar

그룹 에 추가 nginx하기 위해이 경로를 포기 foo했지만 해당 사용자 정의 ACL은 파일에 액세스하려는 nginx의 시도를 망쳤습니다. 나는 그것을 실행하여 그것을 정리했다 :

sudo setfacl -b /home/foo/bar

그리고 nginx는 파일에 접근 할 수있었습니다.

PHP를 사용하는 경우 index서버 블록 의 NGINX 지시문에 index.php가 포함되어 있는지 확인하십시오 .

index index.php index.html;

자세한 정보 는 공식 문서 의 색인 지시문 을 확인하십시오.

나는 같은 문제에 직면했지만 위의 해결책은 도움이되지 않았습니다.

따라서 많은 어려움을 겪은 후 sestatus 가 모든 포트를 차단하고 모든 문제를 허용하도록 설정하여 sestatus 가 해결되었다는 것을 알았습니다 .

sudo setenforce 0

이것이 나와 같은 누군가를 돕기를 바랍니다.