استعادة مزامنة WebDAV الخاصة بـ ownCloud عن طريق إيجاد المسار المعطل

لحل مشكلة "يبدو أن واجهة WebDAV معطلة"، تأكد من إمكانية الوصول إلى نقطة نهاية DAV الخاصة بـ ownCloud، وأن خادم الويب الخاص بك يُعيد توجيه طلبات WebDAV، بما في ذلك طلب ` PROPFINDdevice`، إلى تطبيق PHP الخاص بـ ownCloud. يعتمد التغيير الصحيح على ما إذا كان Apache أو Nginx أو خادم وكيل عكسي هو المسؤول عن معالجة عنوان URL العام؛ لذا اختبر نقطة النهاية قبل تعديل الإعدادات لإصلاح الطبقة المعطلة.

ابحث عن ما يختبره التحذير فعليًا

يُصدر مدقق إدارة ownCloud Classic هذا التحذير عندما يتعذر على فحص مزامنة الملفات استخدام واجهة WebDAV. في كثير من الحالات، يكون السبب مشكلة في خادم الويب أو مسار الطلب، ولا يُعدّ ذلك دليلاً على تلف الملفات أو قاعدة البيانات. يُشرح هذا التحذير في مرجع تحذيرات ownCloud Server 11 الرسمي بشكل منفصل عن فحص اكتشاف الخدمة /.well-known/caldav./.well-known/carddav

استخدم نقطة نهاية DAV المطابقة لمسار التثبيت العام. في جذر النطاق، تكون نقطة النهاية عادةً هي `/dev https://cloud.example.com/remote.php/dav/ dav https://cloud.example.com/owncloud/remote.php/dav.../remote.php/webdav

أرسل طلبًا موثقًا PROPFINDبعمق صفر. في هذا الأمر، استبدل اسم المضيف/المسار واسم المستخدم في المثال. سيطلب منك Curl إدخال كلمة المرور لأنه يتم توفير اسم المستخدم فقط -u.

curl -i -u 'USERNAME' -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/owncloud/remote.php/dav'

عادةً ما تكون استجابة WebDAV الناجحة هي 207 Multi-Status. فسّر الاستجابات الأخرى على أنها مؤشرات: 301أو 302تشير إلى مشكلة في إعادة التوجيه أو عنوان URL الأساسي؛ أو 401تعني عدم قبول المصادقة؛ أو 404تعني غالبًا أن المسار أو إعادة كتابة PHP لم تصل إلى ownCloud؛ أو 405تشير 501إلى أن الخادم أو الوكيل أو طبقة الأمان رفضت طريقة DAV. لا يُعد فتح المتصفح لعنوان URL مع صفحة تسجيل الدخول دليلاً على نجاح PROPFINDالعملية.

اختر الحل حسب تصميم خادم الويب

أباتشي: أبقِ قواعد إعادة الكتابة الخاصة بـ ownCloud نشطة

لتثبيت Apache بشكل قياسي، تأكد أولاً من وجود الملف المُقدّم من ownCloud .htaccessوأن Apache يسمح بتوجيهات إعادة الكتابة الخاصة به في دليل التثبيت. يُحافظ مُثبّت ownCloud وعملية الترقية على هذه القواعد. إذا AllowOverride Noneمنع Apache من قراءتها، فإما أن تسمح بالتجاوزات المطلوبة لدليل ownCloud أو تنقل القواعد المُكافئة إلى إعدادات المضيف الافتراضي. يُعد الخيار الأول أسهل في الصيانة لموقع ownCloud واحد نموذجي؛ وقد تكون قواعد المضيف الافتراضي المركزية أفضل عندما تتطلب السياسة إعدادات خارج أدلة التطبيقات.

لا تقم بلصق كتلة إعادة كتابة عامة فوق إعدادات تعمل بشكل صحيح. تأكد من mod_rewriteتفعيلها، وأن الموقع يشير إلى جذر مستند ownCloud الصحيح، وأن الطلبات /remote.php/davتصل إلى معالج PHP. بعد تغيير إعدادات Apache، قم بتشغيل اختبار الإعدادات قبل إعادة تحميلها. في ownCloud Classic 11 المبني على Docker، تدير الصورة إعدادات Apache المضمنة؛ استخدم آليات الإعدادات والبيئة المدعومة في الصورة بدلاً من تعديل الملفات المُنشأة داخل حاوية قيد التشغيل. راجع وثائق استكشاف أخطاء خادم ownCloud 11 وإصلاحها .

Nginx: استخدم إعدادات خادم ownCloud

لا يقرأ Nginx .htaccessملفات Apache. إذا كان Nginx يُشغّل ownCloud مباشرةً، فاستخدم إعدادات Nginx المُطابقة لإصدار ownCloud ومسار التثبيت، بما في ذلك معالجة مواقع PHP وتوجيه DAV. قد يُشغّل موقع PHP مُخصّص واجهة الويب مع ظهور خطأ 404 أو توجيهه إلى مُعالج خاطئ. قارن كتلة الخادم النشطة مع وثائق تثبيت ownCloud 10.16/remote.php/dav الخاصة بالمُورّد ، ثم اختبر الإعدادات وأعد تحميل Nginx. تعتمد التوجيهات الدقيقة على التوزيعة، ومقبس PHP-FPM، وما إذا كان ownCloud موجودًا في جذر النطاق أو في دليل فرعي.

الخادم الوكيل العكسي: الحفاظ على المسار والطريقة وعنوان URL العام

إذا قام خادم وكيل بإنهاء بروتوكول HTTPS أو توجيه مسار فرعي مثل `/// /cloud`، فتأكد من أنه يُعيد توجيه مسار DAV بالكامل إلى الخادم الخلفي ويسمح باستخدام طرق WebDAV مثل PROPFIND`/// PUT` و` MOVE///` و`/// DELETE`. قد يحظر خادم الوكيل أو جدار حماية تطبيق الويب طريقةً ما حتى لو كانت نقطة نهاية PHP صحيحة. قارن طلبًا مُرسلًا عبر عنوان URL العام بطلب مُرسل مباشرةً إلى الخادم الخلفي من شبكة موثوقة؛ إذا أعاد الوصول المباشر رمز الاستجابة 207 بينما فشل الطلب العام، فركز على مسار الوكيل، وتصفية الطرق، وعمليات إعادة التوجيه، وعناوين التفويض.

