सभी फाइलों के लिए Nginx 403 निषिद्ध है


192

मेरे पास nagx PHP-FPM के साथ एक CentOS 5 बॉक्स पर स्थापित है, लेकिन इसे अपनी किसी भी फाइल को परोसने के लिए संघर्ष कर रहा हूं - चाहे PHP हो या न हो।

Nginx www-data: www-data, और डिफ़ॉल्ट "EPEL पर nginx में आपका स्वागत है" साइट के रूप में चल रहा है (रूट द्वारा स्वामित्व: 644 अनुमतियों के साथ रूट) लोड ठीक है।

Nginx कॉन्फ़िगरेशन फ़ाइल में /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;
 }
}

Public_html के पास www-data का स्वामित्व होने के बावजूद: 2777 फ़ाइल अनुमतियों के साथ 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 से 403s प्राप्त करने वाले उपयोगकर्ताओं के साथ कई अन्य पोस्ट पाए हैं, लेकिन सबसे ज्यादा मैंने रूबी / यात्री के साथ या तो अधिक जटिल सेटअप को शामिल किया है (जो कि वास्तव में मैं वास्तव में सफल रहा हूं) या केवल अपस्ट्रीम PHP होने पर त्रुटियां प्राप्त कर रहा हूं -एफपीएम शामिल है, इसलिए उन्हें थोड़ी मदद मिलती है।

क्या मैंने यहाँ मूर्खतापूर्ण कुछ किया है?


इस उत्तर की जाँच करें stackoverflow.com/questions/16808813/…
सैंड्स

जवाबों:


333

एक अनुमति की आवश्यकता जिसे अक्सर अनदेखा किया जाता है, एक उपयोगकर्ता को उस फ़ाइल तक पहुंचने के लिए किसी फ़ाइल के प्रत्येक मूल निर्देशिका में x अनुमतियों की आवश्यकता होती है। Www-data x access के लिए /, / home, / home / डेमो, आदि पर अनुमतियों की जाँच करें। मेरा अनुमान है कि / घर शायद 770 है और www-data इसके माध्यम से किसी भी उपखंड को प्राप्त करने के लिए chdir नहीं कर सकता है। यदि यह है, तो chmod o + x / home (या जो भी dir अनुरोध को अस्वीकार कर रहा है) का प्रयास करें।

संपादित करें: आसानी से एक पथ पर सभी अनुमतियों को प्रदर्शित करने के लिए, आप उपयोग कर सकते हैं namei -om /path/to/check


6
मुझे भी। CentOS 6 की मेरी स्थापना पर, / home / user dirs डिफ़ॉल्ट रूप से 700 पर सेट होते हैं।
jjt

2
यह आदमी इसके बारे में भी बात करता है: ( chmod -4 +x /mypathमेरे लिए काम किया) nginxlibrary.com/403-forbidden-error
पीटर

1
क्या कोई समझा सकता है कि यह व्यवहार अपाचे से भिन्न क्यों है, जिसे "x" अनुमतियों के लिए प्रत्येक माता-पिता निर्देशिका की आवश्यकता नहीं है?
जोशुआ डेविड

3
यह कोई अलग नहीं है। मूल कारण पर अपाचे को भी x अनुमति की आवश्यकता नहीं होगी यदि यह रूट के रूप में चल रहा है।
कोलबिजैक

मैंने अपने व्यक्तिगत उपयोगकर्ता समूह में www-data उपयोगकर्ता को जोड़ने और अपने रूट उपयोगकर्ता फ़ोल्डर में एक chmod 710 कर रहा है। एक जादू की तरह काम किया। (एक डेबियन आधारित डिस्ट्रो पर)
बेसिकडे

299

यदि आप अभी भी permission deniedमूल फ़ोल्डर की अनुमतियों को सत्यापित करने के बाद देखते हैं, तो यह SELinux प्रतिबंधित पहुंच हो सकती है ।

