แก้ไขปัญหาหน้าจอว่างเปล่า/หน้าจอสีขาวผิดปกติของ ownCloud: เลือกเส้นทางการกู้คืนที่ถูกต้อง

เริ่มต้นด้วยการตัดสินใจว่าคุณมีหน้าว่างแบบไหนกันแน่

หน้าจอสีขาวแสดงข้อผิดพลาด (white screen of death) บน ownCloud เป็นเพียงอาการ ไม่ใช่การวินิจฉัยโรค วิธีแก้ไขที่ดีที่สุดขึ้นอยู่กับว่าเบราว์เซอร์ได้รับข้อผิดพลาดจากเซิร์ฟเวอร์ ได้รับ HTML ที่ถูกต้องแต่ไม่สามารถโหลด JavaScript หรือ CSS ได้ หรือเชื่อมต่อกับพร็อกซีแบบย้อนกลับที่ไม่สามารถเชื่อมต่อกับ ownCloud ได้เลย

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

คู่มือนี้ครอบคลุม ownCloud Classic ตามเอกสาร ownCloud Classic 11 ฉบับปัจจุบัน เวอร์ชัน 11 รองรับการใช้งานแบบ Docker โดยมีระบบปฏิบัติการ, PHP runtime, ฐานข้อมูล และ Apache อยู่ภายในคอนเทนเนอร์ที่ ownCloud จัดเตรียมไว้ให้ การติดตั้งเวอร์ชัน 10.x เก่ากว่าอาจยังคงใช้เว็บเซิร์ฟเวอร์และโครงสร้าง PHP-FPM แบบดั้งเดิม เลือกใช้คำสั่งที่ตรงกับการใช้งานของคุณ ดูข้อกำหนดของระบบ ownCloud Classic 11 ได้ที่ นี่

1. หน้าว่างนั้นส่งคืนรหัส HTTP 500 หรือเบราว์เซอร์เกิดข้อผิดพลาดหลังจากส่งคืนรหัส HTTP 200 ครับ?

เปิดเครื่องมือสำหรับนักพัฒนาของเบราว์เซอร์ แล้วตรวจสอบทั้ง แท็บ เครือข่ายและ แท็บ คอนโซลนอกจากนี้ ให้ทดสอบปลายทางจากเทอร์มินัลด้วย:

curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/

คำบรรยายภาพ: การตอบสนอง 500 จากฝั่งเซิร์ฟเวอร์บ่งชี้ว่าปัญหาอาจอยู่ที่ ownCloud, PHP, ฐานข้อมูล หรือเว็บแอปพลิเคชัน มากกว่าปัญหาการแสดงผลของเบราว์เซอร์ทั่วไป

หากเอกสารหลักส่งคืนรหัส 500หรือ502/503ให้ให้ความสำคัญกับบันทึกของเซิร์ฟเวอร์และพร็อกซี หากเอกสารหลักส่งคืนรหัส200แต่ชุด JavaScript ล้มเหลวด้วยรหัส 404, 403 หรือข้อยกเว้นสคริปต์ ให้ให้ความสำคัญกับเส้นทางของสินทรัพย์ การเขียนใหม่ของพร็อกซีแบบย้อนกลับ ธีม แคช หรือความเข้ากันได้ของแอป หากมีเพียงเบราว์เซอร์เดียวที่ได้รับผลกระทบ ให้ทดสอบในหน้าต่างส่วนตัวและเบราว์เซอร์อื่นที่รองรับก่อนที่จะเปลี่ยนเซิร์ฟเวอร์

2. ปัญหาเริ่มเกิดขึ้นหลังจากอัปเกรด ownCloud หรือ PHP หรือไม่?

นี่เป็นหนึ่งในคำถามที่มีค่ามากที่สุด เพราะสามารถช่วยจำกัดขอบเขตของปัญหาได้ทันที บันทึกการเผยแพร่เวอร์ชันปัจจุบันของ ownCloud ระบุว่า ownCloud Classic 11 ได้เพิ่มเวอร์ชัน PHP ขั้นต่ำเป็น PHP 8.3 และ ownCloud Classic 11 รองรับเฉพาะ Docker เท่านั้น การติดตั้ง ownCloud 10.x รุ่นเก่าใช้กฎความเข้ากันได้ของ PHP ที่แตกต่างกัน ดังนั้นอย่าคัดลอกคำแนะนำเกี่ยวกับ PHP จากเวอร์ชันหลักอื่น

