ในสคริปต์ PHP ไม่ว่าจะโทรinclude(), require(), fopen()หรืออนุพันธ์ของพวกเขาเช่นinclude_once, require_onceหรือแม้กระทั่งmove_uploaded_file()คนหนึ่งมักจะวิ่งเข้าไปในข้อผิดพลาดหรือคำเตือน:

ไม่สามารถเปิดสตรีม: ไม่มีไฟล์หรือไดเรกทอรีดังกล่าว

กระบวนการที่ดีในการค้นหาสาเหตุของปัญหาอย่างรวดเร็วคืออะไร

มีสาเหตุหลายประการที่อาจเกิดข้อผิดพลาดนี้และทำให้รายการตรวจสอบที่ดีของสิ่งที่จะตรวจสอบก่อนช่วยอย่างมาก

ลองพิจารณาว่าเรากำลังแก้ไขปัญหาบรรทัดต่อไปนี้:

require "/path/to/file"

รายการตรวจสอบ

1. ตรวจสอบพา ธ ของไฟล์เพื่อพิมพ์ผิด

• ตรวจสอบด้วยตนเอง (โดยการตรวจสอบเส้นทางด้วยสายตา)

• หรือย้ายสิ่งที่ถูกเรียกโดยrequire*หรือinclude*ไปยังตัวแปรของตัวเอง, สะท้อน, คัดลอก, และลองเข้าถึงมันจากเทอร์มินัล:

  $path = "/path/to/file";
  
  echo "Path : $path";
  
  require "$path";

  จากนั้นในเทอร์มินัล:

  cat <file path pasted>

2. ตรวจสอบว่าพา ธ ไฟล์นั้นถูกต้องเกี่ยวกับข้อควรพิจารณาพา ธ เทียบกับสัมบูรณ์

• หากเริ่มต้นด้วยเครื่องหมายสแลช "/" มันจะไม่อ้างถึงรูทของโฟลเดอร์เว็บไซต์ของคุณ (รูทเอกสาร) แต่เป็นรูทของเซิร์ฟเวอร์ของคุณ
  • ตัวอย่างเช่นไดเรกทอรีของเว็บไซต์ของคุณอาจเป็น /users/tony/htdocs
• ถ้ามันไม่ได้เริ่มต้นด้วยเครื่องหมายทับไปข้างหน้าก็จะขึ้นอยู่กับเส้นทางรวม (ดูด้านล่าง) หรือเส้นทางเป็นญาติ ถ้าเป็นญาติแล้ว PHP จะคำนวณค่อนข้างไปยังเส้นทางของไดเรกทอรีการทำงานปัจจุบัน
  • ดังนั้นจึงไม่สัมพันธ์กับเส้นทางของรูทเว็บไซต์ของคุณหรือไปยังไฟล์ที่คุณกำลังพิมพ์
  • ด้วยเหตุผลดังกล่าวให้ใช้พา ธ ของไฟล์ที่แน่นอนทุกครั้ง

ปฏิบัติที่ดีที่สุด :

เพื่อให้สคริปต์ของคุณแข็งแกร่งในกรณีที่คุณย้ายสิ่งต่าง ๆ ในขณะที่ยังคงสร้างเส้นทางสัมบูรณ์ที่รันไทม์คุณมี 2 ตัวเลือก:

1. require __DIR__ . "/relative/path/from/current/file"ใช้ __DIR__คงมายากลส่งกลับไดเรกทอรีของแฟ้มปัจจุบัน

2. กำหนดSITE_ROOTค่าคงที่ตัวเอง:

   • ที่รากของไดเรกทอรีเว็บไซต์ของคุณให้สร้างไฟล์เช่น config.php

   • ในconfig.phpเขียน

     define('SITE_ROOT', __DIR__);

   • ในทุกไฟล์ที่คุณต้องการอ้างอิงโฟลเดอร์รูทของไซต์รวมถึงconfig.phpจากนั้นใช้SITE_ROOTค่าคงที่ทุกที่ที่คุณต้องการ:

     require_once __DIR__."/../config.php";
     ...
     require_once SITE_ROOT."/other/file.php";

แนวทางปฏิบัติ 2 ข้อเหล่านี้ยังทำให้แอปพลิเคชันของคุณพกพาได้มากขึ้นเนื่องจากไม่ได้พึ่งพาการตั้งค่า ini เช่นพา ธ รวม

3. ตรวจสอบเส้นทางของคุณ

วิธีการรวมไฟล์อีกค่าค่อนข้างมิได้หมดจดอย่างคือการพึ่งพารวมถึงเส้นทาง นี่เป็นกรณีของไลบรารีหรือกรอบงานเช่นกรอบ Zend