यह देखने के लिए कि क्या SELinux चल रहा है:

# getenforce

अगली रिबूट तक SELinux को निष्क्रिय करने के लिए:

# setenforce Permissive

Nginx को पुनरारंभ करें और देखें कि क्या समस्या बनी रहती है। Nginx को अपनी www निर्देशिका की सेवा करने की अनुमति दें (यह सुनिश्चित करने के लिए कि यह परीक्षण करने से पहले आप SELinux को वापस चालू कर दें। यानी। setenforce Enforcing)

# chcon -Rt httpd_sys_content_t /path/to/www

अधिक जानकारी के लिए यहां मेरा जवाब देखें


1
मैं यह पता नहीं लगा सका कि जब मैंने open() "/usr/share/nginx/logs/xxxxxx.com-error_log" failed (13: Permission denied)अनुमतियाँ जाँचने के बाद यह कहा कि मैंने इसे शुरू किया था और यह सुनिश्चित किया कि इसे रूट के रूप में शुरू किया जा रहा था। मुझे यह पता चला और पता चला कि SELinux सक्षम है। मैंने इसे निष्क्रिय कर दिया और अब यह बिना किसी समस्या के काम करता है। धन्यवाद!
ub3rst4r

1
धन्यवाद! मैं अभी भी उपयोगकर्ताओं को अपने स्वयं एफ पी एम सॉकेट के मालिक के लिए इनकार कर दिया अनुमति के साथ एक समस्या हुई तो मैं बदलकर उस एक का समाधान करने में सक्षम था userसे nginx को जड़ में /var/nginx/nginx.conf- शायद कि जो इस मुद्दे भर आता है और कुछ इच्छा मदद किसी को। दूसरे भाग के लिए DataPyche को S / O।
शीतकालीन

11
यह CentOS 7 aswell पर डिफ़ॉल्ट व्यवहार है।
19

4
इम हर किसी के साथ है कि टिप्पणी की। मैं अपना कंप्यूटर खिड़की से बाहर फेंकने के लिए तैयार था। Nginx को ठीक से कॉन्फ़िगर किया गया था, जहां अनुमतियाँ ठीक से सेट होती हैं, मैं भी सब कुछ 777 बनाने के लिए जहाँ तक गया था और अभी भी अनुमतियाँ अस्वीकृत त्रुटि मिली हैं।
DOfficial

