กู้คืนการซิงค์ WebDAV ของ ownCloud โดยการค้นหาเส้นทางที่เสียหาย

แก้ไขข้อความเตือน “อินเทอร์เฟซ WebDAV ดูเหมือนจะเสีย” โดยตรวจสอบให้แน่ใจว่าสามารถเข้าถึงปลายทาง DAV ของ ownCloud ได้ และเว็บเซิร์ฟเวอร์ของคุณส่งต่อคำขอ WebDAV รวมถึงPROPFINDเมธอด ไปยังแอปพลิเคชัน PHP ของ ownCloud การเปลี่ยนแปลงที่ถูกต้องขึ้นอยู่กับว่า Apache, Nginx หรือพร็อกซีแบบย้อนกลับจัดการ URL สาธารณะหรือไม่ ทดสอบปลายทางก่อนแก้ไขการกำหนดค่าเพื่อให้คุณแก้ไขปัญหาในส่วนที่ล้มเหลว

ตรวจสอบว่าคำเตือนนั้นกำลังทดสอบอะไรกันแน่

ตัวตรวจสอบผู้ดูแลระบบของ ownCloud Classic รายงานคำเตือนนี้เมื่อการตรวจสอบการซิงโครไนซ์ไฟล์ไม่สามารถใช้ส่วนต่อประสาน WebDAV ได้ ในหลายกรณีเป็นปัญหาของเว็บเซิร์ฟเวอร์หรือเส้นทางการร้องขอ ไม่ใช่หลักฐานว่าไฟล์หรือฐานข้อมูลเสียหายเอกสารอ้างอิงคำเตือนอย่างเป็นทางการของ ownCloud Server 11อธิบายเรื่องนี้แยกต่างหากจากการตรวจสอบการค้นหา/.well-known/caldavบริการ/.well-known/carddav

ใช้ปลายทาง DAV ที่ตรงกับเส้นทางการติดตั้งสาธารณะของคุณ โดยทั่วไปแล้วที่รูทโดเมน ปลายทางจะเป็นhttps://cloud.example.com/remote.php/dav; เมื่อติดตั้งในไดเร็กทอรีย่อย ให้รวมไว้ด้วย เช่นhttps://cloud.example.com/owncloud/remote.php/davownCloud Classic 10.16 ยังมีเอกสารเกี่ยวกับ URL ความเข้ากันได้/remote.php/webdavสำหรับการเชื่อมต่อเดสก์ท็อปและตัวจัดการไฟล์บางอย่าง อย่าใช้ URL ไคลเอ็นต์แบบเก่าและปลายทาง DAV แบบใหม่แทนกันได้ในทุกการกำหนดค่า

ส่งPROPFINDคำขอที่ตรวจสอบสิทธิ์แล้วโดยมีระดับความลึกเป็นศูนย์ ในคำสั่งนี้ ให้แทนที่ตัวอย่างโฮสต์/พาธและชื่อผู้ใช้ Curl จะแจ้งให้ป้อนรหัสผ่านเนื่องจากมีการระบุเพียงชื่อผู้ใช้เท่านั้น-u:

curl -i -u 'USERNAME' -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/owncloud/remote.php/dav'

โดยทั่วไป การตอบสนอง WebDAV ที่ประสบความสำเร็จคือ207 Multi-Status. ตีความการตอบสนองอื่นๆ เป็นเบาะแส: 301หรือ302บ่งชี้ถึงปัญหาการเปลี่ยนเส้นทางหรือ URL มาตรฐาน; 401หมายความว่าการตรวจสอบสิทธิ์ไม่ได้รับการยอมรับ; 404มักหมายความว่าเส้นทางหรือการเขียนใหม่ของ PHP ไม่ได้เข้าถึง ownCloud; และ405หรือ501บ่งชี้ว่าเซิร์ฟเวอร์ พร็อกซี หรือเลเยอร์ความปลอดภัยปฏิเสธวิธีการ DAV การที่เบราว์เซอร์เปิด URL ที่มีหน้าเข้าสู่ระบบไม่ได้พิสูจน์ว่าPROPFINDใช้งาน ได้

เลือกวิธีแก้ไขตามรูปแบบของเว็บเซิร์ฟเวอร์

Apache: เปิดใช้งานกฎการเขียนใหม่ของ ownCloud ไว้