การรวมเช่นนี้จะมีลักษณะเช่นนี้:

include "Zend/Mail/Protocol/Imap.php"

ในกรณีนั้นคุณจะต้องแน่ใจว่าโฟลเดอร์ที่เป็น "Zend" เป็นส่วนหนึ่งของพา ธ include

คุณสามารถตรวจสอบเส้นทางรวมกับ:

echo get_include_path();

คุณสามารถเพิ่มโฟลเดอร์ได้ด้วย:

set_include_path(get_include_path().":"."/path/to/new/folder");

4. ตรวจสอบว่าเซิร์ฟเวอร์ของคุณมีสิทธิ์เข้าถึงไฟล์ดังกล่าว

อาจเป็นไปได้ว่าผู้ใช้ที่ใช้กระบวนการเซิร์ฟเวอร์ (Apache หรือ PHP) นั้นไม่ได้รับอนุญาตให้อ่านหรือเขียนไฟล์ดังกล่าว

หากต้องการตรวจสอบว่าผู้ใช้เซิร์ฟเวอร์รายใดกำลังทำงานอยู่คุณสามารถใช้posix_getpwuid :

$user = posix_getpwuid(posix_geteuid());

var_dump($user);

ในการค้นหาการอนุญาตบนไฟล์ให้พิมพ์คำสั่งต่อไปนี้ในเทอร์มินัล:

ls -l <path/to/file>

และดูสัญลักษณ์สัญลักษณ์การอนุญาต

5. ตรวจสอบการตั้งค่า PHP

หากไม่มีการทำงานใด ๆ ข้างต้นแสดงว่าปัญหาอาจเป็นไปได้ว่าการตั้งค่า PHP บางอย่างห้ามไม่ให้เข้าถึงไฟล์นั้น

การตั้งค่าสามรายการอาจเกี่ยวข้อง:

1. open_basedir
   • หากตั้งค่าไว้ PHP จะไม่สามารถเข้าถึงไฟล์ใด ๆ นอกไดเรกทอรีที่ระบุได้ (แม้จะไม่ผ่านลิงก์สัญลักษณ์)
   • อย่างไรก็ตามพฤติกรรมเริ่มต้นนั้นไม่สามารถตั้งค่าได้ในกรณีที่ไม่มีข้อ จำกัด
   • สามารถตรวจสอบได้โดยโทรphpinfo()หรือใช้ini_get("open_basedir")
   • คุณสามารถเปลี่ยนการตั้งค่าได้โดยแก้ไขไฟล์ php.ini หรือไฟล์ httpd.conf ของคุณ
2. โหมดปลอดภัย
   • หากมีการเปิดใช้ข้อ จำกัด อาจนำไปใช้ อย่างไรก็ตามสิ่งนี้ถูกลบใน PHP 5.4 หากคุณยังอยู่ในรุ่นที่รองรับเซฟโหมดอัปเกรดเป็นเวอร์ชัน PHP ที่ยังคงรองรับอยู่
3. allow_url_fopen และ allow_url_include
   • สิ่งนี้ใช้ได้เฉพาะกับการรวมหรือเปิดไฟล์ผ่านกระบวนการเครือข่ายเช่น http: // ไม่เมื่อพยายามรวมไฟล์ไว้ในระบบไฟล์โลคัล
   • สามารถตรวจสอบด้วยini_get("allow_url_include")และตั้งค่าด้วยini_set("allow_url_include", "1")

กรณีมุม

หากไม่มีการเปิดใช้งานด้านบนเพื่อวินิจฉัยปัญหานี่คือสถานการณ์พิเศษที่อาจเกิดขึ้นได้:

1. การรวมไลบรารีที่ใช้พา ธ include

มันอาจเกิดขึ้นได้ที่คุณรวมไลบรารีตัวอย่างเช่นกรอบงาน Zend โดยใช้เส้นทางแบบสัมพันธ์หรือแบบสัมบูรณ์ ตัวอย่างเช่น :

require "/usr/share/php/libzend-framework-php/Zend/Mail/Protocol/Imap.php"

แต่คุณยังคงได้รับข้อผิดพลาดประเภทเดียวกัน

สิ่งนี้อาจเกิดขึ้นเนื่องจากไฟล์ที่คุณมี (รวมสำเร็จ) มีคำสั่ง include สำหรับไฟล์อื่นและตัวที่สองนั้นรวมคำสั่งจะถือว่าคุณได้เพิ่มพา ธ ของไลบรารีนั้นไปยังพา ธ include

