ติดตามการทำงานของฟังก์ชันบันทึกเมื่อ ONLYOFFICE ไม่สามารถบันทึกไปยัง Nextcloud ได้

ตัวอย่างสมมติ:มินาแก้ไขแผนโครงการใน ONLYOFFICE จากโฟลเดอร์ใน Nextcloud โปรแกรมแก้ไขเปิดขึ้นและยอมรับการเปลี่ยนแปลงของเธอ แต่ต่อมา Nextcloud รายงานว่า “ไม่สามารถบันทึกเอกสารได้” ตัวอย่างนี้เป็นเพียงตัวอย่างประกอบ ไม่ใช่รายงานการทดสอบจริง ในสถานการณ์นี้ ให้เปิดโปรแกรมแก้ไขไว้ เก็บสำเนาของงานที่ยังไม่ได้บันทึกไว้ในเครื่อง และตรวจสอบว่า ONLYOFFICE Docs สามารถติดต่อฟังก์ชันบันทึกของ Nextcloud ได้โดยตรงหรือไม่ จากนั้นใช้บันทึกเพื่อแยกแยะความล้มเหลวในการส่งฟังก์ชันบันทึกออกจากปัญหาพื้นที่จัดเก็บหรือสิทธิ์การเข้าถึงของ Nextcloud

โปรแกรมแก้ไขเอกสาร ONLYOFFICE แสดงแผนโครงการและตัวบ่งชี้ว่าบันทึกการเปลี่ยนแปลงทั้งหมดแล้ว
ตัวบ่งชี้การบันทึกของตัวแก้ไขนั้นมีประโยชน์ แต่โปรดตรวจสอบให้แน่ใจว่าไฟล์ที่อัปเดตแล้วนั้นมีอยู่ใน Nextcloud หลังจากปิดเซสชันการแก้ไขแล้ว

1. ป้องกันการเปลี่ยนแปลงของมินา ก่อนทำการแก้ไขปัญหา

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

ทดสอบไฟล์ DOCX ขนาดเล็กในโฟลเดอร์มาตรฐานของ Nextcloud หากบันทึกได้ ให้ตรวจสอบสิทธิ์การเข้าถึงไฟล์ สถานะการแชร์ พื้นที่จัดเก็บ หรือรูปแบบไฟล์ต้นฉบับ หากบันทึกไฟล์ทั้งหมดไม่ได้ ให้เริ่มจากเส้นทางเรียกกลับที่แชร์และสถานะของเซิร์ฟเวอร์

2. ตรวจสอบฟังก์ชันเรียกกลับสำหรับการบันทึกข้อมูลระหว่างเซิร์ฟเวอร์

ONLYOFFICE Docs จะส่งคำขอ POST ไปยัง URL การเรียกกลับที่ได้รับจากตัวเชื่อมต่อ Nextcloud จากนั้น Nextcloud จะดึงไฟล์ที่แก้ไขแล้วและอัปเดตเวอร์ชันที่จัดเก็บไว้ โปรแกรมแก้ไขอาจเปิดได้ตามปกติ แต่จะบันทึกไม่สำเร็จหาก Document Server ไม่สามารถส่งข้อมูลกลับไปยัง Nextcloud ได้