สำหรับการติดตั้ง Apache มาตรฐาน ก่อนอื่นให้ตรวจสอบว่าไฟล์ที่ ownCloud จัดเตรียมไว้นั้น.htaccessมีอยู่หรือไม่ และ Apache อนุญาตให้ใช้คำสั่ง rewrite ในไดเร็กทอรีการติดตั้งAllowOverride Noneหรือไม่ กระบวนการติดตั้งและอัปเกรด ownCloud จะเก็บรักษากฎเหล่านี้ไว้ หากป้องกันไม่ให้ Apache อ่านกฎเหล่านี้ ให้เพิ่มการแทนที่ที่จำเป็นสำหรับไดเร็กทอรี ownCloud หรือย้ายกฎที่เทียบเท่าไปยังการกำหนดค่า virtual-host ตัวเลือกแรกนั้นง่ายต่อการบำรุงรักษาสำหรับไซต์ ownCloud เดียวทั่วไป กฎ virtual-host แบบรวมศูนย์อาจเหมาะสมกว่าเมื่อนโยบายกำหนดให้มีการกำหนดค่าภายนอกไดเร็กทอรีแอปพลิเคชัน

อย่าคัดลอกบล็อกการเขียนใหม่ทั่วไปมาวางทับบนการกำหนดค่าที่ใช้งานได้อยู่แล้ว ตรวจสอบให้แน่ใจว่าmod_rewriteเปิดใช้งานอยู่ เว็บไซต์ชี้ไปยังไดเร็กทอรีหลักของ ownCloud ที่ถูกต้อง และคำขอ/remote.php/davเข้าถึงตัวจัดการ PHP ถูกต้อง หลังจากเปลี่ยนการกำหนดค่า Apache แล้ว ให้ทำการทดสอบการกำหนดค่าก่อนที่จะโหลดใหม่ ใน ownCloud Classic 11 ที่ใช้ Docker รูปภาพจะจัดการการกำหนดค่า Apache ที่ฝังอยู่ภายใน ใช้กลไกการกำหนดค่าและสภาพแวดล้อมที่รองรับโดยรูปภาพแทนการแก้ไขไฟล์ที่สร้างขึ้นภายในคอนเทนเนอร์ที่กำลังทำงานอยู่ ดูเอกสารการแก้ไขปัญหา ownCloud Server 11

Nginx: ใช้การตั้งค่าเซิร์ฟเวอร์ ownCloud

Nginx ไม่สามารถอ่าน.htaccessไฟล์ของ Apache ได้ หาก Nginx ให้บริการ ownCloud โดยตรง ให้ใช้การกำหนดค่า Nginx ที่ตรงกับเวอร์ชัน ownCloud และเส้นทางการติดตั้งของคุณ รวมถึงการจัดการตำแหน่ง PHP และการกำหนดเส้นทางที่เกี่ยวข้องกับ DAV ด้วย การใช้ตำแหน่ง PHP แบบกำหนดเองที่เรียบง่ายอาจให้บริการเว็บอินเทอร์เฟซได้ แต่กลับแสดงข้อ/remote.php/davผิดพลาด 404 หรือส่งไปยังตัวจัดการที่ไม่ถูกต้อง เปรียบเทียบโค้ดเซิร์ฟเวอร์ที่ใช้งานอยู่กับเอกสารการติดตั้ง ownCloud 10.16 ของผู้จำหน่าย จากนั้นทดสอบการกำหนดค่าและรีโหลด Nginx คำสั่งที่แน่นอนจะขึ้นอยู่กับการแจกจ่าย ซ็อกเก็ต PHP-FPM และว่า ownCloud อยู่ที่รูทโดเมนหรือไดเร็กทอรีย่อย

รีเวิร์สพร็อกซี: รักษาเส้นทาง วิธีการ และ URL สาธารณะ

หากพร็อกซีทำการยุติ HTTPS หรือกำหนดเส้นทางย่อย เช่น `<path>` /cloudให้ตรวจสอบว่าพร็อกซีส่งต่อเส้นทาง DAV ทั้งหมดไปยังแบ็กเอนด์และอนุญาตวิธีการ WebDAV เช่นPROPFIND` <path>` PUT, MOVE`<path>` และDELETE`<path>` หรือไม่ พร็อกซีหรือไฟร์วอลล์แอปพลิเคชันเว็บอาจบล็อกวิธีการบางอย่างได้แม้ว่าปลายทาง PHP จะถูกต้องก็ตาม เปรียบเทียบคำขอที่ส่งผ่าน URL สาธารณะกับคำขอที่ส่งตรงไปยังแบ็กเอนด์จากเครือข่ายที่เชื่อถือได้ หากการเข้าถึงโดยตรงส่งคืนรหัส 207 แต่คำขอสาธารณะล้มเหลว ให้มุ่งเน้นไปที่เส้นทางพร็อกซี การกรองวิธีการ การเปลี่ยนเส้นทาง และส่วนหัวการอนุญาต

