Nginx 403はすべてのファイルで禁止されています

CentOS 5のボックスにnginxをPHP-FPMとともにインストールしましたが、PHPかどうかに関係なく、私のファイルにサービスを提供するのに苦労しています。

Nginxはwww-data：www-dataとして実行されており、デフォルトの「EPELでnginxへようこそ」サイト（root：rootが所有し、644の権限を持つ）は正常に読み込まれます。

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

public_htmlが2777ファイル権限を持つwww-data：www-dataに所有されているにもかかわらず、このサイトはコンテンツを提供できません-

 [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を取得しているユーザーがいる他の多くの投稿を見つけましたが、Ruby / Passengerを使用したより複雑な設定（以前は実際に成功しました）が関係しているか、上流のPHPの場合にのみエラーが発生しています-FPMが関係しているため、ほとんど役に立たないようです。

ここでばかげたことをしましたか？

見過ごされがちな権限要件の1つは、ユーザーがファイルにアクセスするには、ファイルのすべての親ディレクトリにx権限が必要であることです。/、/ home、/ home / demoなどのアクセス権でwww-data xアクセスを確認します。私の推測では、/ homeはおそらく770であり、www-dataはそれをchdirしてサブディレクトリに到達することはできません。そうである場合は、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;

Linuxのユーザー名で「ユーザー名」を変更します。

このエラーが発生したので、最終的に次のコマンドで解決しました。

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を使用して同じ問題が発生しました。権限などをいじる代わりに、解決策は、他のすべてのドメイン所有者（ユーザー）がいるpsaclnグループにnginxユーザーを追加することでした。

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がすべてのポートをブロックするように強制するように設定され、それを寛容に設定することによってすべての問題が解決されることがわかりました。

sudo setenforce 0

これが私のような人に役立つことを願っています。