แก้ไขข้อผิดพลาด “ไม่สามารถบันทึกเอกสารได้” ของ ONLYOFFICE ใน Nextcloud

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

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

เริ่มจากพฤติกรรมที่ได้รับการยืนยันแล้ว ไม่ใช่ข้อความแสดงข้อผิดพลาด

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

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

1. เรียกใช้ฟังก์ชันตรวจสอบการเชื่อมต่อในตัวของตัวเชื่อมต่อ

บนโฮสต์ Nextcloud ให้เรียกใช้การตรวจสอบตัวเชื่อมต่อ ONLYOFFICE ในฐานะผู้ใช้เว็บเซิร์ฟเวอร์ สำหรับการติดตั้ง Debian หรือ Ubuntu ทั่วไป:

cd /var/www/nextcloud
sudo -E -u www-data php occ onlyoffice:documentserver --check

เส้นทาง Nextcloud และผู้ใช้ HTTP ที่แน่นอนอาจแตกต่างกันไปตามการแจกจ่ายหรือโครงสร้างคอนเทนเนอร์ คู่มือการดูแลระบบของ Nextcloud เองแนะนำให้เรียกใช้occในฐานะผู้ใช้ HTTP เพื่อให้การเป็นเจ้าของไฟล์มีความสอดคล้องกัน เอกสาร ONLYOFFICE ถูกocc onlyoffice:documentserver --checkใช้เป็นตัวอย่างการทดสอบการเชื่อมต่อตัวเชื่อมต่อ

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

2. ตรวจสอบทั้งที่อยู่เซิร์ฟเวอร์สาธารณะและที่อยู่เซิร์ฟเวอร์ภายใน

ใน Nextcloud ให้เปิดการตั้งค่า → การจัดการ → ONLYOFFICEที่อยู่หลักของ ONLYOFFICE Docs ต้องสามารถใช้งานได้โดยไคลเอนต์และบริการที่เกี่ยวข้อง หาก URL สาธารณะไม่สามารถเข้าถึงได้ภายในเนื่องจากเครือข่าย Docker, NAT, DNS แบบ split-horizon หรือนโยบายไฟร์วอลล์ ให้ขยายการตั้งค่าเซิร์ฟเวอร์ขั้นสูง

ตัวเชื่อมต่ออย่างเป็นทางการได้เปิดเผยที่อยู่ภายในแยกต่างหากสำหรับสถานการณ์นี้โดยเฉพาะ:

• ที่อยู่ ONLYOFFICE Docs สำหรับการร้องขอภายในจากเซิร์ฟเวอร์ : ที่อยู่ซึ่ง Nextcloud ใช้ในการติดต่อ ONLYOFFICE
• ที่อยู่เซิร์ฟเวอร์สำหรับการร้องขอภายในจาก ONLYOFFICE Docs : ที่อยู่ซึ่ง ONLYOFFICE ใช้ในการติดต่อ Nextcloud สำหรับการเรียกกลับและการรับส่งข้อมูลระหว่างเซิร์ฟเวอร์ที่เกี่ยวข้อง

ตัวอย่างเช่น คอนเทนเนอร์สองตัวบนเครือข่าย Compose เดียวกัน อาจสามารถใช้ชื่อบริการภายในได้ ในขณะที่เบราว์เซอร์ยังคงใช้ชื่อโฮสต์ HTTPS สาธารณะ อย่าคัดลอกรูปแบบนั้นโดยไม่คิดไตร่ตรอง: ชื่อเหล่านั้นต้องสามารถใช้งานได้จริงในเครือข่ายของคุณวิธีแก้ไข:ทดสอบแต่ละทิศทางจากเครื่องหรือคอนเทนเนอร์ที่ส่งคำขอมา

ความเข้าใจผิดที่พบบ่อย: “โปรแกรมแก้ไขข้อความเปิดได้ ดังนั้น DNS และการกำหนดเส้นทางจึงไม่มีปัญหา”

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

ขั้นตอน:เข้าไปในคอนเทนเนอร์หรือโฮสต์ ONLYOFFICE แล้วทดสอบที่อยู่ Nextcloud ที่คาดว่าจะใช้งาน การร้องขอ HTTPS พื้นฐานไปยังโฮสต์ Nextcloud สามารถยืนยันการเข้าถึง DNS/TCP/TLS ได้ แต่โปรดจำไว้ว่าstatus.phpการร้องขอที่สำเร็จไม่ได้ตรวจสอบความถูกต้องของการอนุญาตการเรียกกลับหรือการจัดการ POST ที่แท้จริง

3. ตรวจสอบ JWT ก่อนเปลี่ยนกฎพร็อกซี

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

ตรวจสอบแล้ว:รหัสลับที่ใช้ร่วมกันต้องตรงกัน ขึ้นอยู่กับการติดตั้ง:ตำแหน่งที่คุณจัดการรหัสลับนั้นขึ้นอยู่กับว่า ONLYOFFICE ถูกติดตั้งจากแพ็กเกจ บน Windows หรือใน Docker ในการติดตั้งแบบ Docker JWT_SECRETมักใช้ตัวแปรสภาพแวดล้อม คุณสามารถตรวจสอบการกำหนดค่าเซิร์ฟเวอร์ที่มีผลได้ใน/etc/onlyoffice/documentserver/local.json.

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

4. ตรวจสอบบันทึก ONLYOFFICE และ Nextcloud ในช่วงเวลาที่การบันทึกล้มเหลว