قم بتعيين عناوين الوكيل الخاصة بـ ownCloud إلى عناوين الوكيل الفعلية فقط trusted_proxies. في حال فشل الكشف التلقائي عن عنوان URL، overwritehostيمكن لإعدادات overwriteprotocolو و overwritewebrootوصف عنوان URL العام، لكنها لا تُصلح طريقة DAV المحظورة أو مسار PHP المفقود. قد يسمح مستوى ثقة الوكيل غير الصحيح بظهور عناوين عميل مزيفة. استخدم إرشادات تكوين الوكيل العكسي الرسمية لشبكتك.

افصل عملية اكتشاف DAV عن عملية الوصول إلى الملفات

تساعد عناوين /.well-known/caldavURL الخاصة /.well-known/carddavبـ `<URL>` و`<URL>` عملاء التقويم وجهات الاتصال على اكتشاف نقاط نهاية الخدمة. من المفترض أن تُوجّه هذه العناوين إلى نقطة نهاية DAV الخاصة بـ ownCloud، ولكن في حال حدوث خطأ هناك، سيظهر تحذير منفصل عن فحص WebDAV المعطّل لمزامنة الملفات. قد لا يؤدي إصلاح عمليات إعادة التوجيه هذه فقط إلى إزالة تحذير المزامنة. بالنسبة إلى Apache، قد تتولى قواعد ownCloud المُضمّنة عملية الاكتشاف عند تفعيلها؛ بينما تتطلب عمليات نشر Nginx والمجلدات الفرعية تكوين خادم مطابق. تحقق من كل عنوان URL ووجهة إعادة التوجيه الخاصة به بشكل مستقل، باتباع إرشادات تحذيرات ownCloud الرسمية .

تحقق من الإصلاح

أعد اختبار المصادقة PROPFINDعلى عنوان URL العام لـ DAV وتأكد من استجابته 207 Multi-Status. ثم قم بتحديث صفحة إدارة ownCloud وأجرِ اختبار مزامنة بسيطًا باستخدام تطبيق سطح المكتب. إذا استمر فشل الطلب، قارن حالة HTTP والطابع الزمني مع سجلات خادم الويب، والوكيل، وPHP، وownCloud. في Docker، تشير وثائق ownCloud إلى أن سجلات التطبيق قد تكون موجودة في دليل السجلات المُثبَّت، بينما تُرسَل سجلات Apache وPHP إلى مخرجات الحاوية؛ docker compose logs owncloudوهذا يُساعد في تحديد هذه الأخطاء.

تغطي أدلة المستخدم الحالية لـ ownCloud كلاً من الإصدارين Classic 11.0 و 10.16، وتختلف طريقة التثبيت باختلاف الإصدار؛ حيث تُحدد وثائق Classic 11 استخدام Docker كطريقة التثبيت المدعومة. استخدم دليل الإصدار المُثبّت لديك، وتجنّب تطبيق أجزاء Apache أو Nginx القديمة بشكل عشوائي على إعدادات الحاويات أو الخوادم الوكيلة الأحدث.