centos - Nginx 403 सभी फ़ाइलों के लिए वर्जित





http-status-code-403 php (8)


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

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

Nginx www-data के रूप में चल रहा है: www-data, और डिफ़ॉल्ट "ईपीईएल पर 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;
 }
}

Www_ डेटा के स्वामित्व वाले public_html के बावजूद: 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 के दौरान त्रुटियां प्राप्त कर रहे हैं -एफपीएम शामिल है, इसलिए वे थोड़ी मदद की प्रतीत होते हैं।

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




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

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

अजीब समस्या ....




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

nginx.conf में

worker_processes 4;
user username

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




मैंने गलती से setfacl कमांड चलाकर इस समस्या पर थोड़ा सा संस्करण setfacl । मैं भाग गया:

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

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

sudo setfacl -b /home/foo/bar

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




मुझे यह त्रुटि मिली है और मैंने अंत में इसे नीचे दिए गए आदेश के साथ हल किया है।

restorecon -r /var/www/html

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

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




एक अनुमति आवश्यकता जिसे अक्सर अनदेखा किया जाता है, उस उपयोगकर्ता को उस फ़ाइल तक पहुंचने के लिए फ़ाइल की प्रत्येक मूल निर्देशिका में x अनुमतियों की आवश्यकता होती है। Www-data x पहुंच के लिए /, / home, / home / demo आदि पर अनुमतियां जांचें। मेरा अनुमान है कि / घर शायद 770 है और www-data किसी भी subdir पाने के लिए इसके माध्यम से 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

अधिक जानकारी के लिए यहां मेरा उत्तर देखें




छिपी निर्देशिका और फाइलें कभी भी वेब पहुंच योग्य नहीं होनी चाहिए। आपके प्रश्न का सामान्य उत्तर यह है:

  location ~ /\.  { return 403; }

यह किसी भी उपनिर्देशिका में .git, .svn, .htaccess और इसी तरह की फ़ाइलों तक पहुंच से इनकार करता है।







nginx centos http-status-code-403 php