ตัวอย่างเช่นไฟล์เฟรมเวิร์ก Zend ที่กล่าวถึงก่อนหน้านี้อาจมีดังต่อไปนี้:

include "Zend/Mail/Protocol/Exception.php" 

ซึ่งไม่ใช่การรวมโดยเส้นทางสัมพัทธ์หรือโดยเส้นทางสัมบูรณ์ สันนิษฐานว่าไดเร็กทอรีเฟรมเวิร์ก Zend ถูกเพิ่มเข้ากับพา ธ include

ในกรณีเช่นนี้ทางออกเดียวที่ทำได้คือเพิ่มไดเรกทอรีให้กับเส้นทางของคุณ

2. SELinux

หากคุณใช้งาน Security-Enhanced Linux อาจเป็นสาเหตุของปัญหาโดยปฏิเสธการเข้าถึงไฟล์จากเซิร์ฟเวอร์

ในการตรวจสอบว่า SELinux เปิดใช้งานบนระบบของคุณหรือไม่ให้รันsestatusคำสั่งในเทอร์มินัล หากคำสั่งไม่มีอยู่ SELinux จะไม่อยู่ในระบบของคุณ หากมีอยู่ก็ควรบอกคุณว่ามีการบังคับใช้หรือไม่

หากต้องการตรวจสอบว่านโยบาย SELinux เป็นสาเหตุของปัญหาหรือไม่คุณสามารถลองปิดได้ชั่วคราว อย่างไรก็ตามโปรดระวังเพราะสิ่งนี้จะปิดการป้องกันทั้งหมด อย่าทำสิ่งนี้บนเซิร์ฟเวอร์ที่ใช้งานจริงของคุณ

setenforce 0

หากคุณไม่ได้ปิด SELinux อีกต่อไปปัญหานี้จะเป็นต้นเหตุ

ในการแก้ปัญหาคุณจะต้องกำหนดค่า SELinux ตามลำดับ

ประเภทบริบทต่อไปนี้จะจำเป็น:

• httpd_sys_content_t สำหรับไฟล์ที่คุณต้องการให้เซิร์ฟเวอร์ของคุณสามารถอ่านได้
• httpd_sys_rw_content_t สำหรับไฟล์ที่คุณต้องการเข้าถึงแบบอ่านและเขียน
• httpd_log_t สำหรับล็อกไฟล์
• httpd_cache_t สำหรับไดเรกทอรีแคช

ตัวอย่างเช่นหากต้องการกำหนดhttpd_sys_content_tประเภทบริบทให้กับไดเรกทอรีรูทของเว็บไซต์ให้รัน:

semanage fcontext -a -t httpd_sys_content_t "/path/to/root(/.*)?"
restorecon -Rv /path/to/root

หากไฟล์ของคุณอยู่ในโฮมไดเรกทอรีคุณจะต้องเปิดhttpd_enable_homedirsบูลีนด้วย:

setsebool -P httpd_enable_homedirs 1

ไม่ว่าในกรณีใดอาจมีสาเหตุหลายประการที่ทำให้ SELinux ปฏิเสธการเข้าถึงไฟล์ขึ้นอยู่กับนโยบายของคุณ ดังนั้นคุณจะต้องสอบถามว่า นี่คือบทเรียนพิเศษเกี่ยวกับการกำหนดค่า SELinux สำหรับเว็บเซิร์ฟเวอร์

3. Symfony

หากคุณกำลังใช้ Symfony และพบข้อผิดพลาดนี้เมื่ออัปโหลดไปยังเซิร์ฟเวอร์อาจเป็นไปได้ว่าแคชของแอปไม่ได้ถูกรีเซ็ตเนื่องจากอาจapp/cacheถูกอัพโหลดหรือไม่ได้ล้างแคชนั้น

คุณสามารถทดสอบและแก้ไขปัญหานี้ได้โดยเรียกใช้คำสั่งคอนโซลต่อไปนี้:

cache:clear

4. ไม่ใช่อักขระ ACSII ภายในไฟล์ซิป

เห็นได้ชัดว่าข้อผิดพลาดนี้สามารถเกิดขึ้นได้เมื่อมีการโทรzip->close()เมื่อไฟล์บางไฟล์ใน zip มีอักขระที่ไม่ใช่ ASCII ในชื่อไฟล์เช่น "é"

ทางออกที่เป็นไปได้คือการตัดชื่อไฟล์utf8_decode()ก่อนสร้างไฟล์เป้าหมาย

ให้เครดิตแก่Fran Canoสำหรับการระบุและแนะนำวิธีแก้ไขปัญหานี้

