إذا ظهرت رسالة "فشل التحقق من سلامة الملفات" في ownCloud بعد الترقية، فاستخدم تقرير الملفات غير الصالحة لتحديد الملفات التي فشلت قبل إجراء أي تغييرات عليها. إعادة الفحص تُكرر عملية التحقق فقط، ولا تُعيد الملفات المفقودة، ولا تتراجع عن التعديلات المخصصة، ولا تُثبّت إصدارًا مُصحّحًا من التطبيق. بالنسبة للملفات الأساسية، قارنها بإصدار ownCloud الذي قمت بالترقية إليه. في حال وجود مشكلة في توقيع التطبيق، ابحث عن تحديث متوافق وموقّع بشكل صحيح، أو تواصل مع مطوّر التطبيق.
يعتمد الإصلاح الأمثل على نطاق التحذير. قد يكون استبدال التثبيت بالكامل أكثر أمانًا بعد ترقية جزئية أو ترقية لإصدارات مختلطة، ولكنه يتطلب وقتًا أطول للتوقف عن العمل وحفظًا دقيقًا لبيانات التكوين والمستخدم. يُعد استبدال ملف أساسي واحد مؤكد أسرع، ولكن فقط عند التأكد من أن الملف ينتمي إلى الإصدار المُثبَّت. قد يُتيح تعطيل التحقق من التوقيع استخدام تطبيق معين، ولكنه يُقلل من الحماية، ويجب أن يكون استثناءً موثقًا، وليس إصلاحًا روتينيًا.
أولاً، اكتشف ما الذي فشل
سجّل الدخول كمسؤول وافتح صفحة الإدارة. اتبع تحذير سلامة الملفات للوصول إلى قائمة الملفات غير الصالحة. في وثائق ownCloud الحالية، يُصنّف التقرير المشكلات حسب المكوّن، مثل الملفات الأساسية أو التطبيق، ويستخدم تصنيفات مثل <input type="file"> INVALID_HASHو <input type="file"> و < input type="file"> و <input type="file" FILE_MISSING> . تشير هذه التصنيفات إلى أسباب مختلفة، لذا سجّل اسم المكوّن والمسار ونوع الخطأ قبل إجراء أي تغييرات.EXTRA_FILEEXCEPTION
INVALID_HASHيعني ذلك أن محتويات الملف الحالية لا تتطابق مع قيمة التجزئة في بيانات التوقيع. تشمل التفسيرات الشائعة الترقية الجزئية، أو بقاء ملف قديم في مكانه، أو إجراء تعديل محلي.
FILE_MISSINGهذا يعني أن الملف الموقّع غير موجود. قد يكون السبب في ذلك عملية استخراج أو نشر غير مكتملة للأرشيف.
EXTRA_FILEهذا يعني أن التثبيت يحتوي على ملف غير مدرج في التوقيع. قد يكون ملفًا متبقيًا عن طريق الخطأ، أو ملفًا مخصصًا، أو إضافة محلية مشروعة تحتاج إلى مراجعة.
EXCEPTIONهذا يعني أن ownCloud لم يتمكن من التحقق من التوقيع. قد يشير التقرير إلى أن بيانات التوقيع مفقودة، أو أن الشهادة غير صالحة أو ملغاة، أو أن عملية التحقق لم تكتمل.
لا تحذف ملفًا لمجرد ظهوره كملف إضافي. تأكد من وظيفته ومن أضافه. وعلى وجه الخصوص، لا تُعدّل أبدًا ملف التطبيق signature.jsonلإخفاء التحذير؛ إذ تنص إرشادات توقيع الكود الخاصة بـ ownCloud صراحةً على عدم تعديله.
اختر عملية الإصلاح بناءً على الأدلة.
| إيجاد | الخطوة التالية المفضلة | التنازل عن ميزة ممن أجل الحصول على أخرى |
| تحتوي العديد من الملفات الأساسية على تجزئات غير صالحة أو مفقودة بعد الترقية اليدوية | قم بإنشاء نسخة جديدة من الإصدار المستهدف بالضبط واستعد الملفات الرسمية المتأثرة، أو كرر عملية الترقية اليدوية بشكل كامل. | تتطلب الترقية النظيفة جهدًا أكبر وقد تستلزم فترة توقف، لكنها تقلل من خطر ترك شجرة تعليمات برمجية مختلطة الإصدارات. |
| أحد ملفات النظام الأساسية غير صالح، وأنت تعلم أنه تم تعديله محليًا. | قارن التعديل بملف الإصدار المطابق؛ احتفظ بالتغيير المخصص خارج شجرة النواة الموقعة، وأعد تطبيقه فقط إذا كان مدعومًا. | قد يؤدي الاحتفاظ بالتغيير إلى الحفاظ على السلوك المحلي، بينما سيستمر تعديل ملفات النظام الأساسية الموقعة في الفشل في عمليات التحقق من السلامة. |
| يقوم التطبيق بالإبلاغ عن بيانات توقيع مفقودة أو غير صالحة | قم بتثبيت إصدار متوافق من مطور التطبيق أو قم بتعطيل/إزالة التطبيق إذا لم تعد بحاجة إليه | يحافظ التحديث على الوظائف؛ أما تعطيله فيتجنب تغيير كود التطبيق ولكنه قد يؤدي إلى إزالة ميزات يعتمد عليها المستخدمون |
| تم إلغاء شهادة التطبيق أو أنها غير صالحة | اطلب من مسؤول التطبيق إصدارًا متوافقًا موقّعًا حديثًا؛ لا تعيد استخدام ملفات التوقيع أو تعديلها. | قد يستغرق هذا بعض الوقت، ولكنه يحافظ على سلامة عملية التحقق من التوقيع. |
| تم تحديد ملف إضافي | تحقق من مالك الملف، والغرض منه، وما إذا كان جزءًا من عملية تخصيص قبل نقله من مجلد التثبيت. | قد يؤدي حذف ملف غير معروف إلى تعطيل التكامل المحلي أو حذف شيء مهم |
يُضيف ownCloud 11 اعتبارًا خاصًا بكل إصدار: يجب أن تحتوي تطبيقات الطرف الثالث على توقيعات صالحة ليتم تثبيتها أو تحديثها أو تفعيلها، ويمكن حظر التطبيق غير الصالح بدلاً من مجرد الإشارة إليه. اعتبارًا من 6 أكتوبر 2026، تنص وثائق ownCloud 11.0 على أنه سيتم قبول التطبيقات التي تستخدم نظام التوقيع السابق مع تحذير حتى 31 ديسمبر 2026؛ بعد ذلك التاريخ، لن يتم الوثوق إلا بالتوقيعات التي تتم بموجب البنية التحتية للمفاتيح العامة الجديدة (PKI). إذا كنت تستخدم ownCloud 10.x، فراجع الوثائق الخاصة بإصدارك المحدد بدلاً من افتراض أن قواعد تطبيق الإصدار 11.0 تنطبق.
قم بالتحضير قبل تغيير التركيب
- تأكد من إصدار الخادم الحالي والإصدار المستهدف الذي يظهر أثناء عملية الترقية. راجع ملاحظات الإصدار ومتطلبات النظام المطابقة، بما في ذلك إصدارات PHP المدعومة.
- قم بإنشاء نسخة احتياطية جديدة من قاعدة البيانات، وملف الإعدادات، ومجلد البيانات. احتفظ بنسخة من شجرة التعليمات البرمجية الحالية أو لقطة من نظام الملفات إذا كانت طريقة النشر لديك تدعم ذلك.
- ضع الخادم في وضع الصيانة قبل استبدال التعليمات البرمجية أثناء عملية الإصلاح. استخدم الطريقة الموثقة لتثبيتك، وتأكد من عدم قيام المستخدمين بكتابة أي ملفات أثناء العملية.
- حدد طريقة تثبيت ownCloud: أرشيف/يدوي، حزمة نظام التشغيل، أو Docker. اتبع إجراء الترقية الخاص بتلك الطريقة. لا تخلط الملفات من ملف مضغوط (tarball) مع ملفات التثبيت المُدارة بواسطة حزمة.
- احتفظ بالتقرير الأصلي ودوّن كل ملف تنقله أو تستبدله. هذا يُسهّل عملية استعادة النظام وتشخيص المشكلة لاحقاً.
تُعدّ هذه الاحتياطات مهمة لأنّ تحذير سلامة البيانات يتعلّق بشفرة التطبيق القابلة للتنفيذ، بينما تُشكّل قاعدة البيانات وملفات المستخدم أجزاءً منفصلة من عملية التثبيت. وقد يؤدي استعادة دليل شفرة قديم فوق ملفات أحدث مُدارة بواسطة الحزمة إلى حدوث عدم توافق. لذا، توصي إرشادات الترقية الخاصة بـ ownCloud بعمل نسخة احتياطية جديدة، ومراجعة ملاحظات الإصدار والمتطلبات، والتحقق من توافق تطبيقات الطرف الثالث قبل الترقية.
إصلاح ملفات النظام الأساسية بعد الترقية الجزئية
إذا ذكر التقرير مسارات أساسية رسمية مثل index.php`/ version.php` أو `/` أو ملفات ضمن شجرة النظام الأساسي، فاحصل على الأرشيف الرسمي للإصدار المحدد الذي تنوي تشغيله حاليًا. لا تستخدم أرشيفًا أحدث لمجرد توفره، لأن رموز التجزئة الخاصة بالسلامة تتوافق مع إصدار محدد.
في حالة وجود اختلاف بسيط ومفهوم، قارن المسار المُبلغ عنه مع المسار نفسه في ذلك الأرشيف. بعد التأكد من أنه ملف رسمي غير مُعدّل، استبدل الملف المتأثر فقط مع الحفاظ على ملكية الملفات والأذونات المطلوبة من خادم الويب الخاص بك. إذا كانت عدة ملفات مفقودة أو غير متطابقة، أو لم تتمكن من تحديد الإصدار الذي وفّر الملفات الحالية، فإن الترقية النظيفة من دليل إصدار جديد هي عادةً الخيار الأكثر موثوقية.
لتثبيت الأرشيف يدويًا، يُنصح بتجهيز الإصدار بشكل منفصل، والاحتفاظ بملفات النظام config، dataثم اتباع خطوات الترقية الرسمية لنقل التعليمات البرمجية. تجنب استبدال محتويات الأرشيف بمجلد بيانات المستخدم. تتضمن عمليات نشر الحزم والحاويات إجراءات تحديث خاصة بها؛ استخدمها بدلًا من تطبيق طريقة الأرشفة اليدوية. عند نقل الملفات الفردية عبر بروتوكول نقل الملفات (FTP)، توضح وثائق سلامة ownCloud وضع النقل الثنائي.
التعامل مع تحذيرات التطبيق بشكل منفصل
إذا أشار التقرير إلى تطبيق بدلاً من النظام الأساسي، فتحقق أولاً مما إذا كان هذا التطبيق يدعم إصدار ownCloud الخاص بك. ثبّت إصدارًا رسميًا أو إصدارًا مُقدّمًا من جهة الصيانة يتوافق مع الخادم ويحمل توقيعًا صالحًا. إذا لم يتوفر إصدار متوافق، فعطّل التطبيق وتأكد من أن ذلك لن يُعطّل سير العمل المطلوب. يُعدّ حذف التطبيق خيارًا أكثر ديمومة، ويجب اتباع إرشادات الحذف الخاصة بالتطبيق نفسه.
في ownCloud 11، يُعد تعطيل التحقق من صحة تطبيق معين استثناءً يتحكم فيه المسؤول، ويتم تسجيله، ويؤدي إلى فقدان التطبيق لسلامة النظام وحماية الإلغاء. استخدمه فقط بعد تقييم مصدر التطبيق وتأثيره، ووثّق من وافق على الاستثناء وسبب الموافقة. لا يُعد هذا حلاً لإصلاح تثبيت النظام الأساسي التالف أو المُعدّل. في الإصدارات الأقدم، يختلف سلوك الإنفاذ المتاح، لذا راجع وثائق الإصدار المُثبّت لديك.
قم بإجراء فحص جديد وتأكد من النتيجة
بعد تصحيح الملفات الأساسية، استخدم خاصية إعادة الفحص في صفحة الإدارة إن كانت متاحة. يمكنك أيضًا تشغيل occالفحوصات الموثقة. بالنسبة لـ Docker Compose، يقدم دليل توقيع الكود الحالي لـ ownCloud الأمثلة التالية:
docker compose exec owncloud occ integrity:check-core
docker compose exec owncloud occ integrity:check-app calendar
استبدل calendarبمعرف التطبيق المذكور في تقريرك. بالنسبة لعمليات التثبيت غير الحاوية، شغّل الملف occمن دليل ownCloud الخاص بك كمستخدم خادم الويب؛ يختلف المسار الدقيق والمستخدم باختلاف نظام التشغيل وطريقة التثبيت. يتحقق الأمر الموثق من النظام الأساسي أو تطبيق مُسمى؛ ويشير الدليل الحالي إلى عدم وجود أمر واحد لإعادة فحص كل تطبيق يدويًا.
يتم التحقق من الإصلاح عندما لا يُدرج التقرير الجديد الملفات المُصحَّحة وتعمل الميزة المعنية بشكل طبيعي. إذا تكرر خطأ التجزئة نفسه، فابحث عن عملية نشر تلقائية، أو تصحيح محلي، أو مهمة مزامنة، أو حادثة أمنية تُغيّر الملف مرة أخرى. إذا أشار التقرير إلى شهادة ملغاة، أو توقيع تطبيق مفقود، أو عدم تطابق في الإصدار لا يمكنك حله من إصدار رسمي، فتوقف عن تكرار الفحص وتواصل مع مسؤول التطبيق أو دعم ownCloud مع التقرير وإصدار الخادم الدقيق.
أي نهج يجب أن تستخدمه؟
اختر استبدال ملف مُحدد عندما يُشير التقرير إلى ملف أساسي رسمي واحد، ويكون الإصدار الدقيق معروفًا، ويمكنك الحصول على الملف الأصلي المُطابق. كرر الترقية النظيفة عند فشل العديد من الملفات الأساسية، أو انقطاع الترقية، أو احتواء التثبيت على ملفات من أكثر من إصدار. بالنسبة للأخطاء التي تقتصر على التطبيق، يُفضل تحديث من قِبل المُشرف أو تعطيل تطبيق غير مُستخدم؛ فهذا يُعالج المُكوّن المُتأثر دون استبدال الملفات الأساسية غير ذات الصلة. احتفظ باستثناءات التحقق لتطبيق مُحدد تم تقييمه عندما لا يكون هناك بديل مُوقع، وتكون الحاجة التشغيلية أكبر من فقدان حماية سلامة النظام.
قبل التحديث القادم، راجع ملاحظات الإصدار والمتطلبات أولاً، وعطّل تطبيقات الطرف الثالث غير المتوافقة كما توصي ownCloud، ثم أنشئ نسخة احتياطية جديدة. قد تستغرق هذه الخطوات بعض الوقت للتخطيط، لكنها تُسهّل تشخيص أي تحذير يتعلق بسلامة النظام بعد التحديث، وتجعل عملية الاستعادة أكثر أمانًا.
المراجع الرسمية