تفترض بعض أدوات تثبيت Docker الخاصة بالمورّدين أنها تستطيع إنشاء أدلة التطبيقات مباشرةً ضمن نظام ملفات الجذر في Linux. ويتعارض ذلك مع تصميم ZimaOS الشبيه بالأجهزة المخصّصة عندما تُصرّ أداة التثبيت على مسار مضيف مثل /app.
توصل هذا النقاش الذي بدأ في يناير 2026 في النهاية إلى حل أفضل من جعل نظام ملفات جذر ZimaOS قابلاً للكتابة: ضبط ONLYOFFICE Workspace لاستخدام تخزين دائم ضمن /media، وتحديد نوع تثبيت Community صراحةً.
لا تجعل جذر ZimaOS قابلاً للكتابة لمجرد تلبية متطلبات أداة التثبيت
كان النشر الأصلي يتكوّن من حاويات متعددة لقاعدة البيانات والبحث والمستندات والبريد والاتصالات وخدمات الإدارة. توقعت أداة المورّد وجود /app، بينما أراد المستخدم تخزين البيانات الفعلية على محرك بيانات ZimaOS كبير.
وجّه المجتمع النقاش بشكل صحيح بعيدًا عن تعديل نظام ملفات ZimaOS الأساسي بشكل دائم. فقد تستبدل تحديثات نظام التشغيل المخصّصة للأجهزة التغييرات غير المدعومة ضمن نظام ملفات الجذر أو تبطل مفعولها.
كان لدى أداة تثبيت المورّد دليل أساسي قابل للتهيئة
بعد فحص نصوص أداة التثبيت، علم المستخدم أن موقع التخزين لم يكن محددًا بشكل ثابت فعليًا. إذ كان بالإمكان تغيير الدليل الأساسي من المسار الافتراضي على مستوى الجذر إلى موقع دائم ضمن محرك بيانات ZimaOS.
تُعد هذه بنية أكثر أمانًا، لأن الحاويات وبيانات التطبيقات تبقى على وحدة تخزين قابلة للكتابة، بينما تظل صورة نظام ZimaOS مُدارة من قِبل نظام التشغيل.
حدّد نوع تثبيت Community صراحةً
أفاد المستخدم لاحقًا بوجود مشكلة ثانية: فبعد تغيير الدليل الأساسي، كان بإمكان أداة التثبيت الرجوع إلى إصدار Enterprise. وبعد التعاون مع مورّد البرنامج، تأكدوا من أن نشر Community يتطلب تحديد نوع التثبيت المناسب.
ولا تزال تعليمات ONLYOFFICE الحالية تعرض نوعَي تثبيت منفصلين، Community وEnterprise. وقبل تعديل نص برمجي قديم تم تنزيله، تحقق من معلمات النص البرمجي التي تحدد Workspace Community في أداة التثبيت الحالية.
استخدم نص ONLYOFFICE الحالي، وليس اسم الملف التاريخي في المنتدى
أشارت إجابة المنتدى في عام 2026 إلى اسم ملف قديم لأداة التثبيت. أما تعليمات ONLYOFFICE Workspace الحالية فتنشر الآن الملف workspace-install.sh لعمليات النشر عبر Docker، وتوثّق المعلمات المدعومة بشكل منفصل.
ترد العملية الحالية من المصدر الأساسي ومتطلبات النظام في مسار تثبيت Workspace Community الحالي عبر Docker والمحافظ عليه.
يظل Docker Compose بديلًا أكثر شفافية
ناقش المجتمع أيضًا نشر الحزمة باستخدام Compose بدلًا من الاعتماد على نص تثبيت كبير. ويجعل هذا النهج مراجعة إصدارات الصور ومسارات وحدات التخزين والشبكات والتخزين الدائم أسهل قبل النشر.
إذا استوردت حزمة متعددة الحاويات إلى ZimaOS الحالي، فتنتمي إعدادات التشغيل القياسية إلى Docker Compose. ويساعد الشرح الحالي حول كيفية تعامل ZimaOS مع إعدادات Docker Compose على إبقاء مسارات تخزين المورّد منفصلة عن البيانات الوصفية لتطبيقات ZimaOS.
الأسئلة الشائعة حول ONLYOFFICE على ZimaOS
هل أحتاج إلى جعل نظام ملفات جذر ZimaOS قابلًا للكتابة؟
لم يتطلب أي حل في النقاش النهائي ذلك. كان النهج الأفضل هو وضع الدليل الأساسي للمورّد على وحدة تخزين دائمة قابلة للكتابة.
هل كان /app إلزاميًا فعلًا؟
أكد مورّد المستخدم في النهاية إمكانية تغيير الدليل الأساسي لأداة التثبيت، ولذلك لم يكن المضيف بحاجة إلى تخزين التطبيق ضمن مسار /app الموجود على مستوى الجذر.
لماذا ظهر الإصدار الخاطئ؟
اكتشف المستخدم أن تغيير الدليل الأساسي كشف سلوكًا في أداة التثبيت يؤدي افتراضيًا إلى اختيار Enterprise. وأفاد بأن تحديد نوع تثبيت Community صراحةً حل هذه المشكلة.
هل ينبغي أن أنسخ أوامر المنتدى لعام 2026 كما هي؟
لا. ينبغي التحقق من اسم ملف أداة التثبيت الحالية في ONLYOFFICE ومعلماتها بالاستناد إلى تعليماتها المُحدّثة قبل النشر.