เพื่อเพิ่มคำตอบที่มีอยู่ (ดีมาก)

ซอฟต์แวร์โฮสติ้งที่ใช้ร่วมกัน

open_basedirเป็นสิ่งที่สามารถทำให้คุณตอได้เพราะสามารถระบุได้ในการกำหนดค่าเว็บเซิร์ฟเวอร์ แม้ว่าวิธีนี้จะสามารถแก้ไขได้ง่ายหากคุณใช้เซิร์ฟเวอร์เฉพาะของคุณเอง แต่ก็มีบางแพคเกจซอฟต์แวร์โฮสติ้งที่ใช้ร่วมกันออกไป (เช่น Plesk, cPanel, ฯลฯ ) ซึ่งจะกำหนดค่าคำสั่งการกำหนดค่าตามแต่ละโดเมน เนื่องจากซอฟต์แวร์สร้างไฟล์กำหนดค่า (เช่นhttpd.conf) คุณไม่สามารถเปลี่ยนไฟล์นั้นโดยตรงเนื่องจากซอฟต์แวร์โฮสติ้งจะเขียนทับไฟล์นั้นเมื่อรีสตาร์ท

ด้วย Plesk พวกเขาให้สถานที่ที่จะแทนที่ให้เรียกว่าhttpd.conf vhost.confเฉพาะผู้ดูแลเซิร์ฟเวอร์เท่านั้นที่สามารถเขียนไฟล์นี้ได้ การกำหนดค่าสำหรับ Apache มีลักษณะเช่นนี้

<Directory /var/www/vhosts/domain.com>
    <IfModule mod_php5.c>
        php_admin_flag engine on
        php_admin_flag safe_mode off
        php_admin_value open_basedir "/var/www/vhosts/domain.com:/tmp:/usr/share/pear:/local/PEAR"
    </IfModule>
</Directory>

ให้ผู้ดูแลระบบเซิร์ฟเวอร์ของคุณปรึกษาคู่มือสำหรับซอฟต์แวร์โฮสต์และเว็บเซิร์ฟเวอร์ที่ใช้

สิทธิ์ของไฟล์

สิ่งสำคัญคือให้สังเกตว่าการดำเนินการไฟล์ผ่านเว็บเซิร์ฟเวอร์ของคุณนั้นแตกต่างจากบรรทัดคำสั่งหรือการดำเนินงาน cron ข้อแตกต่างที่สำคัญคือเว็บเซิร์ฟเวอร์ของคุณมีผู้ใช้และสิทธิ์ของตัวเอง เพื่อเหตุผลด้านความปลอดภัยที่ผู้ใช้ถูก จำกัด Apache เช่นมักจะเป็นapache, www-dataหรือhttpd(ขึ้นอยู่กับเซิร์ฟเวอร์ของคุณ) งาน cron หรือการดำเนินการ CLI มีสิทธิ์ใด ๆ ก็ตามที่ผู้ใช้เรียกใช้ (เช่นการเรียกใช้สคริปต์ PHP เนื่องจากรูทจะดำเนินการด้วยสิทธิ์ของรูท)

หลายครั้งที่ผู้คนจะแก้ไขปัญหาการอนุญาตด้วยการทำสิ่งต่อไปนี้ (ตัวอย่าง Linux)

chmod 777 /path/to/file

นี่ไม่ใช่แนวคิดที่ฉลาดเพราะไฟล์หรือไดเรกทอรีนั้นสามารถเขียนได้ทั่วโลก หากคุณเป็นเจ้าของเซิร์ฟเวอร์และเป็นผู้ใช้คนเดียวนี่ไม่ใช่เรื่องใหญ่ แต่ถ้าคุณอยู่ในสภาพแวดล้อมการโฮสต์ที่ใช้ร่วมกันคุณแค่ให้ทุกคนเข้าถึงเซิร์ฟเวอร์ของคุณ

สิ่งที่คุณต้องทำคือกำหนดผู้ใช้ที่ต้องการเข้าถึงและให้สิทธิ์การเข้าถึงแก่ผู้ใช้เท่านั้น เมื่อคุณทราบว่าผู้ใช้รายใดที่ต้องการการเข้าถึงคุณจะต้องแน่ใจว่า

1. ผู้ใช้นั้นเป็นเจ้าของไฟล์และอาจเป็นไดเรกทอรีหลัก (โดยเฉพาะไดเรกทอรีหลักหากคุณต้องการเขียนไฟล์) ในสภาพแวดล้อมการโฮสต์ที่ใช้ร่วมกันส่วนใหญ่จะไม่มีปัญหาเนื่องจากผู้ใช้ของคุณควรเป็นเจ้าของไฟล์ทั้งหมดที่อยู่ใต้รูทของคุณ ตัวอย่าง Linux แสดงอยู่ด้านล่าง

    chown apache:apache /path/to/file