ตั้งค่า ownCloud trusted_proxiesให้เป็นที่อยู่พร็อกซีจริงเท่านั้น หากการตรวจจับ URL อัตโนมัติล้มเหลว การตั้งค่า overwritehost, overwriteprotocol, และoverwritewebrootอาจอธิบาย URL สาธารณะได้ แต่จะไม่สามารถแก้ไขวิธีการ DAV ที่ถูกบล็อกหรือเส้นทาง PHP ที่หายไปได้ ความเชื่อถือพร็อกซีที่ไม่ถูกต้องอาจอนุญาตให้มีการปลอมแปลงส่วนหัวที่อยู่ไคลเอ็นต์ได้ โปรดใช้คำแนะนำการกำหนดค่าพร็อกซีแบบย้อนกลับ อย่างเป็นทางการ สำหรับโทโพโลยีของคุณ

ควรแยกการค้นหา DAV ออกจากการเข้าถึงไฟล์

URL เหล่า/.well-known/caldavนี้/.well-known/carddavช่วยให้ไคลเอนต์ปฏิทินและรายชื่อติดต่อค้นหาปลายทางบริการได้ โดยควรจะนำไปยังปลายทาง DAV ของ ownCloud แต่หากเกิดความล้มเหลว จะมีคำเตือนแยกต่างหากจากการตรวจสอบ WebDAV ที่มีปัญหาในการซิงโครไนซ์ไฟล์ การแก้ไขเฉพาะการเปลี่ยนเส้นทางการค้นหาเหล่านี้อาจไม่สามารถล้างคำเตือนการซิงโครไนซ์ได้ สำหรับ Apache กฎที่มาพร้อมกับ ownCloud อาจจัดการการค้นหาได้เมื่อเปิดใช้งาน สำหรับ Nginx และการใช้งานแบบไดเร็กทอรีย่อย จำเป็นต้องมีการกำหนดค่าเซิร์ฟเวอร์ที่ตรงกัน ตรวจสอบ URL แต่ละรายการและเป้าหมายการเปลี่ยนเส้นทางแยกกัน โดยปฏิบัติตามคำแนะนำคำเตือนอย่างเป็นทางการของ ownCloud

ตรวจสอบการซ่อมแซม

ทำการทดสอบการตรวจสอบ สิทธิ์ซ้ำอีกครั้งPROPFINDกับ URL DAV สาธารณะ และยืนยันว่าได้ผลลัพธ์ที่ถูกต้อง จาก207 Multi-Statusนั้นรีเฟรชหน้าการจัดการ ownCloud และทำการทดสอบการซิงค์ขนาดเล็กด้วยไคลเอ็นต์เดสก์ท็อป หากคำขอยังคงล้มเหลว ให้เปรียบเทียบสถานะ HTTP และการประทับเวลา กับบันทึกของเว็บเซิร์ฟเวอร์ พร็อกซี PHP และ ownCloud ใน Docker เอกสารของ ownCloud ระบุว่าบันทึกแอปพลิเคชันอาจอยู่ในไดเร็กทอรีบันทึกที่เชื่อมต่อ ในขณะที่บันทึกของ Apache และ PHP จะถูกส่งไปยังเอาต์พุตของคอนเทนเนอร์ ซึ่งdocker compose logs owncloudสามารถช่วยค้นหาข้อผิดพลาดเหล่านั้นได้

คู่มือปัจจุบันของ ownCloud ครอบคลุมทั้ง Classic 11.0 และ 10.16 และลักษณะการติดตั้งจะแตกต่างกันไปตามเวอร์ชัน โดยเอกสารของ Classic 11 ระบุว่า Docker เป็นวิธีการติดตั้งที่รองรับ โปรดใช้คู่มือสำหรับเวอร์ชันที่ใช้งานอยู่ และหลีกเลี่ยงการนำโค้ด Apache หรือ Nginx เก่าๆ ไปใช้กับคอนเทนเนอร์หรือพร็อกซีเวอร์ชันใหม่กว่าโดยไม่ตรวจสอบให้ดี