จำลองปัญหาโดยใช้ไฟล์ทดสอบ จากนั้นเปรียบเทียบบันทึกของ DocService และ Nextcloud ในเวลานั้น บน Linux บันทึกของ ONLYOFFICE จะอยู่ใน/var/log/onlyoffice/documentserver/; ใน Docker ให้ตรวจสอบบันทึกของคอนเทนเนอร์หรือไดเร็กทอรีบันทึกที่เชื่อมต่อไว้ บันทึกไฟล์เริ่มต้นของ Nextcloud จะอยู่nextcloud.logในไดเร็กทอรีข้อมูล เว้นแต่ว่าlog_typeหรือlogfileจะเปลี่ยนแปลงมัน

  • 301, 302 หรือ 308:การเปลี่ยนเส้นทาง URL แบบ Callback ซึ่งมักเกิดขึ้นระหว่าง HTTP/HTTPS หรือชื่อโฮสต์
  • หมดเวลาหรือเกิดข้อผิดพลาด DNS:เซิร์ฟเวอร์เอกสารไม่สามารถแก้ไขหรือเข้าถึง URL ได้
  • 403 หรือ 404:พร็อกซี, กฎการเข้าถึง, การเขียนเส้นทางใหม่ หรือการตั้งค่าโฮสต์อาจปฏิเสธคำขอ
  • ข้อผิดพลาดในการจัดเก็บข้อมูล Nextcloud:ได้รับการแจ้งเตือนแล้ว โปรดตรวจสอบโควต้า สิทธิ์ สถานะการจัดเก็บข้อมูล หรือการล็อก
การตั้งค่าการดูแลระบบ Nextcloud ONLYOFFICE พร้อมช่องที่อยู่เซิร์ฟเวอร์สาธารณะและภายในตามที่ระบุไว้ในเอกสาร
ช่องที่อยู่ภายในของตัวเชื่อมต่อใช้สำหรับเส้นทางระหว่างเซิร์ฟเวอร์เมื่อไม่สามารถเข้าถึง URL สาธารณะได้จากทั้งสองเซิร์ฟเวอร์

3. แก้ไข URL หรือเส้นทางพร็อกซีเมื่อมีการเปลี่ยนเส้นทางการเรียกกลับ

ใน Nextcloud ให้เปิดการตั้งค่า > การจัดการ > ONLYOFFICEตรวจสอบให้แน่ใจว่าที่อยู่ ONLYOFFICE Docs สาธารณะเป็น URL ที่เบราว์เซอร์ของผู้ใช้ควรโหลด หากเซิร์ฟเวอร์ทั้งสองไม่สามารถติดต่อกันได้ผ่านที่อยู่สาธารณะ ให้ตั้งค่าฟิลด์ภายในที่ระบุไว้ในเอกสาร: ที่อยู่ ONLYOFFICE Docs สำหรับการร้องขอภายในจากเซิร์ฟเวอร์และที่อยู่เซิร์ฟเวอร์สำหรับการร้องขอภายในจาก ONLYOFFICE Docsอันแรกต้องใช้งานได้จาก Nextcloud ไปยัง Document Server ส่วนอันที่สองต้องใช้งานได้จาก Document Server ไปยัง Nextcloud

ในการตั้งค่าสมมุติของมินา ฟังก์ชันเรียกกลับจะใช้http://cloud.example.comและเปลี่ยนเส้นทางไปยัง HTTPS กำหนดค่าที่อยู่ HTTPS สุดท้ายโดยตรง จากนั้นตรวจสอบให้แน่ใจว่า DNS กฎไฟร์วอลล์ และความเชื่อถือของใบรับรองอนุญาตให้ Document Server เข้าถึงได้ พร็อกซีควรส่งฟังก์ชันเรียกกลับไปยัง Nextcloud โดยไม่ต้องเปลี่ยนเส้นทางรูปแบบ ชื่อโฮสต์ หรือพาธ ชื่อโฮสต์ตัวอย่างไม่เหมาะสำหรับการติดตั้งจริง

ฟังก์ชันตรวจสอบการเชื่อมต่อของ ONLYOFFICE สามารถช่วยตรวจสอบที่อยู่บริการที่กำหนดค่าไว้ได้:

sudo -u www-data php occ onlyoffice:documentserver --check

เรียกใช้งานจากไดเร็กทอรี Nextcloud โดยใช้บัญชีเว็บเซิร์ฟเวอร์ที่เหมาะสม การตรวจสอบที่สำเร็จไม่ได้หมายความว่าการเรียกกลับ POST จะทำงานได้ การร้องขอ HEAD ด้วยตนเองหรือหน้าเว็บเบราว์เซอร์ที่โฮสต์เนมเดียวกันก็ไม่ใช่หลักฐานเช่นกัน

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

