لا يثبت المصدر أن «ZimaOS 1.5.0 لا يمكنه تشغيل Nextcloud AIO». بل يثبت حالة تراجع أضيق نطاقًا: مكدس AIO واحد كان يعمل على الإصدار 1.4.1 وتوقف عن العمل بعد الإصدار 1.5.0، مع إبلاغ حاوية Apache مرارًا بأنها لا تستطيع الكتابة إلى /mnt/data. واجه مستخدم آخر مشكلات إضافية في مقبس Docker والتحقق من النطاق وتعارض المنافذ، واختار بدلًا من ذلك مكدس Nextcloud Compose العادي.
توفر وثائق Nextcloud AIO الحالية مسارًا رسميًا للوكيل العكسي لم يعد يتطلب نشر Apache الداخلي لـ AIO مباشرةً على المنفذ 80. ويستخدم واجهة AIO على المنفذ 8080 ويسمح بـ APACHE_PORT ليُنقل إلى منفذ مختلف على المضيف، مثل 11000. وهذا مرجع حالي أفضل من تصعيد الامتيازات أو تغيير الأذونات يدويًا حتى يبدأ المكدس مصادفةً.
كان فشل المصدر داخل AIO تحديدًا
قال صاحب المنشور الأصلي:
- كان AIO يعمل على ZimaOS 1.4.1؛
- بعد الإصدار 1.5.0، بدأ المكدس إلى حد كبير؛
- فشلت حاوية Apache باستمرار في الكتابة إلى
/mnt/data; -
privileged: trueلم يحل المشكلة؛ - لم يؤدِّ إنشاء وحدة تخزين mastercontainer الخاصة بـ AIO مسبقًا إلى حل المشكلة.
وهذا دليل على عدم اعتبار «إضافة الامتيازات فقط» حلًا دائمًا.
واجه مستخدم آخر عدة طبقات مختلفة من AIO
أفاد gelbuilding أولًا بوجود مشكلة في مقبس Docker، ثم /mnt/data الأذونات، ثم ظهرت مشكلة التحقق من النطاق. كما اشتبهوا في أن استخدام بوابة ZimaOS للمنفذ 80 غير متوافق مع تصميم AIO لديهم.
كانت تلك ملاحظات من المجتمع، وليست تحليلًا للسبب الجذري من IceWhale.
يدعم AIO الحالي إعدادًا مخصصًا للوكيل العكسي
توصي إرشادات Nextcloud AIO الحالية بما يلي:
- انشر واجهة إدارة AIO على المنفذ 8080؛
- اضبط
APACHE_PORTمثل 11000؛ - وجّه الوكيل العكسي أو النفق إلى منفذ Apache ذلك؛
- اربط مقبس Docker للقراءة فقط داخل mastercontainer؛
- أبقِ المطلوب
nextcloud_aio_mastercontainerوحدة تخزين.
راجع نموذج Nextcloud AIO الحالي للوكيل العكسي.
نفق Cloudflare لا يلغي متطلبات AIO للمنافذ الداخلية والأذونات
تتجنب النفق فتح المنفذين العامين 80 و443 على جهاز التوجيه، لكن حاويات AIO تظل بحاجة إلى مسار داخلي صالح بين mastercontainer وApache ومقبس Docker وتخزين البيانات والنفق/الوكيل العكسي.
إذا لم يتم استيفاء متطلبات AIO الخاصة بالتحقق من النطاق وتوقعات الوكيل، فإن «تولّي Cloudflare لمهمة HTTPS» لا يجعل مكدس AIO سليمًا تلقائيًا.
لا تغيّر أذونات بيانات AIO بشكل تكراري باستخدام chmod قبل فهم الحاوية التي تملكها
/mnt/data في حاوية شقيقة لـ AIO، يُعد ذلك جزءًا من نموذج التخزين المُدار في AIO. وقد تؤدي التغييرات الواسعة في أذونات المضيف إلى اختفاء الخطأ، لكنها قد تُضعف الملكية أو تتسبب في فشل الترقية لاحقًا.
افحص إعدادات وحدة تخزين AIO ومجلد البيانات الفعلية، واتبع إرشادات التخزين الأصلية لـ AIO أولًا.
اختار مستخدم المصدر Compose القياسي لـ Nextcloud كبديل عملي
ذكر gelbuilding أن مكدس Nextcloud عاديًا تحت /DATA/AppData/nextcloud عمل بسلاسة على منفذ متاح، وكان لا يزال من الممكن نشره عبر Cloudflare Tunnel.
هذه بنية صالحة إذا كان المستخدم يفضّل التحكم الصريح في حاويات Nextcloud وقاعدة البيانات وRedis بدلًا من الحاويات الشقيقة التي تديرها الحاوية الرئيسية لـ AIO.
لا ينبغي افتراض حدوث فشل الإصدار 1.5.0 على ZimaOS الحالي
إن ZimaOS الحالي أحدث بكثير من إصدار أكتوبر 2025 الوارد في المصدر. وقبل إعادة تطبيق الحلول الالتفافية القديمة، اختبر Compose الحالي الخاص بـ Nextcloud/AIO على ZimaOS الحالي واجمع سجلات الحاويات الدقيقة.
يحتاج AIO إلى الوصول إلى مقبس Docker وفقًا لنموذج إدارته
تنشئ الحاوية الرئيسية حاويات شقيقة وتديرها. لذلك توصي التعليمات الحالية للمصدر الأصلي بتركيب /var/run/docker.sock للقراءة فقط داخل الحاوية الرئيسية. إذا كان المقبس غائبًا أو يتعذر الوصول إليه، فلن يتمكن AIO من تنسيق بقية مكدسه بشكل صحيح.
لا توسّع نطاق الوصول إلى المقبس ليشمل أوضاع كتابة غير ضرورية، ولا تكشفه للحاويات غير ذات الصلة.
حافظ على اسم وحدة تخزين حاوية AIO الرئيسية والغرض منها كما هما
تستخدم أمثلة AIO الحالية وحدة التخزين المسمّاة nextcloud_aio_mastercontainer لإعدادات AIO الخاصة به. ويحذّر المصدر الأصلي من إعادة تسمية أو تغيير المكوّنات المطلوبة بشكل عشوائي، لأن منطق التحديث والإدارة يتوقع البنية الموثّقة.
يغيّر وضع الوكيل العكسي منافذ AIO التي تحتاج إلى نشر
تذكر تعليقات Compose الحالية الخاصة بـ AIO أنه يمكن إزالة منفذي المضيف 80 و8443 عند التشغيل خلف وكيل عكسي مثل Nginx أو Caddy أو Apache أو Cloudflare Tunnel، بينما تظل واجهة AIO على المنفذ 8080 ويمكن لـ Apache استخدام منفذ منفصل مُعدّ.
وهذا أدق من منح مميّزًا وضعًا للتغلب على تعارض في المنافذ.
يستخدم AIO وCompose القياسي لـ Nextcloud نموذجين تشغيليين مختلفين
يبسّط AIO عمليات الترقية والنسخ الاحتياطي والخدمات ذات الصلة، إذ يتيح للحاوية الرئيسية إدارة المكدس. أما نشر Compose القياسي فيمنح مسؤول NAS تحكمًا مباشرًا في كل خدمة ومسار وقرار متعلق بالوكيل العكسي. اختار مستخدم المصدر النموذج الثاني بعد مواجهة مشكلات مع AIO.
لا يُعد أي من الخيارين «أكثر توافقًا» بطبيعته إلى الأبد؛ اختر النموذج الذي تستطيع صيانته والتزم بوثائقه الأصلية باستمرار.
الأسئلة الشائعة حول Nextcloud AIO
هل أثبت المصدر أن ZimaOS 1.5.0 حظر Nextcloud AIO على مستوى النظام؟
لا. توثّق هذه الحالة حالتي فشل من المجتمع من دون سبب شامل أكدته IceWhale.
هل ينبغي أن يكون الوضع المميّز أول حل؟
لا. جرّب صاحب المنشور الأصلي ذلك، واستمر فشل الكتابة في Apache.
هل يمكن لـ AIO العمل خلف وكيل عكسي من دون امتلاك المنفذ 80 على المضيف؟
نعم. توفّر وثائق AIO الحالية APACHE_PORTسير عمل وكيل عكسي قائم على .
