私はCentOS 5のボックスにnginxをPHP-FPMと共にインストールしましたが、PHPかどうかに関わらず、私のファイルのいずれかを処理するのに苦労しています。
Nginxはwww-data:www-dataとして実行されており、デフォルトの "EPELのnginxへようこそ"サイト(root:644の権限を持つrootが所有)は正常にロードされます。
Nginx設定ファイルにはincludeディレクティブがあります。 /etc/nginx/sites-enabled/*.conf、 そして私は設定ファイル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を取得しているユーザーに関する投稿が他にもたくさんありますが、私が見たことのほとんどはRuby/Passengerを使ったより複雑な設定(過去に実際に成功した)に関するものです。 -FPMが関与しているので、それらはほとんど役に立ちません。
私はここでばかげたことをしたことがありますか?
見過ごされがちなアクセス許可の要件の1つは、ユーザーがそのファイルにアクセスするためにはファイルのすべての親ディレクトリでx個のアクセス許可が必要なことです。 www-data xアクセスの/、/ home、/ home/demoなどのアクセス権を確認してください。私の推測では、/ homeはおそらく770であり、www-dataはそれを介してサブディレクトリにアクセスすることはできません。もしそうなら、chmod o + x/homeを試してください(あるいはdirが要求を拒否しているものなら何でも)。
編集:パス上のすべての権限を簡単に表示するには、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のユーザー名で 'username'を変更してください。
私はこのエラーを持っていました、そして私はついに以下のコマンドでそれを解決しました。
restorecon -r /var/www/html
問題は、ある場所から別の場所に何かを移動したときに発生します。移動してもオリジナルのselinuxコンテキストが保持されるため、/ homeまたは/ tmp内の何かを展開すると、その場所に一致するselinuxコンテキストが与えられます。今、あなたはそれを/ var/www/htmlにmvし、それはそれと共に/ tmpまたは/ homeに属しているという文脈を取り、httpdはそれらのファイルにアクセスすることをポリシーによって許可されていません。
Mvの代わりにファイルをcpした場合、selinuxコンテキストはコピー元の場所ではなく、コピー先の場所に従って割り当てられます。 restoreconを実行すると、コンテキストがデフォルトに戻り、それも修正されます。
私は別のケースを試してみましたそして所有者がnginx(chown -R nginx:nginx "/var/www/myfolder"
)に設定されたときだけ - それは予想通りに動き始めました。
昔の質問ですが、私は同じ問題を抱えていました。私は上記のすべての答えを試しました、何もうまくいきませんでした。私にとってそれを修正したのは、ドメインを削除し、それを再び追加することでした。私はPleskを使用しています、そしてドメインが既にそこにあった後に私はNginxをインストールしました。
ローカルバックアップを最初に/ var/www/backupsに行いました。だから私は簡単にファイルをコピーバックすることができます。
奇妙な問題.
私は誤ってsetfacl
コマンドを実行することによって、この問題のわずかな変形に自分自身を掘りました。私は走った:
Sudo setfacl -m user:nginx:r /home/foo/bar
私はnginx
をfoo
グループに追加することを支持してこのルートを放棄しましたが、そのカスタムACLはnginxがファイルにアクセスしようとする試みを妨げました。私は実行してそれをクリアしました:
Sudo setfacl -b /home/foo/bar
そしてnginxはファイルにアクセスすることができました。
Plesk Onyx 17を使用して同じ問題を抱えていました。権限などを台無しにする代わりに、nginxユーザーをpsaclnグループに追加することで解決しました。他のすべてのドメイン所有者(ユーザー)は以下のとおりです。
usermod -aG psacln nginx
これでnginxは.htaccessやその他のファイルにアクセスして内容を正しく表示する権限を持ちます。
一方、静的コンテンツを提供するために、Apacheがpsaservグループに属していることも確認してください。
usermod -aG psaserv Apache
そして、その後PleskでApacheとNginxの両方を再起動することを忘れないでください。 (そしてCtrl-F5でページをリロードする)
SELinuxを使用している場合は、次のように入力してください。
Sudo chcon -v -R --type=httpd_sys_content_t /path/to/www/
これは許可の問題を修正します。
PHPを使用している場合は、サーバーブロックのindex
NGINXディレクティブにindex.phpが含まれていることを確認してください。
index index.php index.html;
詳細については、公式ドキュメントの indexディレクティブ をご覧ください。