4. ติดตามหลักฐานไปยังพื้นที่จัดเก็บข้อมูล Nextcloud

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

การล็อกไฟล์แบบธุรกรรมของ Nextcloud จะประสานการเขียนข้อมูล ดังนั้นอย่าปิดใช้งานเพื่อแก้ไขปัญหาอย่างรวดเร็ว หากบันทึกชี้ไปที่ข้อผิดพลาดในการล็อกหรือฐานข้อมูล ให้ตรวจสอบแบ็กเอนด์การล็อกและบริการ Redis หรือ Valkey อย่าลบoc_file_locksแถวหรือไฟล์ล็อก เนื่องจากอาจขัดขวางการเขียนข้อมูลที่กำลังดำเนินการอยู่

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

มุมมองไฟล์ Nextcloud แสดงแผนโครงการพร้อมไอคอนสถานะสีเขียวและเวลาที่แก้ไขล่าสุด
หลังจากซ่อมแซมเสร็จแล้ว โปรดยืนยันว่าไฟล์ที่อัปเดตแล้วปรากฏอยู่ในโฟลเดอร์ Nextcloud ที่คาดไว้ และมีเวลาแก้ไขล่าสุด

5. ตรวจสอบเส้นทางการบันทึกข้อมูลให้ครบถ้วน

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

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

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

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

เอกสารนี้ได้รับการตรวจสอบเมื่อวันที่ 9 ตุลาคม 2569 ฟิลด์ตัวเชื่อมต่อและปลายทางบันทึกอาจแตกต่างกันไปตามเวอร์ชันแอปที่ติดตั้งและการกำหนดค่าการปรับใช้

ฝากความเห็น

ติดตามการทำงานของฟังก์ชันบันทึกเมื่อ ONLYOFFICE ไม่สามารถบันทึกไปยัง Nextcloud ได้

ติดตามการทำงานของฟังก์ชันบันทึกเมื่อ ONLYOFFICE ไม่สามารถบันทึกไปยัง Nextcloud ได้

ตรวจสอบสาเหตุการบันทึก ONLYOFFICE ที่ล้มเหลวโดยตรวจสอบเส้นทางการเรียกกลับของ Nextcloud การเปลี่ยนเส้นทางพร็อกซี และบันทึกการจัดเก็บข้อมูล จากนั้นตรวจสอบว่าไฟล์ที่แก้ไขแล้วยังคงอยู่หรือไม่

ป้องกันไม่ให้ ONLYOFFICE Document Server ใช้หน่วยความจำ VPS จนหมด

ป้องกันไม่ให้ ONLYOFFICE Document Server ใช้หน่วยความจำ VPS จนหมด

ค้นหาสาเหตุของปัญหาหน่วยความจำไม่เพียงพอของ ONLYOFFICE ตรวจสอบข้อจำกัดของ Docker กำหนดขนาด RAM ของ VPS ให้ถูกต้อง เพิ่ม swap อย่างปลอดภัย และตรวจสอบว่าเอกสารเปิดและบันทึกได้

ตรวจสอบหาสาเหตุของการส่งออกไฟล์ PDF ที่ล้มเหลวของ ONLYOFFICE

ตรวจสอบหาสาเหตุของการส่งออกไฟล์ PDF ที่ล้มเหลวของ ONLYOFFICE

แยกปัญหาการดาวน์โหลดผ่านเบราว์เซอร์ออกจากข้อผิดพลาดในการแปลงไฟล์ฝั่งเซิร์ฟเวอร์ และใช้บันทึกหรือการตรวจสอบการเข้าถึงที่ถูกต้องเพื่อให้การส่งออกไฟล์ PDF ทำงานได้

แก้ไขข้อผิดพลาด “โทเค็นไม่ถูกต้อง” ของ ONLYOFFICE ใน Nextcloud

แก้ไขข้อผิดพลาด “โทเค็นไม่ถูกต้อง” ของ ONLYOFFICE ใน Nextcloud

