يُعد هذا النقاش من يناير 2026 حول Nextcloud/MariaDB من أوضح الأمثلة على سبب ضرورة تشخيص شبكة الحاويات طبقةً تلو الأخرى. ثبّت المستخدم تطبيقي Nextcloud وMariaDB بشكل منفصل، ووصلت MariaDB إلى حالة سليمة «جاهزة للاتصالات»، لكن Nextcloud فشل أثناء الإعداد الأولي بسبب تعذر على getaddrinfo العثور على mariadbلم يؤدِّ إعادة تثبيت التطبيقين وحذف مجلداتهما إلى تغيير الخطأ.
حدث الاختراق عندما اختبر المجتمع عنوان IP الفعلي لحاوية MariaDB في Docker. بدأ Nextcloud التثبيت فورًا. وأثبت ذلك أن خادم قاعدة البيانات وبيانات الاعتماد ومسار TCP كانت تعمل أساسًا، بينما كان اسم المضيف mariadb لم يكن يُحل من داخل حاوية Nextcloud.
أراد المستخدم قاعدة بيانات MariaDB منفصلة لـ Nextcloud
ناقشت الردود المبكرة بدائل مثل صورة Nextcloud متكاملة تتضمن PostgreSQL، أو إنشاء قاعدة بيانات ومستخدم MariaDB يدويًا عبر phpMyAdmin. لم تكن تلك الاقتراحات هي المشكلة النهائية. فقد كانت MariaDB تعمل لدى المستخدم بالفعل، وكان المطلوب هو تمكين Nextcloud من الوصول إليها.
أظهرت سجلات MariaDB أن قاعدة البيانات كانت تعمل بشكل سليم
نصح المجتمع، بحق، بعدم الاستمرار في تغيير كلمات مرور MariaDB ومتغيرات البيئة بعد تهيئة قاعدة البيانات بالفعل. إذ تطبق العديد من صور قواعد البيانات متغيرات التهيئة فقط عند إنشاء دليل البيانات لأول مرة.
يجب أن يكون مضيف قاعدة البيانات قابلاً للوصول من داخل Nextcloud
أثناء الإعداد الأولي لـ Nextcloud، يمكن أن يحتوي حقل مضيف قاعدة البيانات على اسم مضيف ومنفذ، مثل:
mariadb:3306لا يعمل ذلك إلا عندما توفر شبكة Docker تحليل الأسماء لـ mariadb من حاوية Nextcloud.
تعذر على getaddrinfo العثور على mariadb — هل هذا خطأ في الحاوية متعلق بنظام DNS؟
كان الخطأ الأساسي هو:
php_network_getaddresses: تعذر على getaddrinfo العثور على mariadbيحدث هذا قبل أن تتمكن MariaDB من قبول اسم المستخدم وكلمة المرور أو رفضهما. فإذا تعذر تحليل الاسم إلى عنوان IP، فلن تكون بيانات اعتماد قاعدة البيانات قيد التحقق بعد.
وجود «Bridge» في التطبيقين لم يحل مشكلة تحليل الأسماء
أكد المستخدم أن التطبيقين كليهما يعرضان شبكة من نوع Bridge في ZimaOS، لكن mariadb لم تُحل المشكلة بعد. هذه نقطة مهمة في Docker: الحاويات المتصلة بشكل مستقل بجسر Docker الافتراضي لا تحصل تلقائيًا على سلوك DNS نفسه لأسماء الخدمات مثل الخدمات المتصلة بشبكة جسر يعرّفها المستخدم.
لذلك، فإن قول «كلاهما يستخدم bridge» لا يكفي لإثبات أن إحدى الحاويتين تستطيع حل اسم الحاوية الأخرى.
لم تُصلح إعادة التثبيت النظيفة سلوك الشبكة
أزال المستخدم تثبيت كلٍّ من Nextcloud وMariaDB، وحذف مجلداتهما، ثم ثبّتهما مجددًا من الصفر. وعاد خطأ اسم المضيف نفسه. وهذا الاختبار السلبي مفيد لأنه يوضح أن المشكلة لم تكن ببساطة بيانات MariaDB قديمة أو كلمة مرور غير صحيحة لمرة واحدة.
كان تحذير الوصول المحلي في Nextcloud مشكلة منفصلة
عثر المستخدم على اقتراح عبر الإنترنت لتمكين allow_local_remote_serversأدى تطبيق ذلك الإعداد أثناء الإعداد الأولي إلى توقف Nextcloud عن التشغيل بشكل صحيح. وأوضح المجتمع أن هذا الخيار يعالج قاعدة أمان مختلفة في Nextcloud، ولم يُصلح حل أسماء Docker.
انتقل مجتمع المستخدمين بعد ذلك إلى اختبارات مباشرة لشبكة Docker
طلب المُجيب إجراء الفحوصات التالية:
- ما إذا كانت كلتا الحاويتين قيد التشغيل؛
- وضع الشبكة الفعلي الذي أبلغ عنه Docker؛
- ما إذا كان Nextcloud يستطيع حل اسم
mariadb; - عنوان Docker IP الحالي لحاوية MariaDB.
وهذا هو التصعيد الصحيح بعد أن تتوقف لقطات الإعداد عن تفسير السلوك: اختبر الاتصال من مساحة أسماء الشبكة نفسها التي يعمل فيها Nextcloud.
استخدام عنوان IP لحاوية MariaDB أتاح تثبيت Nextcloud
كان الاختبار الحاسم هو استبدال mariadb:3306 مؤقتًا باستخدام عنوان Docker IP والمنفذ الخاصين بحاوية MariaDB. وردّ المستخدم في المصدر بأن Nextcloud بدأ التثبيت حينها.
لخّص المُجيب النتيجة بوضوح:
-
mariadb:3306فشل؛ - وقد عمل عنوان Docker IP المباشر على المنفذ 3306 فورًا.
وهذا دليل قوي على وجود مشكلة في حل اسم الحاوية.
عنوان IP مباشر للحاوية هو حل بديل صالح للتشخيص
يثبت استخدام عنوان IP إمكانية الوصول إلى قاعدة البيانات، ويسمح بمتابعة التثبيت. وفي الحالة المصدر، كان ذلك حلًا بديلًا فعالًا.
لكن عناوين IP المعيّنة تلقائيًا للحاويات قد تتغير عند إعادة إنشاء حاوية أو إزالتها أو إرفاقها بشبكة مختلفة. ويكون الاعتماد الدائم على 172.17.x.x قد يتعطل لاحقًا من دون إجراء أي تغيير في إعدادات Nextcloud أو MariaDB.
شبكة Docker يعرّفها المستخدم هي تصميم أفضل على المدى الطويل
تتمثل البنية الأكثر موثوقية في إرفاق Nextcloud وMariaDB بشبكة Docker واحدة يعرّفها المستخدم، واستخدام اسم خدمة أو حاوية مستقر لمضيف قاعدة البيانات. يوفر Docker نظام DNS مضمّنًا على الشبكات التي يعرّفها المستخدم لهذا الغرض تحديدًا.
يُسهّل تحرير YAML الأصلي في ZimaOS حاليًا هذا النوع من تعريف الشبكات أكثر مما كان عليه عند إنشاء سلسلة النقاش الأصلية. استخدم نموذج إعداد Compose الحالي في ZimaOS عند إنشاء شبكة مشتركة لـ Nextcloud وMariaDB.
الحفاظ على بيانات MariaDB بعناية
إذا كانت MariaDB تحتوي بالفعل على قاعدة بيانات Nextcloud عاملة، فلا تحذف دليل بياناتها الدائم لمجرد تغيير شبكة Docker. يمكن تغيير عضوية الشبكة دون إعادة إنشاء محتويات قاعدة البيانات.
قبل إجراء أي ترحيل، انسخ قاعدة البيانات احتياطيًا وسجّل المستخدم الحالي، واسم قاعدة البيانات، وربط وحدة التخزين.
لا تعطل عناصر تحكم أمان Nextcloud لإصلاح DNS في Docker
تحمي إعدادات مثل النطاقات الموثوقة، والوصول إلى الخوادم المحلية والبعيدة، وإعدادات الوكيل العكسي Nextcloud على مستوى HTTP/التطبيق. ولا ينبغي تغييرها إلا عندما يتطلب خطأ Nextcloud المقابل ذلك.
A getaddrinfo ينتمي الخطأ المتعلق باسم مضيف قاعدة البيانات إلى طبقة شبكة Docker.
شجرة تشخيص أفضل
- تأكد من أن MariaDB قيد التشغيل وتستمع على المنفذ 3306.
- تأكد من وجود قاعدة البيانات المقصودة ومن معرفة بيانات اعتمادها.
- اختبر ما إذا كان بإمكان Nextcloud حل اسم مضيف قاعدة البيانات.
- إذا فشل حل اسم المضيف، فاختبر عنوان IP الخاص بحاوية قاعدة البيانات.
- إذا كان عنوان IP يعمل، فأصلح شبكة Docker بدلًا من تغيير كلمات مرور قاعدة البيانات.
- انقل الحاويتين إلى شبكة مستقرة يعرّفها المستخدم للحصول على اسم مضيف دائم.
الأسئلة الشائعة حول Nextcloud وMariaDB
هل كانت MariaDB نفسها معطلة؟
لا. أظهر السجل أنها كانت جاهزة للاتصالات.
ماذا يعني فشل getaddrinfo لـ mariadb؟
تعذر على Nextcloud حل اسم مضيف قاعدة البيانات قبل أن يصل حتى إلى مرحلة المصادقة.
ما الذي أكد التشخيص؟
أتاح استخدام عنوان IP المباشر لحاوية MariaDB عبر Docker لـ Nextcloud بدء التثبيت.
هل ينبغي أن يكون عنوان IP المباشر للحاوية هو مضيف قاعدة البيانات الدائم؟
قد ينجح ذلك، لكن إنشاء شبكة Docker مشتركة يعرّفها المستخدم مع حل مستقر لأسماء المضيفين أكثر موثوقية.
هل أدى إعادة تثبيت التطبيقين إلى حل المشكلة؟
لا. أجرى المستخدم إعادة تثبيت نظيفة للنظام، فعاد خطأ حلّ اسم المضيف نفسه.