สำหรับการติดตั้ง ownCloud 10.x แบบดั้งเดิม ให้รันคำสั่งจากไดเร็กทอรี ownCloud:

sudo -u www-data ./occ status
php -v

สำหรับ ownCloud Classic 11 ให้เรียกใช้ OCC ผ่านการปรับใช้ Compose:

docker compose exec owncloud occ status
docker compose exec owncloud php -v

คำบรรยายภาพ: การตรวจสอบเวอร์ชัน ownCloud และ PHP ที่ติดตั้งไว้มีความสำคัญอย่างยิ่ง โดยเฉพาะอย่างยิ่งเมื่อหน้าจอกลายเป็นสีขาวทันทีหลังจากการอัปเกรด

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

3. บันทึกข้อผิดพลาดใดที่แสดงข้อผิดพลาดที่ชัดเจนเป็นครั้งแรก?

โดยทั่วไปแล้ว บันทึกการทำงานจะมีประโยชน์มากกว่าการลองผิดลองถูกในการเปลี่ยนแปลงการตั้งค่า คู่มือการดูแลระบบของ ownCloud แนะนำให้ใช้บันทึกการทำงานของ ownCloud ในการวินิจฉัยปัญหา โดยค่าเริ่มต้น บันทึกการทำงานจะถูกจัดเก็บไว้ในไดเร็กทอรีข้อมูลที่กำหนดค่าไว้ เว้นแต่logfileจะมีการตั้งค่า เป็นอย่างอื่น

ในการติดตั้งแบบดั้งเดิม ตัวอย่างเช่น:

tail -n 100 /path/to/owncloud/data/owncloud.log
journalctl -u php-fpm --since "15 minutes ago"
journalctl -u apache2 --since "15 minutes ago"
journalctl -u nginx --since "15 minutes ago"

ใน ownCloud Classic 11 ให้ตรวจสอบบริการ Compose แทน:

docker compose logs --tail=200 owncloud
docker compose ps

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

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

เอกสารเกี่ยวกับการบันทึกข้อมูลของ ownCloud ระบุว่า การบันทึกข้อมูลระดับ DEBUG สามารถช่วยในการวินิจฉัยปัญหาได้ แต่จะสร้างข้อมูลจำนวนมากและอาจส่งผลต่อประสิทธิภาพการทำงาน หากคุณเพิ่มระดับการบันทึกข้อมูลชั่วคราว ให้ลดระดับการบันทึกข้อมูลลงหลังจากรวบรวมหลักฐานเสร็จแล้ว โปรดดู การกำหนดค่าการบันทึกข้อมูล ของownCloud

4. คุณควรปิดใช้งานแอปพลิเคชันจากผู้พัฒนาภายนอกหรือไม่?

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

แสดงรายการแอปก่อน ใน ownCloud เวอร์ชัน 10.x:

sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_ID

บน ownCloud 11:

docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID

คำบรรยายภาพ: การปิดใช้งานเฉพาะแอปพลิเคชันที่เกี่ยวข้องกับบันทึกการทำงานนั้นส่งผลกระทบน้อยกว่าการปิดใช้งานส่วนประกอบหลายอย่างหรือการเปลี่ยนแปลงโครงสร้างเว็บทั้งหมด

ข้อเสียคือฟังก์ชันการทำงาน: ผู้ใช้จะใช้งานแอปนั้นไม่ได้จนกว่าจะมีการอัปเดตหรือเปิดใช้งานใหม่ ซึ่งโดยทั่วไปแล้วจะดีกว่าการปิดใช้งานบริการหลักของ ownCloud เอกสารของ OCC ยังระบุด้วยว่าแอปหลักหลายแอปไม่สามารถปิดใช้งานได้ รวมถึง DAV, FederatedFileSharing, Files และ Files_External โปรดตรวจสอบคำแนะนำการแก้ไขปัญหาทั่วไปอย่างเป็นทางการและ เอกสาร อ้างอิงคำสั่ง OCC

