لم يكن الإصلاح النهائي في هذا النقاش هو «حذف .ppstorage في كل مرة». فقد عاد الملف لأن تخطيط وحدة التخزين الأساسي ظل غير صحيح. وجاء التشخيص المفيد من السجلات، بينما تمثّل التغيير الدائم في تصحيح مجلد المضيف الذي جرى ربطه بمسار Originals في PhotoPrism.
كانت رسالة السجل إشارة، وليست الإصلاح الكامل
لاحظ أحد الردود وجود علامة .ppstorage داخل /DATA/Gallery واقترح حذفها. نفّذ المستخدم ذلك، لكن PhotoPrism أعاد إنشاء الملفات واستمر في الفشل. وقد أوضح ذلك أن علاقة المسارات—وليس الملف وحده—كانت بحاجة إلى التصحيح.
يفصل PhotoPrism بين Originals وStorage
توضح مجلدات تخزين PhotoPrism الرسمية أن مجلد Storage يحتوي على الإعدادات وذاكرة التخزين المؤقت والنسخ الاحتياطية والصور المصغرة وبيانات الملفات الجانبية، ولا ينبغي عادةً تهيئته داخل Originals، إلا عند استخدام ترتيب للأسماء المخفية يدعمه PhotoPrism. وتفسر هذه القاعدة من المصدر سبب تسبب ربط تخزين التطبيق داخل شجرة صور Originals في حدوث مشكلات.
يشرح أول تطبيق Docker نموذج مسار المضيف ومسار الحاوية في ZimaOS، بينما توفر متطلبات متجر تطبيقات ZimaOS السياق الحالي على مستوى الحزمة عند وجود أكثر من قالب أو مجموعة تبعيات.
استخدم السجلات قبل تغيير قواعد البيانات أو الأذونات
يوصي دليل استكشاف أخطاء PhotoPrism عبر Docker الرسمي بفحص سجلات Docker، ويشير تحديدًا إلى أخطاء القرص والأذونات والمسارات والتخزين. وفي هذه الحالة، قدم السجل معلومات كافية لتجنب إعادة بناء MariaDB عشوائيًا أو تغيير المنافذ أو إعادة تثبيت نظام التشغيل بالكامل.
ما الذي أثبته التغيير المجتمعي الناجح
قارن المستخدم قالب BigBear بعملية الربط في متجر تطبيقات ZimaOS، وغيّر رابط Originals، ثم بدأ PhotoPrism. ويؤكد ذلك أن ربط التخزين كان العامل الحاسم في هذا التثبيت؛ لكنه لا يثبت أن كل حزمة حالية من PhotoPrism تستخدم مسار المضيف نفسه تمامًا.
الخلاصة
إذا ثبّت PhotoPrism لكنه توقف فورًا، فاقرأ السجلات قبل تغيير كل شيء دفعة واحدة. في هذه الحالة المجتمعية، أشارت مشكلة .ppstorage المتكررة إلى وجود علاقة غير صحيحة بين تخزين PhotoPrism وOriginals. وقد سمح تصحيح ربط وحدات التخزين—بدل حذف العلامة مرارًا—بتشغيل التطبيق.