2
Centos 7 (SELinux सक्षम) पर, मेरे लिए सबसे सरल फ़िक्स था setsebool httpd_read_user_content on(घरेलू निर्देशिका से होस्ट की गई स्थिर फ़ाइलों के लिए, विश्व-पठनीय के लिए chmod'ed) - हालाँकि मुझे लगता है कि @ KapiteinWitbaard के ऊपर की विधि अधिक सुरक्षित है।
टिमस्टेली

63

मैंने उपयोगकर्ता सेटिंग जोड़कर इस समस्या को हल किया।

nginx.conf में

worker_processes 4;
user username;

लिनक्स उपयोगकर्ता नाम के साथ 'उपयोगकर्ता नाम' बदलें।


4
मेरा मानना ​​है कि यह उत्तर स्वीकृत उत्तर की तुलना में बेहतर सुरक्षा वार है। आपको अपने होम फोल्डर (जो संवेदनशील जानकारी हो सकती है) पर अनुमतियों के साथ खिलवाड़ करने की ज़रूरत नहीं है और यदि आप nginx के साथ विकास कर रहे हैं, तो यह आपको SCM के लिए अजीब फ़ाइल अनुमतियां अपलोड करने से बचाता है।
CamelBlues

होम निर्देशिका पर अतिरिक्त अनुमतियाँ निष्पादित की जाती हैं, पढ़ी नहीं जाती हैं, इस प्रकार कोई भी संवेदनशील जानकारी नहीं है (सिद्धांत में) पता चला है (सिवाय, इस मामले में, शायद एक दुर्भावनापूर्ण PHP स्क्रिप्ट के लिए जो ऊपर की तरफ पुन: दर्ज हो और किसी अन्य निर्देशिका के भीतर संवेदनशील फ़ाइलों का स्थान जानता हो। www-data के लिए सुलभ)। आप यह भी देखेंगे कि मूल प्रश्न में, मेरा nginx "www-data" के रूप में चल रहा था - यहां कॉन्फ़िगरेशन मान पहले से ही वांछित थे।
एंगस आयरलैंड

2
उपयोगकर्ता समूह को भी जोड़ना था: उपयोगकर्ता का उपयोग समूह।
गेब्रियल ए। ज़ोरिल्ला

मेरे लिए भी काम किया है (बस के रूप में dir nginx करने के लिए: nginx chmodding)। मैं इस समाधान को पसंद करता हूं, हालांकि मैं अपने दस्तावेज़ रूट को nginx की तुलना में किसी अन्य उपयोगकर्ता के स्वामित्व में रख सकता हूं। इस ओर इशारा करने के लिए धन्यवाद एंडरसन।
kvdv

मेरा दिन बचाया। वैसे अगर मशीन में कई उपयोगकर्ता हैं और प्रत्येक उपयोगकर्ता की अपनी वेबसाइट है, तो मैं इससे कैसे निपटूं?
साइकोक 7

38

मुझे यह त्रुटि मिली है और मैंने अंत में इसे कमांड के साथ हल किया है।

restorecon -r /var/www/html

समस्या तब होती है जब आप किसी जगह से दूसरी जगह mv करते हैं। जब आप इसे स्थानांतरित करते हैं, तो यह मूल के selinux संदर्भ को संरक्षित करता है, इसलिए यदि आप / home / tmp में कुछ अनटार करते हैं तो इसे selinux संदर्भ दिया जाता है जो इसके स्थान से मेल खाता है। अब आप mv करते हैं कि / var / www / html और यह संदर्भ लेता है कि यह इसके साथ / tmp या / home में है और httpd को उन फ़ाइलों को एक्सेस करने की नीति द्वारा अनुमति नहीं है।

यदि आप फ़ाइलों को mv के बजाय cp करते हैं, तो selinux संदर्भ आपके द्वारा कॉपी किए जा रहे स्थान के अनुसार असाइन किया जाता है, न कि जहां से यह आ रहा है। रिस्टोरॉन चलाने से संदर्भ वापस अपने डिफ़ॉल्ट पर आ जाता है और इसे ठीक भी करता है।


1
धन्यवाद @jsina, इससे मुझे बहुत मदद मिली
पंकज गर्ग

1
धिक्कार है, +1 , मुझे भी।
jww

24

मैंने अलग-अलग मामलों की कोशिश की है और केवल जब मालिक को नगनेक्स ( chown -R nginx:nginx "/var/www/myfolder") में सेट किया गया था - यह उम्मीद के मुताबिक काम करना शुरू कर दिया।


1
मेरे लिए भी काम किया। मुझे संदेह है कि यह तब होता है क्योंकि भले ही nginx को रूट के रूप में शुरू किया गया हो, यह nginx.conf फ़ाइल में निर्दिष्ट उपयोगकर्ता के तहत प्रक्रियाओं को जन्म देता है, जो कि "उपयोगकर्ता nginx;" डिफ़ॉल्ट रूप से। उपयोगकर्ता को उपयोगकर्ता को बदलना जो आपके दस्तावेज़ रूट का मालिक है, को भी एंडरसन के सुझाव के अनुसार काम करना चाहिए।
kvdv

मिस्टर एंडरसन? नहीं! एंड्रॉन;)
एंडरॉन

क्षमायाचना श्री एंडरॉन;) मैं पिछली टिप्पणी को अब संपादित नहीं कर सकता, हालांकि ...
kvdv

