إصلاح مسارات تطبيقات ZimaOS بعد ترحيل البيانات إلى محرك أقراص آخر

إذا نقلت Media أو Documents أو AppData أو مجلدات ZimaOS الأخرى إلى وحدة NVMe أو قرص HDD أكبر، وبدا أن Jellyfin لا يزال يبحث فقط في ZimaOS-HD، فإن طريقة الترحيل مهمة. وقد حُلّت هذه المشكلة في موضوع مجتمع IceWhale في أكتوبر 2025 من خلال التمييز بين عمليتي ZimaOS المختلفتين اللتين كان من السهل على المستخدمين الخلط بينهما.

تنقل وظيفة الترحيل في الإعدادات بيانات ZimaOS المُدارة وتنشئ روابط رمزية للتوافق ضمن /DATA. أما وظيفة «ترحيل» بالنقر بزر الفأرة الأيمن في تطبيق الملفات، فتنقل المجلدات والملفات العادية وتنتج تقريرًا بالترحيل، لكنها لا تنشئ تلك الروابط الرمزية. كان صاحب المنشور الأصلي قد نقل Media باستخدام أداة الترحيل في تطبيق الملفات، وأبقى User Database على ZimaOS-HD؛ وبعد ترحيل User Database عبر الإعدادات، تمكن Jellyfin من العثور على مجلدات الوسائط، وأكد الكاتب أن المشكلة حُلّت.

التخطيط الأصلي لتخزين ZimaBoard 2

استخدم إعداد المجتمع جهاز ZimaBoard 2 1664، مع تثبيت النظام على ZimaOS-HD وإضافة NVMe بسعة 2 تيرابايت عبر لوحة توسعة PCIe. أراد المستخدم أن يحتفظ قرص النظام الصغير بنظام التشغيل، بينما تبقى بيانات التطبيقات ومحتوى المستخدم على وحدة NVMe الأكبر.

مسار المنتج الحالي هو خادم اللوحة الواحدة ZimaBoard 2.

كان لدى ZimaOS وظيفتا ترحيل مختلفتان

أوضح Zima-Giorgio الفرق الأساسي:

1. «ترحيل الموقع» في الإعدادات: ينقل البيانات التي يديرها ZimaOS وينشئ روابط رمزية للتوافق.
2. «ترحيل» في تطبيق الملفات: ينقل الملفات/المجلدات المحددة ويوفر تقريرًا بمهمة الترحيل، لكنه لا ينشئ روابط رمزية.

يستخدم ZimaOS الحالي صفحة مخصصة لترحيل البيانات

يضع دليل ترحيل بيانات ZimaOS الحالي سير العمل هذا ضمن:

الإعدادات ← ترحيل البيانات

تشمل أهداف الترحيل الحالية صور Docker، وبيانات تطبيقات Docker، وقواعد بيانات المستخدمين مثل المعرض والتنزيلات والمستندات والوسائط والنسخ الاحتياطي.

سير العمل الحالي هو تعديل الموقع ← اختيار مساحة التخزين الجديدة ← بدء الترحيل. استخدم واجهة المستخدم الحالية هذه بدلًا من البحث عن لقطات الشاشة المطابقة لمسار الإعدادات > التطبيقات لعام 2025.

لماذا لا يزال /DATA يبدو مشيرًا إلى ZimaOS-HD

بعد الترحيل المُدار، يحتفظ ZimaOS بمراجع توافق ضمن /DATA. هذه روابط رمزية، ويُطلق عليها شائعًا الروابط اللينة. ويمكن للتطبيق مواصلة الإشارة إلى مسار مألوف ضمن /DATA رغم أن البيانات الفعلية موجودة على قرص آخر.

قدّم Zima-Giorgio هذا الأمر لفحصها:

ls /DATA -al

لذلك قد يبدو مسار AppData المُرحّل من الناحية المفاهيمية كما يلي:

/DATA/AppData → /media/nvme/AppData

لماذا جعل تطبيق الملفات عملية الترحيل تبدو غير متسقة

لاحظ الكاتب الأصلي أن مجلدًا بالاسم نفسه ظل يظهر على ZimaOS-HD بعد الترحيل، وأن الملفات التي أُنشئت على NVMe لم تظهر في المجلد القديم. وقد نُقلت بعض المجلدات باستخدام تطبيق الملفات بدلًا من مسار الترحيل المُدار الذي ينشئ روابط رمزية.

كما أن تطبيق الملفات الرسومي لم يعرض مباشرةً كل مسارات نظام التشغيل، لذلك تمكّن الكاتب من رؤية جزء أكبر من نظام الملفات الفعلي من الطرفية مقارنةً بمتصفح لوحة المعلومات.

الإصلاح الذي أكدته جماعة المستخدمين

أوضح صاحب المنشور الأصلي لاحقًا ما حدث بالضبط:

