يحتوي هذا المصدر على عدة أعطال متشابهة ظاهريًا في Immich، لكن لا يوجد حل واحد شامل لها. استعاد تطبيق Immich المعطّل لدى صاحب المنشور الأصلي عمله فورًا بعد تنفيذ sudo systemctl restart docker. جرّب مستخدم آخر الأمر نفسه، لكنه ظل غير قادر على تشغيل Immich. وأظهر الخطأ اللاحق لديه أن منفذ المضيف 2283 كان مستخدمًا بالفعل، وهي مشكلة تختلف عن توقف خدمة Docker.
وهذا هو الدرس الأساسي: بعد تحديث نظام التشغيل، حدّد أولًا ما إذا كانت خدمة Docker نفسها غير سليمة، أو أن مشروع Compose واحدًا فقط يواجه مشكلة، أو أن حاوية قديمة/مكررة تستحوذ بالفعل على المنفذ الذي يحتاجه Immich.
تحقق أولًا من صحة خدمة Docker
كانت توصية 777-Spider الأولى هي التحقق من أن Docker يعمل بصورة صحيحة. ثم أعاد صاحب المنشور الأصلي تشغيل Docker وأفاد بأن كل شيء عاد إلى العمل.
تؤثر إعادة تشغيل Docker في جميع الحاويات على المضيف، لذا نفّذها عمدًا وتوقّع إعادة تشغيل التطبيقات الأخرى.
لم تكن إعادة تشغيل Docker حلًا شاملًا لمشكلة Immich
أفاد Chris بأن إعادة تشغيل Docker نفسها ساعدت التطبيقات الأخرى، لكنها لم تُعد Immich إلى العمل. وهذا دليل مباشر على عدم اعتبار systemctl restart docker حلًا مضمونًا.
أظهر أحد أخطاء المصدر صراحةً أن المنفذ 2283 مستخدم بالفعل
للتعامل مع الحالة الحالية، حدّد الحاوية أو العملية التي تستحوذ على المنفذ 2283 قبل حذف أي شيء أو إعادة إنشائه. فقد تترك حاويات Immich قديمة أو مشروع Compose أُعيد إنشاؤه جزئيًا منفذًا مشغولًا.
فشل تشغيل تطبيق Compose هو خطأ في حزمة التطبيق
إذا كان Docker يشغّل Paperless أو التطبيقات الأخرى بصورة طبيعية، بينما يفشل Immich مع خطأ في Compose، فتحقق من حالات خدمات Immich وسجلاتها وتعريف Compose الحالي بدلًا من إعادة تثبيت نظام التشغيل بالكامل.
ساعدت إعادة التثبيت مستخدمًا واحدًا، لكنها كلّفته وقتًا وإعادة نسخ البيانات
أعاد Chris تثبيت Immich في النهاية ونسخ الصور مرة أخرى. وقد حذّر صراحةً بشأن النسخ الاحتياطية. كان ذلك قرارًا أخيرًا من مستخدم، وليس حلًا مؤكدًا للجميع.
احتفظ ببيانات تطبيق Immich وقاعدة البيانات قبل إعادة التثبيت
لا تقتصر حالة Immich على مجلد الصور. احتفظ بقاعدة البيانات، وإعدادات التطبيق، ومسارات المكتبة قبل حذف الحاويات أو وحدات التخزين. يحتفظ ZimaOS الحالي ببيانات مهمة للتطبيق خارج الحاويات القابلة للاستبدال.
استخدم نموذج بيانات التطبيق الدائمة الحالي في ZimaOS.
لا تعتبر هذه المشكلة تراجعًا حاليًا في Immich 1.7.1
يرجع المصدر تحديدًا إلى ZimaOS 1.5.4 وإصدار أقدم من Immich. أما ZimaOS الحالي وImmich v3 فأحدث بكثير، لذا أعد إنتاج الخطأ الحالي بدقة قبل تطبيق حل بديل في عام 2026.
قد تكون إعادة Immich إلى إصدار أقدم غير آمنة بعد ترحيل قاعدة البيانات
ذكر أحد مستخدمي المصدر أنه عاد إلى إصدار سابق من Immich. قد تؤدي ترقيات الإصدارات الرئيسية الحالية إلى ترحيل حالة قاعدة البيانات والتطبيق، لذلك يجب أن تستند إمكانية الرجوع إلى إرشادات إصدار Immich المطابق، لا إلى تغيير وسم الصورة إلى إصدار أقدم فحسب.
يتطلب تعارض المنافذ تحديد المستمع الحالي
يذكر خطأ المصدر صراحةً أن Docker لم يتمكن من ربط منفذ المضيف 2283 لأنه مستخدم بالفعل. وقد يحدث ذلك عند استمرار تشغيل حاوية Immich قديمة، أو استخدام حزمة ثانية للمنفذ نفسه، أو تعيين خدمة أخرى إليه.
قبل حذف أي شيء، حدّد الحاوية أو المستمع الحالي الذي يستخدم المنفذ وقرّر أي حزمة ينبغي أن تملكه.
قد تكون أيقونة التطبيق الرمادية عرضًا لحالة Docker، لا لفقدان بيانات Immich
بالنسبة إلى صاحب المنشور الأصلي، أدت إعادة تشغيل Docker إلى استعادة جميع التطبيقات. وهذا يعني أن حالة Immich الرمادية لديه كانت ناتجة عن بيئة تشغيل الحاويات، ولم تكن دليلًا على حذف قاعدة بيانات الصور أو المكتبة.
لكن مشاركًا آخر لم يستعد Immich بإعادة التشغيل نفسها، ما يوضح أن عرض واجهة المستخدم وحده لا يكفي لتشخيص السبب الجذري.
اقرأ خطأ Compose قبل إعادة التثبيت
عبارة «فشل تشغيل تطبيق Compose» هي خطأ عام. أما الدليل المفيد فهو رسالة الخدمة أو الحاوية الأساسية: تعارض منفذ، أو وحدة تخزين مفقودة، أو فشل في صحة قاعدة البيانات، أو مشكلة في سحب الصورة، أو ملف YAML غير صالح، أو مشكلة في الأذونات.
احتفظ بالسجلات التي يظهر فيها الفشل قبل إعادة إنشاء الحزمة؛ فقد تؤدي إعادة التثبيت إلى محو الأدلة.
يجعل Immich v3 الحالي الرجوع العشوائي إلى إصدار أقدم أكثر خطورة
تقدّم Immich منذ ذلك الحين عبر تغييرات رئيسية في المخطط والنشر. وقد لا تكون قاعدة بيانات حديثة من v3 آمنة للتشغيل باستخدام صورة قديمة عشوائية، لمجرد أن مستخدمًا في عام 2026 عاد سابقًا إلى إصدار v1.x.
اتبع إرشادات Immich الحالية بشأن الترحيل والرجوع إلى إصدار أقدم، واحتفظ بنسخ احتياطية موثوقة من قاعدة البيانات والمكتبة قبل تغييرات الإصدارات الرئيسية.
إذا كانت إعادة التثبيت ضرورية، فاحتفظ بالمسارات الدائمة أولًا
سجّل مكتبة الصور، وبيانات PostgreSQL، والإعدادات، ومسارات التعلم الآلي/ذاكرة التخزين المؤقت، وتعيينات وحدات التخزين الحالية. إن إزالة الحاويات القابلة للاستبدال تختلف تمامًا عن حذف مجلدات المضيف الدائمة.
ينبغي لإعادة التثبيت النظيفة والناجحة أن تعيد ربط البيانات الدائمة المقصودة أو تستعيدها عبر مسار نسخ احتياطي مدعوم، لا أن تتطلب إعادة نسخ مكتبة الصور الوحيدة من البداية.
الأسئلة الشائعة حول تعطل Immich 1.5.4
هل أدت إعادة تشغيل Docker إلى إصلاح Immich لدى صاحب المنشور الأصلي؟
نعم.
هل أصلحت المشكلة لدى كل المستخدمين في النقاش؟
لا. ظل Immich لدى مستخدم آخر متعطلًا، ثم ظهر لاحقًا تعارض في المنفذ 2283.
هل ينبغي للمستخدمين الحاليين إعادة تثبيت Immich فورًا؟
لا. حدّد أولًا صحة خدمة Docker، وحالة Compose، والجهة التي تستخدم المنفذ، والبيانات الدائمة.