ONLYOFFICE แนะนำให้ตรวจสอบบันทึก DocService เพื่อหาข้อผิดพลาดในการบันทึก สำหรับการติดตั้งบน Linux และ Docker บันทึกของ Document Server จะอยู่ภายใต้/var/log/onlyoffice/documentserver; ผู้ใช้ Docker ยังสามารถติดตามเอาต์พุตของคอนเทนเนอร์ได้ด้วยdocker logs -f <container>หากต้องการรายละเอียดเพิ่มเติม ONLYOFFICE ได้จัดทำเอกสารโหมดดีบักชั่วคราวผ่านDS_LOG_LEVEL=DEBUGหรือการกำหนดค่า log4js ดูคู่มือการบันทึกดีบักอย่างเป็นทางการ

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

sudo -E -u www-data php occ log:file

Nextcloud ยังบันทึกข้อมูลlog:tailเกี่ยวกับlog:watchแอป Log Reader ด้วย ขั้นตอนการดำเนินการ:จำลองข้อผิดพลาดในการบันทึกหนึ่งครั้ง บันทึกเวลาที่บันทึก จากนั้นเปรียบเทียบข้อมูลทั้งสองฝั่ง การปฏิเสธเครือข่าย ข้อผิดพลาด TLS การตอบสนอง 401/403 การตอบสนอง 5xx หรือข้อยกเว้นพื้นที่จัดเก็บข้อมูล ชี้ไปยังวิธีการแก้ไขที่แตกต่างกันมาก

5. แก้ไขปัญหา TLS และพร็อกซีแบบย้อนกลับโดยไม่ลดทอนความปลอดภัยในการใช้งานจริง

ใบรับรองที่ลงนามด้วยตนเองหรือออกโดยเอกชนอาจทำให้การเชื่อมต่อ HTTPS ระหว่างเซิร์ฟเวอร์ล้มเหลวได้ หาก CA ที่เกี่ยวข้องไม่น่าเชื่อถือ ตัวเชื่อมต่อมี ตัวเลือก "ปิดใช้งานการตรวจสอบใบรับรอง (ไม่ปลอดภัย)"แต่ ONLYOFFICE ระบุอย่างชัดเจนว่าไม่ปลอดภัยและแนะนำให้เปลี่ยนใบรับรองด้วยใบรับรองที่ออกโดย CA ที่น่าเชื่อถือการดำเนินการ:ใช้การข้ามการตรวจสอบใบรับรองเป็นเพียงขั้นตอนการวินิจฉัยระยะสั้นในสภาพแวดล้อมที่มีการควบคุมเท่านั้น การแก้ไขที่ยั่งยืนคือห่วงโซ่ใบรับรองที่ถูกต้องซึ่งได้รับความไว้วางใจจากทั้งสองเซิร์ฟเวอร์

หากมีการใช้งาน Reverse Proxy อยู่ด้านหน้า ONLYOFFICE โปรดตรวจสอบให้แน่ใจว่า Reverse Proxy นั้นยังคงรักษารูปแบบ (scheme) โฮสต์ (host) และพฤติกรรมการอัปเกรดที่คาดหวังไว้ ONLYOFFICE มีคำแนะนำเฉพาะเกี่ยวกับการใช้งาน Reverse Proxy รวมถึงส่วนหัวที่ส่งต่อ (forwarded headers) และการตั้งค่าที่เกี่ยวข้องกับ WebSocket โปรดดู คู่มือ การกำหนดค่า Reverse Proxy สำหรับ Nextcloud ของ ONLYOFFICE

ขึ้นอยู่กับการใช้งาน:ไม่สามารถอนุมานการกำหนดค่า Nginx, Apache, Traefik, HAProxy, ingress-controller หรือ CDN ที่แน่นอนได้จากข้อผิดพลาดในการบันทึกเพียงอย่างเดียวการดำเนินการ:เปรียบเทียบการกำหนดค่าพร็อกซีของคุณกับตัวอย่างของผู้จำหน่ายสำหรับโครงสร้างเครือข่ายของคุณ และตรวจสอบสถานะ HTTP ที่บันทึกไว้ระหว่างการเรียกกลับก่อนที่จะเปลี่ยนแปลงค่าหมดเวลาหรือส่วนหัวโดยพลการ

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

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

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

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

7. ทำความเข้าใจการทำงานของปุ่มบันทึกและการบันทึกแบบบังคับ

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

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

ตารางการวินิจฉัยอย่างรวดเร็ว

วิธีการตรวจสอบการแก้ไข

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

จากนั้นให้เรียกใช้การตรวจสอบตัวเชื่อมต่ออีกครั้ง:

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

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

เมื่อสาเหตุยังไม่ชัดเจน

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

ในขั้นตอนนี้ ให้บันทึกเวลาที่บันทึกไว้อย่างแม่นยำ รหัสสถานะ HTTP เวอร์ชันตัวเชื่อมต่อ เวอร์ชัน Nextcloud เวอร์ชัน ONLYOFFICE Docs โครงสร้างเครือข่าย และบรรทัดบันทึกที่เกี่ยวข้อง (ที่ถูกตัดทอนแล้ว) ข้อมูลเหล่านี้มีประโยชน์มากกว่าข้อความทั่วไปของเบราว์เซอร์ที่ว่า “ไม่สามารถบันทึกเอกสารได้”

เอกสารอ้างอิงอย่างเป็นทางการ

• ONLYOFFICE: คู่มือการผสานรวม Nextcloud
• การแก้ไขปัญหา ONLYOFFICE Docs API
• API ตัวจัดการการเรียกกลับ ONLYOFFICE
• การกำหนดค่า JWT ของ ONLYOFFICE
• การกำหนดค่าการบันทึกข้อมูลของ Nextcloud