• تم ترحيل بيانات التطبيق وصورة التطبيق من خلال الإعدادات.
• كانت قاعدة بيانات المستخدمين لا تزال على ZimaOS-HD.
• كان قد تم نقل الوسائط باستخدام أداة ترحيل الملفات، لذلك لم يتم إنشاء رابط رمزي للتوافق.

بعد ترحيل قاعدة بيانات المستخدمين إلى NVMe من خلال الإعدادات، تمكّن Jellyfin من العثور على مجلدات الوسائط. وقد أفاد الكاتب صراحةً بأن ذلك نجح.

سير العمل الآمن الحالي لنقل بيانات التطبيقات والمستخدمين

1. أضف قرص HDD أو SSD أو NVMe داخليًا مؤهلًا، وتأكد من أن ZimaOS يتعرّف عليه.
2. افتح الإعدادات > ترحيل البيانات.
3. اختر الفئة المُدارة التي تريد نقلها.
4. انقر على تعديل الموقع.
5. حدّد مساحة التخزين الوجهة.
6. ابدأ الترحيل ودعه يكتمل قبل إجراء تغييرات أخرى على التخزين.
7. تحقّق من تفاصيل الترحيل.
8. إذا ظلّ أحد التطبيقات يتصرّف كما لو أن البيانات موجودة على القرص القديم، فتحقّق من /DATA الروابط الرمزية وتعيينات وحدات تخزين Docker الخاصة بالتطبيق.

تحقّق من الوجهة الفعلية في الطرفية

ls -al /DATA
readlink -f /DATA/AppData
readlink -f /DATA/Media

هذه أوامر فحص؛ ولا تنقل البيانات أو تحذفها.

تذكّر طبقة مسار حاوية Docker

حتى عندما يكون مسار المضيف في ZimaOS صحيحًا، يعمل Jellyfin داخل Docker. وقد يُركّب مسار مضيف مثل /DATA/Media قد يُركّب داخل الحاوية باسم /Media. لا يستطيع Jellyfin تصفح سوى المسارات المُركّبة داخل حاويته.

تخطيط الإعدادات التاريخي

كانت أداة التخزين مشكلة منفصلة

أفاد المنشور الأصلي أيضًا بظهور بيانات قديمة عن المساحة المستخدمة في أداة تخزين لوحة المعلومات حتى إعادة التشغيل. وقد أقرّ Zima-Giorgio بأن ذلك كان مشكلة معروفة في ذلك الوقت. لا تخلط بين مشكلة العرض هذه ومشكلة مسار Jellyfin.

قائمة التحقق لترحيل ZimaOS ومسارات التطبيقات

1. حدّد ما إذا كنت تنقل بيانات ZimaOS المُدارة أو ملفات عادية.
2. استخدم الإعدادات > ترحيل البيانات الحالي لترحيل صور Docker وبيانات تطبيقات Docker أو قواعد بيانات المستخدم.
3. لا تتوقع أن ينشئ أمر ترحيل المجلد في تطبيق الملفات /DATA روابط التوافق.
4. بعد الترحيل، افحص ls -al /DATA.
5. استخدم readlink -f للتأكد من الوجهة الفعلية.
6. تحقق من تعيين وحدة التخزين من مضيف Docker إلى الحاوية الخاص بالتطبيق.
7. تذكّر أن متصفح Jellyfin يرى مسارات الحاوية، وليس مسارات المضيف العشوائية.
8. لا تحذف المجلدات القديمة يدويًا حتى تتأكد من نجاح الترحيل وسلوك التطبيقات.

الأسئلة الشائعة حول ترحيل البيانات في ZimaOS

لماذا لا يزال Jellyfin يشير إلى /DATA بعد الترحيل؟

قد يكون ذلك مقصودًا. إذ ينشئ ترحيل ZimaOS المُدار روابط رمزية حتى تتمكن التطبيقات من الاستمرار في استخدام مسارات متوافقة /DATA المسارات، بينما توجد الملفات الفعلية على محرك أقراص آخر.

هل أمر الترحيل في تطبيق الملفات هو نفسه ترحيل البيانات؟

لا. ينقل ترحيل الملفات المجلدات والملفات؛ أما ترحيل البيانات المُدار فيُنشئ بنية مسارات التوافق التي تستخدمها البيانات المُدارة في ZimaOS.

كيف أرى الروابط الرمزية؟

استخدم ls -al /DATA. الهدف الظاهر بعد السهم هو موقع التخزين الفعلي.

ما الذي أصلح مشكلة Jellyfin الأصلية فعليًا؟

رحّل المؤلف قاعدة بيانات المستخدم إلى NVMe من خلال مسار الترحيل المُدار في الإعدادات. بعد ذلك عثر Jellyfin على مجلدات الوسائط، وأكد المؤلف نجاح الإعداد.

أين يوجد هذا الإعداد في ZimaOS الحالي؟

تضع الوثائق الحالية سير العمل ضمن الإعدادات > ترحيل البيانات.