ज़रूर, कोई समस्या नहीं है। अब मैं एंडरसन के रूप में था :) और कुछ परियों की कहानियों को लिखने की जरूरत है ...
एंडरन

1
क्या यह सुरक्षा मुद्दा नहीं है?
gontard 10

6

यदि आप SELinux का उपयोग कर रहे हैं, तो बस टाइप करें:

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

यह अनुमति समस्या को ठीक करेगा।


1

पुराना सवाल है, लेकिन मेरे पास एक ही मुद्दा था। मैंने ऊपर दिए गए हर उत्तर की कोशिश की, कुछ भी काम नहीं किया। हालाँकि डोमेन को हटाकर, और इसे फिर से जोड़ना मेरे लिए यह तय था। मैं Plesk का उपयोग कर रहा हूं, और मैंने Nginx AFTER को स्थापित किया डोमेन पहले से ही वहां था।

हालांकि पहले / var / www / बैकअप के लिए एक स्थानीय बैकअप था। इसलिए मैं आसानी से फाइलों को कॉपी कर सकता था।

अजीब समस्या है ...।


1

हमारे पास एक ही मुद्दा था, Plesk गोमेद 17 का उपयोग करना। अधिकारों आदि के साथ खिलवाड़ करने के बजाय, समाधान नगेंक्स उपयोगकर्ता को psacln समूह में जोड़ना था, जिसमें अन्य सभी डोमेन मालिक (उपयोगकर्ता) थे:

usermod -aG psacln nginx

अब nginx के पास एक्सेस .htaccess या किसी अन्य फ़ाइल को सामग्री को ठीक से दिखाने के लिए आवश्यक अधिकार हैं।

दूसरी ओर, यह भी सुनिश्चित करें कि Apache सोसरव समूह में है, स्थैतिक सामग्री परोसने के लिए:

usermod -aG psaserv apache

और Plache के बाद Apache और Nginx दोनों को पुनः आरंभ करना न भूलें! (और पृष्ठों को Ctrl-F5 के साथ पुनः लोड करें)


यह सही उत्तर है और usermod -aG username www-dataअधिकांश सेटअपों पर इसकी संभावना सबसे अधिक है ।
दारियो ज़ाद्रो

0

मैंने गलती से setfaclकमांड चलाने की गलती से इस समस्या को हलका कर दिया। मैं भागा:

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

मैं जोड़ने के पक्ष में इस मार्ग को छोड़ दिया nginxकरने के लिए fooसमूह है, लेकिन उस कस्टम एसीएल nginx के फ़ाइल तक पहुँचने का प्रयास विफल हो गया था। मैंने इसे चलाकर साफ़ किया:

sudo setfacl -b /home/foo/bar

और फिर nginx फ़ाइलों तक पहुँचने में सक्षम था।


0

यदि आप PHP का उपयोग कर रहे हैं, तो सुनिश्चित करें indexकि सर्वर ब्लॉक में NGINX निर्देश एक index.php शामिल है:

index index.php index.html;

अधिक जानकारी के लिए आधिकारिक दस्तावेज में इंडेक्स डायरेक्टिव चेकआउट करें ।


0

मैं एक ही मुद्दे का सामना कर रहा था लेकिन उपरोक्त समाधानों से मदद नहीं मिली।

इसलिए, बहुत संघर्ष के बाद मुझे पता चला कि सेस्टेटस को लागू करने के लिए सेट किया गया था जो सभी बंदरगाहों को अवरुद्ध करता है और इसे सेट करने के लिए सभी मुद्दों को हल करने के लिए।

sudo setenforce 0

आशा है कि यह मेरे जैसे किसी की मदद करेगा।


जबकि वह आपकी समस्या तय कर सकता है - बधाई! - यह थोड़ा दुखद है :-( stopdisablingselinux.com देखें - क्या आप एक अलग वर्कअराउंड ढूंढ सकते हैं?
एंगस आयरलैंड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.