5. เมื่อใดจึงควรแก้ไขสิทธิ์การเข้าถึง?

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

ตั้งค่าระบบให้อยู่ในโหมดบำรุงรักษาก่อนเริ่มงานซ่อมแซมที่ก่อให้เกิดการหยุดชะงัก สำหรับ ownCloud 11:

docker compose exec owncloud occ maintenance:mode --on

สำหรับการใช้งานเวอร์ชัน 10.x แบบดั้งเดิม:

sudo -u www-data ./occ maintenance:mode --on

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

อย่าใช้chmod 777สูตรการอนุญาตแบบเรียกซ้ำหรือคัดลอกแบบเหมาจ่ายจากเวอร์ชันที่ไม่เกี่ยวข้อง คู่มือ ownCloud 11 ฉบับปัจจุบันได้ระบุความเป็นเจ้าของและโหมดเฉพาะสำหรับไฟล์ที่เพิ่มด้วยตนเองในไดเร็กทอรีที่ติดตั้งใน Docker ไว้แล้วappsได้แก่configความเป็นเจ้าของwww-data:rootไฟล์แอป0644ไดเร็กทอรีแอป0751และไฟล์การกำหนดค่าที่เพิ่มเข้ามา0644นอกจากนี้ยังระบุ0640ถึงการเปลี่ยนแปลงด้วยตนเอง.htaccessด้วย.user.iniใช้เอกสารคู่มือการอัปเกรด ownCloud 11เป็นข้อมูลอ้างอิงเฉพาะเวอร์ชัน

6. คุณควรเปลี่ยนโมดูล PHP, OPcache หรือการตั้งค่าหน่วยความจำหรือไม่?

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

สำหรับระบบ PHP รุ่นเก่าที่จัดการโดยโฮสต์ ให้ตรวจสอบว่าเว็บรันไทม์โหลดอะไรบ้าง:

php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable

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

สำหรับ ownCloud 11 นั้น อิมเมจอย่างเป็นทางการจะจัดการรันไทม์ PHP ดังนั้นการเปลี่ยนแพ็กเกจ PHP ของโฮสต์จึงไม่ใช่ขั้นตอนที่ถูกต้อง ownCloud ระบุว่า OPcache เปิดใช้งานโดยค่าเริ่มต้นในอิมเมจ Docker ของตน โปรดดูเอกสารเกี่ยวกับการแคชหน่วยความจำของ ownCloud

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

7. การอัปเกรดถูกขัดจังหวะหรือไฟล์หลักไม่สอดคล้องกันหรือไม่?

หากหน้าจอว่างเปล่าปรากฏขึ้นระหว่างหรือหลังการอัปเกรดทันที ให้ตรวจสอบสถานะการอัปเกรดก่อน เอกสารการอัปเกรดของ ownCloud แนะนำให้ใช้ OCC สำหรับขั้นตอนการอัปเกรดและการซ่อมแซม แทนการแก้ไขฐานข้อมูลด้วยตนเอง

สำหรับ ownCloud 11:

docker compose exec owncloud occ status
docker compose exec owncloud occ upgrade
docker compose exec owncloud occ maintenance:repair
docker compose exec owncloud occ integrity:check-core

สำหรับ ownCloud เวอร์ชัน 10.x ให้ใช้คำสั่ง OCC ที่เทียบเท่ากันภายใต้ผู้ใช้เว็บเซิร์ฟเวอร์:

sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core

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

ผลลัพธ์ด้านความสมบูรณ์ของโค้ดจำเป็นต้องได้รับการตีความ เอกสาร ownCloud ระบุINVALID_HASH, FILE_MISSING, และEXTRA_FILEเป็นเงื่อนไขที่แตกต่างกัน อย่าแก้ไขsignature.jsonเพื่อทำให้คำเตือนหายไป เอกสาร ownCloud 11 ฉบับปัจจุบันยังกำหนดให้การลงนามแอปของบุคคลที่สามเป็นสิ่งจำเป็นสำหรับการติดตั้ง การอัปเดต และการเปิดใช้งาน โปรดดูเอกสารเกี่ยวกับการลงนามโค้ดของ ownCloud

8. คุณควรตรวจสอบความถูกต้องของการแก้ไขอย่างไร?