ตรงกับรหัสลับ JWT ที่ใช้โดย ONLYOFFICE Docs และ Nextcloud สามารถนำไปใช้ได้อย่างปลอดภัยสำหรับการติดตั้งบน Docker หรือ Linux และตรวจสอบการเชื่อมต่อโดยไม่ลดทอนความปลอดภัยในการยืนยันตัวตน

ติดตั้ง ONLYOFFICE Workspace Community บน Ubuntu 24.04

ติดตั้ง ONLYOFFICE Workspace Community บน Ubuntu 24.04

ติดตั้ง ONLYOFFICE Workspace Community บน Ubuntu 24.04 โดยใช้สคริปต์ Docker อย่างเป็นทางการ ตรวจสอบข้อกำหนดของเซิร์ฟเวอร์ ข้ามการติดตั้ง Mail หากไม่จำเป็น และตรวจสอบพอร์ทัลอย่างปลอดภัย

ตั้งค่ารหัสลับ JWT ของ ONLYOFFICE ระหว่างเซิร์ฟเวอร์และตัวเชื่อมต่อ

ตั้งค่ารหัสลับ JWT ของ ONLYOFFICE ระหว่างเซิร์ฟเวอร์และตัวเชื่อมต่อ

กำหนดค่ารหัสลับ JWT ที่ตรงกันสำหรับ ONLYOFFICE Docs และตัวเชื่อมต่อ โดยใช้ขั้นตอนที่ปลอดภัยสำหรับแพ็คเกจ Linux การใช้งาน Docker และการตรวจสอบยืนยัน

ตกแต่ง ONLYOFFICE Docs ด้วยโลโก้และสีธีมของคุณ

ตกแต่ง ONLYOFFICE Docs ด้วยโลโก้และสีธีมของคุณ

ใส่โลโก้บริษัทและสีอินเทอร์เฟซของคุณลงในโปรแกรมแก้ไขเอกสาร ONLYOFFICE Docs ที่ฝังอยู่ภายใน โดยใช้ไฟล์ธีมแบบกำหนดเองและการกำหนดค่าโปรแกรมแก้ไข ดูข้อจำกัดของรุ่นและการตรวจสอบการใช้งาน

รักษาการแก้ไขของผู้เขียนให้มองเห็นได้เมื่อส่งออกเป็นไฟล์ DOCX

รักษาการแก้ไขของผู้เขียนให้มองเห็นได้เมื่อส่งออกเป็นไฟล์ DOCX

ติดตามการแก้ไขใน Writer รักษาไฟล์ต้นฉบับ ODT ที่สามารถแก้ไขได้ และตรวจสอบไฟล์ DOCX ที่ส่งออกใน Word ก่อนที่จะแชร์

เปิดใช้งานโหมด FIPS บน SLES 15 และตรวจสอบสถานะการบูต

เปิดใช้งานโหมด FIPS บน SLES 15 และตรวจสอบสถานะการบูต

ปฏิบัติตามขั้นตอน SP7 ของ SUSE เพื่อเปิดใช้งานโหมด FIPS รีบูตเครื่องอย่างปลอดภัย ตรวจสอบนโยบายที่ใช้งานอยู่ และตรวจสอบว่าข้อกำหนดด้านการปฏิบัติตามกฎระเบียบของคุณต้องการโมดูลที่ผ่านการตรวจสอบแล้วหรือไม่

ตั้งค่าไดรฟ์ข้อมูลที่เข้ารหัส LUKS บน SLES

ตั้งค่าไดรฟ์ข้อมูลที่เข้ารหัส LUKS บน SLES

เปรียบเทียบ YaST และ cryptsetup สำหรับไดรฟ์ข้อมูล SLES ที่เข้ารหัสใหม่ เลือก LUKS1 หรือ LUKS2 และตรวจสอบพฤติกรรมการปลดล็อกและการเมานต์อย่างปลอดภัย