2. ผู้ใช้และผู้ใช้รายนั้นเท่านั้นที่มีสิทธิ์เข้าถึง ใน Linux แนวทางปฏิบัติที่ดีคือchmod 600(เจ้าของเท่านั้นที่สามารถอ่านและเขียน) หรือchmod 644(เจ้าของสามารถเขียนได้ แต่ทุกคนสามารถอ่านได้)

คุณสามารถอ่านการอภิปรายเพิ่มเติมเกี่ยวกับสิทธิ์ Linux / Unix และผู้ใช้ที่นี่

1. ดูข้อผิดพลาดที่แน่นอน

รหัสของฉันทำงานได้ดีในทุกเครื่อง แต่เฉพาะในรหัสนี้เริ่มมีปัญหา (ซึ่งเคยทำงานฉันคิดว่า) ใช้เส้นทาง "document_root" เพื่อสะท้อนข้อบกพร่องและดูข้อผิดพลาดอย่างใกล้ชิดพบสิ่งนี้

คำเตือน: รวม ( D: /MyProjects/testproject//functions/connections.php ): ไม่สามารถเปิดสตรีม:

คุณสามารถดูว่าปัญหาอยู่ที่ไหน ปัญหาคือ // ก่อนหน้าที่

$document_root = $_SERVER['DOCUMENT_ROOT'];
echo "root: $document_root";
include($document_root.'/functions/connections.php');

ดังนั้นเพียงแค่ลบการบรรทุก / ออกจากการรวมและมันควรจะทำงานได้ดี สิ่งที่น่าสนใจคือพฤติกรรมนี้แตกต่างกันไปในแต่ละรุ่น ฉันเรียกใช้รหัสเดียวกันบนแล็ปท็อป Macbook Pro และพีซีเครื่องนี้ทำงานได้ดีจนกระทั่งทุกอย่าง หวังว่านี่จะช่วยใครซักคน

2. คัดลอกตำแหน่งไฟล์ในเบราว์เซอร์เพื่อให้แน่ใจว่ามีไฟล์อยู่ บางครั้งไฟล์จะถูกลบโดยไม่คาดคิด (เกิดขึ้นกับฉัน) และมันก็เป็นปัญหาในกรณีของฉันด้วย

เพิ่มสคริปต์ด้วยพารามิเตอร์การสืบค้น

นั่นคือกรณีของฉัน มันเชื่อมโยงกับคำถาม # 4485874แต่ฉันจะอธิบายที่นี่ในไม่ช้า
เมื่อคุณพยายามที่จะต้องการpath/to/script.php?parameter=valuePHP จะค้นหาชื่อไฟล์script.php?parameter=valueเนื่องจาก UNIX ช่วยให้คุณมีเส้นทางเช่นนี้
หากคุณต้องการส่งผ่านข้อมูลบางอย่างไปยังสคริปต์ที่รวมอยู่ให้ประกาศเป็น$variable=...หรือ$GLOBALS[]=...หรือวิธีอื่น ๆ ที่คุณต้องการ

หุ้นแซมบ้า

หากคุณมีเซิร์ฟเวอร์ทดสอบ Linux และคุณทำงานจากไคลเอนต์ Windows Samba จะรบกวนการใช้คำสั่งchmod ดังนั้นแม้ว่าคุณจะใช้:

chmod -R 777 myfolder

ในด้าน Linux เป็นไปได้อย่างเต็มที่ที่ Unix Group \ www-data ยังไม่สามารถเข้าถึงการเขียน โซลูชันที่ใช้งานได้อย่างหนึ่งหากการแชร์ของคุณถูกตั้งค่าให้ผู้ดูแลระบบ Windows ถูกแมปไปที่รูท: จาก Windows ให้เปิดการอนุญาตปิดการรับมรดกสำหรับโฟลเดอร์ของคุณพร้อมสำเนา

สาเหตุที่เป็นไปได้อีกประการหนึ่ง: การเปลี่ยนชื่อและ / หรือย้ายไฟล์ขณะอยู่ในโปรแกรมแก้ไขข้อความ ฉันทำตามขั้นตอนทั้งหมดข้างต้นโดยไม่ประสบความสำเร็จจนกว่าฉันจะลบไฟล์ที่ยังคงทิ้งข้อผิดพลาดนี้และสร้างขึ้นใหม่ซึ่งแก้ไขปัญหา