การกู้คืนที่ดีไม่ได้หมายความเพียงแค่ “หน้าเว็บไม่เป็นสีขาวอีกต่อไปแล้ว” ต้องตรวจสอบเส้นทางการร้องขอทั้งหมด:

• หน้าหลักของ ownCloud แสดงสถานะ HTTP ที่คาดหวังไว้ แทนที่จะเป็น 500/502/503
• เครื่องมือสำหรับนักพัฒนาเบราว์เซอร์ไม่แสดงข้อผิดพลาด JavaScript ร้ายแรงที่เกิดขึ้นซ้ำๆ หรือชุดแกนหลักที่ขาดหายไป
• บันทึกของ ownCloud จะไม่บันทึกข้อผิดพลาดร้ายแรงใหม่สำหรับคำขอเดียวกันในทันที
• occ statusรายงานระบุว่ามีการติดตั้งระบบเรียบร้อยแล้ว และไม่มีความจำเป็นต้องอัปเกรดเพิ่มเติมโดยไม่คาดคิด
• โหมดบำรุงรักษาจะถูกปิดใช้งานหลังจากเสร็จสิ้นการบำรุงรักษา
• ผู้ใช้ทดสอบสามารถล็อกอินและเปิดหน้าไฟล์ได้

สำหรับ ownCloud 11:

docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/

คำบรรยายภาพ: ควรตรวจสอบการกู้คืนระบบในทั้งสองระดับ: อินเทอร์เฟซ ownCloud โหลดได้ และสถานะฝั่งเซิร์ฟเวอร์และการตรวจสอบ HTTP ยังคงอยู่ในสภาพดี

วิธีแก้ไขใดให้ผลตอบแทนด้านความเสี่ยงต่อความเสี่ยงที่ดีที่สุด?

สิ่งที่ไม่ควรทำเมื่อ ownCloud แสดงหน้าจอสีขาว

• อย่าเปิดใช้งาน PHP display_errorsบนเว็บไซต์ที่ใช้งานจริงเพื่อเปิดเผยข้อมูลการติดตามข้อผิดพลาดให้เบราว์เซอร์เห็น ให้ใช้บันทึกเซิร์ฟเวอร์แทน
• อย่าตั้งค่าสิทธิ์การเขียนให้กับโครงสร้างไฟล์ ownCloud ทั้งหมดแบบวนซ้ำ
• อย่าดาวน์เกรด ownCloud เพื่อทำการย้อนกลับอย่างรวดเร็ว เว้นแต่คุณจะกู้คืนข้อมูลสำรองที่ได้รับการสนับสนุนไปยังสภาพแวดล้อมที่เข้ากันได้
• ห้ามลบไดเร็กทอรีข้อมูล ข้อมูลแอปพลิเคชัน ตารางฐานข้อมูล หรือไดเร็กทอรีแคชโดยพลการ
• อย่าปิดใช้งานทุกแอปพร้อมกัน หากสามารถแยกปิดใช้งานแอปใดแอปหนึ่งได้
• ห้ามแก้ไขไฟล์หลักที่ลงนามแล้ว หรือsignature.jsonแก้ไขเพื่อระงับข้อผิดพลาดด้านความสมบูรณ์ของข้อมูล

เมื่อไหร่คุณควรจะเพิ่มระดับการรักษาแทนที่จะทดลองต่อไปเรื่อยๆ?

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

ก่อนที่จะเปิดเคสขอความช่วยเหลือ ownCloud แนะนำให้รวบรวมรายงานการกำหนดค่าและบันทึกที่เกี่ยวข้อง สำหรับ ownCloud เวอร์ชัน 10.x คำสั่งที่ระบุไว้ในเอกสารคือ:

sudo -u www-data ./occ configreport:generate > config_report.txt

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

ข้อมูลอ้างอิงอย่างเป็นทางการ

• การแก้ไขปัญหาทั่วไปของ ownCloud Classic 11
• ข้อกำหนดระบบสำหรับ ownCloud Classic 11
• บันทึกการเปลี่ยนแปลงของ ownCloud Server
• การอัปเกรดด้วยตนเองของ ownCloud Classic 11
• การกำหนดค่าการบันทึก ownCloud