فشل تثبيت Paperless-ngx من المصدر في وقت متأخر من عملية متجر تطبيقات ZimaOS، إذ ظهر أولًا خطأ عدم التفويض عند سحب صورة Tika من سجل حاويات GitHub، ثم ظهر لاحقًا فشل DNS خاص بمرآة سجل. ويجعل هذا المزيج الموضوع أكثر تعقيدًا من مجرد القول إن «Paperless معطّل»: فقد كان المكوّن المتعطّل مسار خدمة/صورة Tika اختياريًا، كما تغيّرت نقطة نهاية السجل بين المحاولتين.
لم يصل النقاش العام إلى إصلاح مؤكد لـ ZimaOS App Store. غيّر أحد المستخدمين صورة Tika إلى صورة Apache ووصل التثبيت إلى 100%، لكن المكدس لم يعمل بعد ذلك. وتوفر وثائق Paperless-ngx الحالية مسارًا أوضح: استخدام قوالب Docker Compose المُصانة، وتفعيل متغير Tika/Gotenberg فقط عند الحاجة إلى تنسيقات تلك المستندات.
كان الفشل الأول خطأ تفويض من GHCR
حدث الخطأ الأصلي عند نحو 80%:
Head "https://ghcr.io/v2/paperless-ngx/tika/manifests/2.9.1-minimal": unauthorizedلم يؤدِّ حذف صور Docker المحلية وإعادة التثبيت إلى تغيير النتيجة، ما يستبعد إلى حد كبير أن تكون المشكلة مجرد صورة محلية قديمة.
فشلت المحاولة التالية في حل اسم النطاق عبر DNS
بعد يومين، تغيّر الخطأ إلى فشل في البحث عبر DNS عن اسم مضيف لمرآة سجل. لذلك اقترح أحد أفراد المجتمع التحقق من حل الأسماء، واتصال HTTPS الأساسي، وفلترة DNS، وسلوك VPN/الوكيل، وتجربة سحب الصورة يدويًا.
كانت هذه إجراءات تشخيصية اقترحها المجتمع، وليست سببًا جذريًا أكدته IceWhale.
Tika اختيارية في Paperless-ngx الحالية
توضح وثائق Paperless-ngx الحالية أن Tika وGotenberg خدمتان اختياريتان تُستخدمان مع مستندات Office مثل DOC/XLSX/ODT ومع تحليل رسائل البريد الإلكتروني. وإذا لم تكن هذه التنسيقات مطلوبة، فلا حاجة إلى تمكين Tika أصلًا.
أما إذا كانت مطلوبة، فاستخدم متغير Compose المُصان الذي يتضمن Tika وGotenberg بدلًا من مرجع صورة قديم في متجر التطبيقات.
يُعد Docker Compose الحالي من المصدر أفضل نقطة انطلاق
يوصي دليل إعداد Paperless-ngx الحالي باستخدام Docker لمعظم المستخدمين، ويوفر ملفات Compose مُصانة. ويوصى في عمليات التثبيت الجديدة باستخدام PostgreSQL، كما تتوفر قوالب تدعم Tika بشكل منفصل.
استخدم نموذج تثبيت Paperless-ngx الحالي باستخدام Docker Compose إذا كانت حزمة متجر تطبيقات ZimaOS قديمة أو تشير إلى صورة مساعدة غير متاحة.
قد لا يكفي تغيير صورة Tika وحدها
استبدل أحد المشاركين صورة Tika بـ apache/tika:latest. ووصل التثبيت إلى 100%، لكن التطبيق ظل يفشل بعد بدء التشغيل.
وتهم هذه النتيجة السلبية لأن Paperless يحتاج إلى توافق نقطة نهاية الخدمة، ومفتاح الميزة، وتكامل Gotenberg مع إعداد Compose. فاستبدال صورة الحاوية ليس بالضرورة ترحيلًا كاملًا للمكدس.
ضع بيانات Paperless الدائمة على مساحة التخزين الرئيسية
يمكن أن يتوسع Paperless بسبب المستندات المستهلكة، والصور المصغرة، وبيانات OCR، وفهارس البحث، وقاعدة البيانات. ويوصي ZimaOS حاليًا بنقل بيانات التطبيقات بعيدًا عن محرك النظام قبل تثبيت التطبيقات التي تستهلك مساحة كبيرة.
ويُعد نموذج مسارات تخزين التطبيقات الحالي في ZimaOS مهمًا خصوصًا لـ Paperless، لأن حجم بياناته قد يتجاوز بكثير حجم صورة Docker.
تُعد الأذونات مهمة لمجلد الاستهلاك
تتيح وثائق Paperless-ngx الحالية المتغيرين USERMAP_UID وUSERMAP_GID لكي تتمكن الحاوية من الكتابة إلى المجلدات المرتبطة من المضيف. وإذا تم تثبيت المكدس لكنه لا يستطيع استيعاب المستندات، فتحقق من هذه القيم ومن أذونات مجلد المضيف بدلًا من العودة إلى استكشاف مشكلات السجل وإصلاحها.
لا تعتبر اسم مضيف مرآة السجل هو تطبيق Paperless
أشار خطأ المصدر الثاني إلى اسم مضيف يشبه أسماء المرايا بدلًا من نقطة النهاية الرئيسية ghcr.io. وهذا التمييز مهم: فقد تكون حزمة التطبيق صالحة تمامًا، بينما تكون مرآة الصورة المُهيأة أو خادم DNS أو مسار السجل الإقليمي غير متاح.
إذا نجح السحب اليدوي من السجل الأصلي، لكن ظل متجر التطبيقات يحاول استخدام مرآة معطّلة، فالمشكلة تكمن في طبقة الحزمة أو توجيه السجل، لا في Paperless نفسه.
ميّز بين فشل سحب الصورة وفشل بدء تشغيل الحاوية
لم تكتمل محاولة المصدر الأولى في سحب جميع الصور المطلوبة. أما تجربة Apache Tika اللاحقة فوصلت إلى تثبيت بنسبة 100%، لكنها فشلت بعد البدء. وهذه مرحلتان مختلفتان من الفشل وتتطلبان أدلة مختلفة.
- مرحلة السحب: مصادقة السجل، وDNS، وتوفر المرآة، ووسم الصورة.
- مرحلة بدء التشغيل: متغيرات البيئة، والاتصال بقاعدة البيانات، ونقاط نهاية Tika/Gotenberg، ووحدات التخزين، والأذونات، وفحوصات السلامة.
انسخ نسخة احتياطية من مثيل Paperless العامل قبل استبدال مكدس متجر التطبيقات
إذا كان Paperless قيد الاستخدام بالفعل، فلا تبدّل قوالب Compose لمجرد إصلاح خدمة مساعدة دون حماية المستندات وقاعدة البيانات أولًا. ويتضمن Paperless الحالي من المصدر أداة تصدير مخصصة للنسخ الاحتياطي والترحيل.
أما في التثبيت الجديد، فسيكون البدء من ملف Compose المُصان من المصدر أسهل؛ وفي التثبيت الحالي، احفظ مسارات قاعدة البيانات والوسائط الحالية قبل إعادة كتابة المكدس.
الأسئلة الشائعة حول تثبيت Paperless-ngx
هل ثبت بشكل قاطع أن فشل عام 2025 كان مشكلة DNS؟
لا. فقد أظهر النقاش أخطاء تفويض وأخطاء DNS معًا، ولم يُنشر أي تشخيص نهائي رسمي.
هل Tika مطلوبة لكل عملية تثبيت لـ Paperless-ngx؟
لا. فهي اختيارية، وتلزم أساسًا لمستندات Office وتحليل رسائل البريد الإلكتروني.
هل أدى التبديل إلى apache/tika إلى حل الحالة المصدرية بالكامل؟
لا. فقد وصل أحد المستخدمين إلى تثبيت بنسبة 100%، لكن التطبيق لم يعمل بعد ذلك.
