مثال افتراضي: تقوم مينا بتعديل خطة مشروع في ONLYOFFICE من مجلد Nextcloud. يفتح المحرر ويقبل التغييرات، لكن Nextcloud يُبلغ لاحقًا برسالة "تعذر حفظ المستند". هذا المثال توضيحي فقط، وليس تقريرًا عن اختبار حقيقي. في هذه الحالة، أبقِ المحرر مفتوحًا، واحتفظ بنسخة محلية من العمل غير المحفوظ، وتحقق مما إذا كان بإمكان ONLYOFFICE Docs الوصول مباشرةً إلى دالة الحفظ في Nextcloud. ثم استخدم سجلات النظام للتمييز بين فشل توجيه دالة الحفظ ومشكلة في مساحة تخزين Nextcloud أو أذونات الوصول.
لا تغلق المحرر أو تُحدّثه طالما أنه يحتوي على تغييرات لم يحفظها Nextcloud. استخدم خيار "التنزيل كـ" في المحرر للاحتفاظ بنسخة استرداد محلية، إذا ظل المحرر يعمل. دوّن وقت فشل الحفظ واسم الملف ليتمكن المسؤول من مطابقة السجلات.
اختبر ملف DOCX صغيرًا في مجلد Nextcloud عادي. إذا تم حفظه بنجاح، فركز على أذونات الملف الأصلي، وحالة المشاركة، ومساحة التخزين، أو التنسيق. إذا فشلت جميع الملفات، فابدأ بفحص مسار الاستدعاء المشترك وحالة الخادم.
يرسل تطبيق ONLYOFFICE Docs طلب POST إلى عنوان URL المُستدعى المُقدّم من موصل Nextcloud. ثم يسترجع Nextcloud الملف المُعدّل ويُحدّث نسخته المُخزّنة. قد يفتح المُحرّر بشكل طبيعي، لكنّه قد يتعذّر عليه الحفظ إذا لم يتمكّن خادم المستندات من إرسال البيانات إلى Nextcloud.
أعد إنتاج المشكلة باستخدام ملف اختبار، ثم قارن سجلات DocService وNextcloud في ذلك الوقت. في نظام Linux، توجد سجلات ONLYOFFICE في المسار التالي /var/log/onlyoffice/documentserver/: `/usr/local/docservice//. في Docker، تحقق من سجلات الحاوية أو دليل السجلات المُثبَّت. يوجد سجل ملفات Nextcloud الافتراضي nextcloud.logفي دليل البيانات الخاص به، ما لم log_typeيتم logfileتغييره.
في Nextcloud، افتح الإعدادات > الإدارة > ONLYOFFICE . تأكد من أن عنوان ONLYOFFICE Docs العام هو عنوان URL الذي يجب أن تُحمّله متصفحات المستخدمين. إذا تعذّر على الخادمين الوصول إلى بعضهما عبر عناوينهما العامة، فعيّن الحقول الداخلية الموثقة: عنوان ONLYOFFICE Docs للطلبات الداخلية من الخادم ، وعنوان الخادم للطلبات الداخلية من ONLYOFFICE Docs . يجب أن يعمل العنوان الأول من Nextcloud إلى خادم المستندات، ويجب أن يعمل العنوان الثاني من خادم المستندات إلى Nextcloud.
في الإعداد الافتراضي الذي اقترحته مينا، يستخدم رد الاتصال http://cloud.example.comبروتوكول HTTPS ويعيد التوجيه إليه. قم بتكوين عنوان HTTPS النهائي مباشرةً، ثم تأكد من أن نظام أسماء النطاقات (DNS) وقواعد جدار الحماية وشهادة الثقة تسمح لخادم المستندات بالوصول إليه. يجب أن يمرر الخادم الوكيل رد الاتصال إلى Nextcloud دون إعادة توجيه مخططه أو اسم مضيفه أو مساره. اسم المضيف المذكور في المثال ليس مخصصًا للتثبيتات الحقيقية.
يمكن لفحص الاتصال في ONLYOFFICE المساعدة في التحقق من عناوين الخدمة المُكوّنة:
sudo -u www-data php occ onlyoffice:documentserver --checkقم بتشغيله من مجلد Nextcloud باستخدام حساب خادم الويب المناسب. لا يُعدّ نجاح الفحص دليلاً على عمل رد الاتصال POST. كما أن طلب HEAD يدوياً أو صفحة المتصفح على نفس اسم المضيف لا يُعدّ دليلاً أيضاً.
إذا وصل رد الاتصال إلى Nextcloud ولكن لم يتم تحديث الملف، فابحث في سجلات Nextcloud عن الطلب المطابق. تأكد من أن المستخدم لديه صلاحية التحرير، وأن وحدة التخزين متاحة، وأن الحساب لم يتجاوز حصته، وأن وحدة التخزين تحتوي على مساحة خالية وعدد كافٍ من العقد. إذا كانت المشكلة تؤثر على ملف مشترك، فاسأل عما إذا كان مستخدم آخر أو عميل مزامنة آخر يقوم بتعديله في الوقت نفسه، ثم اختبره بنسخة منه في مجلد خاص.
يُنسق نظام قفل الملفات في Nextcloud عمليات الكتابة؛ لذا لا تُعطّله كحل سريع. إذا أشارت السجلات إلى أخطاء في القفل أو قاعدة البيانات، فتحقق من نظام القفل الخلفي وخدمة Redis أو Valkey. لا تحذف oc_file_locksالصفوف أو تقفل الملفات، فقد يُؤدي ذلك إلى تعطيل عمليات الكتابة النشطة.
إذا نجح اختبار المجلد القياسي ولكن فشل اختبار ملف مخزن خارجيًا، فتحقق من توفر هذا المجلد ونمط المصادقة الخاص به. توضح وثائق ONLYOFFICE القيود المفروضة على بعض أنماط التخزين الخارجي؛ تجنب تغيير بيانات الاعتماد حتى تعزل المجلد المتصل.
بعد تغيير أحد الإعدادات، قم بإجراء تعديل منفصل في مستند تجريبي صغير، وانتظر حتى يكتمل الحفظ، ثم أغلقه وأعد فتحه من Nextcloud. تأكد من بقاء التعديل وأن سجلات النظام لا تُظهر أي إعادة توجيه أو فشل في الاتصال أو استثناء في التخزين.
إذا نجح الاختبار ولكن النسخة الأصلية لا تزال تفشل، فتحقق من أذوناتها، أو نقطة ربطها الخارجية، أو التعديلات المتزامنة. إذا فشلت جميع عمليات الاستدعاء، فاحتفظ بالنسخة المحلية وقم بتصعيد الأمر مع الطابع الزمني، وحالة HTTP، والإصدارات، والسجلات المُنقّحة. احذف رموز JWT، وملفات تعريف الارتباط، وعناوين URL المُوقّعة، وأسماء الملفات الشخصية.
تتناول هذه الخطوات الأسباب الشائعة لخطأ الحفظ، وهي: الاستدعاء، والتوجيه، والتخزين. ويعتمد الحل الأمثل على نقطة الفشل الأولى في السجلات؛ إذ لا يكفي فحص الاتصال الناجح وحده للتأكد من سلامة عملية الحفظ بالكامل.
تمت مراجعة الوثائق في 9 أكتوبر 2026. قد تختلف حقول الموصل ووجهات السجلات حسب إصدار التطبيق المثبت وتكوين النشر.
قم بتشخيص حالات فشل حفظ ملفات ONLYOFFICE عن طريق التحقق من مسار رد الاتصال في Nextcloud، وعمليات إعادة توجيه الوكيل، وسجلات التخزين، ثم تحقق من استمرار الملف الذي تم تعديله.
ابحث عن سبب تعطل ذاكرة ONLYOFFICE، وتحقق من حدود Docker، وقم بتحديد حجم ذاكرة الوصول العشوائي VPS بشكل صحيح، وأضف مساحة التبديل بأمان، وتحقق من فتح المستندات وحفظها.
افصل بين مشاكل التنزيل من المتصفح وأخطاء التحويل من جانب الخادم، واستخدم سجل التحقق أو فحص الوصول المناسبين لجعل عملية تصدير ملف PDF تعمل.
قم بمطابقة سر JWT المستخدم بواسطة ONLYOFFICE Docs و Nextcloud، وقم بتطبيقه بأمان على عمليات تثبيت Docker أو Linux، وتحقق من الاتصال دون إضعاف المصادقة.
قم بتثبيت ONLYOFFICE Workspace Community على Ubuntu 24.04 باستخدام برنامج Docker الرسمي، وتحقق من متطلبات الخادم، وتخطى البريد إذا لزم الأمر، وتحقق من البوابة بأمان.
قم بتكوين أسرار JWT المطابقة لـ ONLYOFFICE Docs وموصلها، مع خطوات آمنة لحزم Linux وعمليات نشر Docker والتحقق.
أضف شعار شركتك وألوان واجهة المستخدم إلى محرر ONLYOFFICE Docs المدمج باستخدام ملف سمة مخصص وإعدادات المحرر. راجع حدود التحرير وفحوصات النشر.
تتبع التعديلات في برنامج Writer، واحتفظ بمصدر ODT قابل للتحرير، وتحقق من ملف DOCX المُصدّر في برنامج Word قبل مشاركته.
اتبع إجراء SP7 الخاص بشركة SUSE لتمكين وضع FIPS، وأعد التشغيل بأمان، وتحقق من السياسة النشطة، وتحقق مما إذا كانت متطلبات الامتثال الخاصة بك تتطلب وحدات تم التحقق من صحتها.
قم بمقارنة YaST و cryptsetup لوحدة تخزين بيانات SLES مشفرة جديدة، واختر LUKS1 أو LUKS2، وتحقق من سلوك إلغاء القفل والتركيب بأمان.
