لماذا تتعطل أذونات الملفات بعد نقل الملفات إلى جهاز تخزين شبكي (NAS)؟

يمكن أن تعمل الملفات بشكل طبيعي على الكمبيوتر، أو القرص الخارجي، أو مجلد التنزيل، ثم تصبح للقراءة فقط، أو غير مرئية لتطبيق، أو غير قابلة للوصول بعد نقلها إلى NAS. هذا عادة لا يعني أن بيانات الملف تالفة. بل يعني أن الملفات دخلت نظام ملفات جديد بنموذج ملكية وصلاحيات مختلف.

يتم تنفيذ النقل عبر الأجهزة عادةً كنسخ يتبعه حذف المصدر. ينشئ NAS ملفات جديدة باستخدام هوية SMB أو NFS المتصلة، وصلاحيات مجلد الوجهة، وقيم UID وGID، وقناع umask، ومستخدم الحاوية، وقواعد الإنشاء على الخادم. أسرع طريقة لحل المشكلة هي تحديد من أنشأ الملفات، ومن يملكها الآن، وأي مستخدم أو عملية يتم رفضها.

نقل الملفات إلى NAS عادةً ما ينشئ ملفات جديدة

سحب مجلد إلى NAS قد يبدو كعملية نقل عادية في مستكشف ويندوز أو فايندر. لكن في الواقع، القرص المصدر وNAS هما نظاما ملفات منفصلان. يقرأ العميل البيانات الأصلية، ينشئ كائنات وجهة جديدة، ويحذف الأصلية بعد نجاح النقل.

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

هذا التمييز يشرح لماذا لا يضمن "قص ولصق" بقاء الملكية، أو إدخالات ACL، أو السمات الموسعة متطابقة بعد النقل إلى NAS. نظام الوجهة لا يقوم ببساطة بنقل كائن نظام الملفات الأصلي.

صلاحيات الوجهة تحدد ما ترثه الملفات الجديدة

إذا حصل كل ملف جديد يتم نسخه على نفس الصلاحيات غير المتوقعة، فعادةً ما يكون الدليل الأب أكثر أهمية من ملف المصدر. قد يكون الوجهة قد ورثت إدخالات ACL، أو ACLs POSIX الافتراضية، أو أعلام ACLs NFSv4، أو إعدادات صلاحيات محددة لنظام NAS.

على سبيل المثال، قد يتم تكوين مجلد مشترك بحيث ترث الملفات الجديدة صلاحيات الوصول لمجموعة عائلية، أو مجموعة وسائط، أو حساب SMB معين. قد يؤدي غياب علم الوراثة إلى نتيجة عكسية: قد يتمكن المستخدمون من الوصول إلى جذر مجموعة البيانات ولكن ليس إلى الملفات الجديدة داخلها.

تفرق أنظمة الأذونات بنمط TrueNAS بين نماذج POSIX وNFSv4/SMB ACL. السلوك المهم هو أن وراثة NFSv4 وSMB ACL يمكن أن تتحكم في الملفات والمجلدات الجديدة، بينما تتصرف الافتراضات POSIX وحدود مجموعة البيانات بشكل مختلف. قبل تغيير ملفات فردية، افحص ACL وأعلام الوراثة على المجلد الوجهة.

يستخدم NAS حساب SMB المتصل

عندما ينسخ جهاز ويندوز أو macOS ملفًا عبر SMB، لا يحتفظ NAS عادةً بهوية المستخدم المحلية لجهاز العميل. ينشئ ملف الوجهة كالحساب الذي تم التحقق منه على مشاركة SMB، أو كحساب يتم تعيين تلك الجلسة إليه.

لهذا السبب قد يكون الملف المملوك لمستخدم ويندوز على جهاز الكمبيوتر المصدر مملوكًا لـ kenneth , nasuser , ضيف ، أو هوية أخرى على جانب NAS بعد النقل. يمكن لبيانات اعتماد SMB المحفوظة أيضًا أن تتسبب في إنشاء جهاز كمبيوتر واحد لملفات تحت مالك مختلف عن جهاز كمبيوتر آخر.

تحقق من اسم مستخدم SMB النشط بدلاً من افتراض استخدام تسجيل الدخول إلى سطح المكتب. افصل المشاركة، وامسح بيانات الاعتماد القديمة إذا لزم الأمر، وأعد الاتصال بحساب NAS الذي يجب أن يملك أو يدير الملفات.

وصول المشاركة والوصول إلى الملفات هما طبقتا أذونات منفصلتان

قد يتمكن المستخدم من فتح مشاركة SMB وتصفح المجلدات لكنه لا يستطيع تعديل أو إعادة تسمية أو حذف ملف. هذا يعني أن المشاركة الشبكية متاحة؛ لكنه لا يثبت أن نظام الملفات منح العملية المطلوبة.

تحدد قواعد مستوى المشاركة ما إذا كان يمكن لعميل SMB أو NFS الدخول إلى المشاركة وما إذا كان الاتصال معروضًا للقراءة فقط أو للقراءة/الكتابة. ثم يقوم نظام الملفات الأساسي بتقييم المالك والمجموعة وبتات الوضع وإدخالات ACL وقواعد الوراثة لكل ملف ودليل.

قم بحل المشكلات في كلا الطبقتين. المشاركة المعلمة للقراءة/الكتابة لا يمكنها تجاوز ACL لنظام الملفات الذي يمنع الكتابة، وأنماط نظام الملفات المتساهلة لا تساعد عندما يكون حساب SMB مقيدًا بواسطة تكوين المشاركة.

ACLs بنمط ويندوز وبتات الوضع POSIX لا تتطابق تمامًا

تحتوي أذونات ويندوز على عدة مستخدمين ومجموعات، وإدخالات سماح ومنع صريحة، وأعلام وراثة، وحقوق منفصلة للقراءة والكتابة والحذف والتعديل. تقلل بتات الوضع التقليدية POSIX الوصول إلى المالك والمجموعة والآخرين.

يجب على أنظمة تشغيل Samba وNAS الترجمة بين تلك النماذج. قد يعرض لوحة أمان ويندوز ACL مفصلًا حتى لو ls -l يعرض فقط تمثيلاً مبسطًا. وعلى العكس، تشغيل chmod قد يغير بتات الوضع دون إعادة بناء ACL بنمط ويندوز الذي يتوقعه عملاء SMB بشكل صحيح.

إذا كان مجموعة بيانات NAS تستخدم NFSv4 أو ACLs الخاصة بـ SMB، فافحص ACL الكامل من خلال واجهة NAS أو باستخدام أمر يدعم ACL. لا تفترض أن الملف الذي يظهر rwxrwx--- تروي القصة الكاملة للأذونات.

تعارضات UID و GID تؤثر على لينكس وNFS والتطبيقات

عادةً ما تحدد أنظمة Linux الملكية من خلال معرفات المستخدمين والمجموعات الرقمية. اسم المستخدم هو مجرد تسمية مرتبطة بتلك الأرقام.

يمكن لنظامين عرض مستخدم يسمى media بينما يستخدم أحدهما UID 1000 والآخر يستخدم UID 1001. بالنسبة لنظام Linux و NFS، هذه هويات مختلفة. قد يكون الملف المملوك لـ UID 1000 غير متاح لتطبيق يعمل كـ UID 1001 حتى عندما تبدو أسماء المستخدمين المرئية متطابقة.

تحقق من القيم الرقمية على NAS، المضيف، العميل، والتطبيق:

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

قارن الأرقام بدلاً من الأسماء المعروضة فقط. إذا كانت أنظمة متعددة بحاجة إلى كتابة نفس التخزين، فقم بمحاذاة قيم UID/GID المطلوبة أو أنشئ مجموعة مشتركة بالأذونات الصحيحة.

قد يكتب SMB و NFS نفس مجموعة البيانات كمستخدمين مختلفين

تظهر مشاكل الأذونات غالبًا تدريجيًا عندما يكون لكل من عملاء SMB و NFS حق الكتابة على نفس الدليل. قد تنتمي الملفات التي تم تحميلها عبر SMB إلى مستخدم NAS واحد، بينما قد تحمل الملفات التي تم إنشاؤها عبر NFS UID رقمي من نظام آخر.

يمكن للبروتوكولين أيضًا تطبيق قواعد ACL وقواعد تعيين الهوية المختلفة. نتيجة لذلك، قد يحتوي المجلد على ملفات تبدو متطابقة للمستخدم لكنها تملك مالكين ومجموعات وأقنعة أو إدخالات موروثة مختلفة.

اختر بروتوكول كتابة رئيسي واحد عندما يكون ذلك ممكنًا. عندما يجب أن يشارك SMB و NFS مجموعة بيانات، قم بمحاذاة معرفات الأرقام، المجموعات المشتركة، ACL الافتراضية، قيم umask، وسلوك الإنشاء قبل وضع بيانات الإنتاج فيها.

تضيف حاويات Docker هوية مستخدم أخرى

قد يكون الملف قابلاً للقراءة عبر SMB لكنه غير متاح لـ Plex، Jellyfin، Nextcloud، أداة التنزيل، أو حاوية النسخ الاحتياطي. يمكن لـ Docker تركيب المسار الصحيح بينما لا تزال العملية داخل الحاوية تفتقر إلى إذن القراءة أو الكتابة عليه.

تعمل عملية الحاوية تحت UID و GID خاصين بها. إذا لم تتطابق تلك الهوية مع المالك أو مجموعة مسموح بها على مسار NAS المركب، فإن التطبيق يتلقى تم رفض الإذن. تركيب المجلد يجعل الدليل مرئيًا؛ لكنه لا يتجاوز تفويض نظام الملفات.

الحل الشائع هو مطابقة UID و GID للحاوية مع الهوية المسموح لها باستخدام المجلد المركب. تحقق من هوية العملية الفعلية بدلاً من الاعتماد فقط على حقل PUID أو PGID المعروض في ملف Compose:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "قابل للكتابة"

حاوية واحدة يمكنها إنشاء ملفات لا يمكن لحاوية أخرى قراءتها

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

قد تستخدم التطبيقات قيم UID/GID مختلفة أو umasks مختلفة. إذا أنشأ التنزيل الملفات كـ 600، فقط مالكه يمكنه قراءتها وكتابتها. وضع مثل 640 يسمح بالقراءة للمجموعة، ولكن فقط عندما تشترك كلتا التطبيقين في المجموعة الصحيحة.

بالنسبة لمجلدات التطبيقات المشتركة، استخدم مجموعة مالك مخططة، أضف الهويات اللازمة للتطبيق إلى تلك المجموعة، واختر umask يمنح المجموعة الوصول المطلوب. إصلاح الملفات القديمة فقط لن يساعد إذا استمر التنزيل في إنشاء ملفات جديدة بأوضاع مقيدة.

الـ Umask وقواعد إنشاء الخادم تتحكم في الأذونات الجديدة

إذا كانت الملفات القديمة تعمل ولكن كل ملف جديد غير قابل للوصول، فمن المحتمل أن تكون عملية الإنشاء هي السبب. يبدأ كل برنامج بوضع ملف مطلوب، ويزيل umask الخاص به أذونات محددة قبل إنشاء الملف.

قد يستخدم Samba أيضًا إعدادات مثل قناع الإنشاء, قناع الدليل, فرض المستخدم، أو فرض المجموعةقد تخفي واجهات NAS هذه خلف قوالب الأذونات، أو إعدادات المجلدات المشتركة، أو خيارات الوراثة.

أنشئ ملف اختبار واحد عبر كل مسار: Windows SMB، macOS SMB، مدير ملفات NAS، NFS، وكل حاوية ذات صلة. قارن المالك الناتج، والمجموعة، والوضع، وACL. هذا يكشف بسرعة أي مسار إنشاء ينتج الأذونات المعطلة.

أدوات النقل المختلفة تحافظ على بيانات وصفية مختلفة

Finder، مستكشف ويندوز، واجهة ويب NAS، cp، و rsync لا تضمن نتائج متطابقة. بعضها يحافظ على الطوابع الزمنية، وبعضها يمكنه الاحتفاظ بأوضاع POSIX، والبعض الآخر ينشئ ملفات جديدة فقط وفقًا لقواعد الوجهة.

قبل اختيار طريقة الترحيل، قرر أي الخصائص يجب أن تبقى:

• محتويات الملفات وبنية الدليل
• أوقات التعديل
• أذونات POSIX
• المالك والمجموعة
• مدخلات ACL
• السمات الموسعة
• الروابط الرمزية

بالنسبة للوثائق العائلية العادية أو ملفات الوسائط، قد يكون وراثة الوجهة مفضلة على الحفاظ على حسابات الكمبيوتر المصدر التي لا توجد على NAS. بالنسبة لبيانات التطبيقات، أو مجلدات المنزل في لينكس، أو ترحيلات الخوادم، قد يكون الحفاظ على الملكية وبيانات ACL ضروريًا.

rsync لا يحافظ على كل خاصية بأمر أساسي واحد

يُعد rsync مفيدًا لترحيلات NAS المُتحكم بها، لكن النتيجة تعتمد على خياراته، وصلاحيات المستخدم الذي ينفذ الأمر، وقدرات أنظمة الملفات المصدر والوجهة.

يحافظ وضع الأرشيف على البيانات الوصفية الشائعة بما في ذلك الأوضاع والطوابع الزمنية والمجموعات والملكية حيثما يُسمح بذلك. هناك خيارات إضافية مطلوبة عندما يجب على الترحيل الحفاظ على الأذونات وACLs والسمات الموسعة باستخدام rsync. قد يستخدم اختبار نموذجي من لينكس إلى لينكس:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

الـ -A الخيار يحافظ على ACL و -X يحافظ على السمات الموسعة عندما يدعمها الطرفان. --numeric-ids يجب استخدامه بعناية لأن الحفاظ على مالك رقمي لا يملك حسابًا صالحًا على NAS يمكن أن يعيد إنتاج عدم التطابق الذي تحاول تجنبه.

وجهة rsync المركبة عبر SMB قد لا تتصرف مثل نظام ملفات NAS

تشغيل rsync من جهاز كمبيوتر إلى مشاركة SMB مركبة محليًا ليس دائمًا مكافئًا لتشغيل rsync عبر SSH مباشرة على نظام ملفات NAS. قد يقوم طبقة SMB بتعيين المالكين، أو تحويل ACL، أو رفض محاولات تعيين السمات.

قد لا يكون لدى المستخدم الذي ينفذ نسخ SMB إذن لتعيين ملكية عشوائية، حتى عندما يطلب rsync ذلك. قد يدعم نظام الملفات الوجهة أيضًا نموذج ACL مختلفًا عن المصدر.

اختبر دليلًا صغيرًا تمثيليًا أولاً. افحص الملفات مباشرة على NAS بعد النقل، وليس فقط من خلال المشاركة المركبة على العميل. أكد الملكية والأوضاع وACL والسمات الموسعة والوصول إلى التطبيق قبل ترحيل مجموعة البيانات بالكامل.

إعدادات أذونات NAS المسبقة يمكن أن تتجاوز بتات الوضع البسيطة

تدير بعض أنظمة NAS الوصول من خلال قوالب ACL لمجموعة البيانات والبيانات الوصفية الموسعة بدلاً من أوضاع المالك/المجموعة/الآخرين التقليدية فقط. هذا يمكن أن يجعل التعديل اليدوي chmod قد تظهر ناجحة بينما يستمر SMB أو التطبيق في رفض الوصول.

قد يتم أيضًا تكوين مجموعة البيانات لإعادة تطبيق القواعد الموروثة عند إنشاء ملفات جديدة أو عند تعديل الأذونات من خلال واجهة الإدارة. قد يؤدي خلط ACL التي تُدار عبر الواجهة الرسومية مع تغييرات متكررة من سطر الأوامر إلى حالة غير متسقة.

اختر نموذج أذونات واحد وقم بإدارته بشكل متسق. إذا تم تكوين مجموعة البيانات لـ SMB/NFSv4 ACL، فاستخدم محرر ACL الخاص بـ NAS أو الأدوات التي تدعم ACL بدلاً من استبدال الهيكل مرارًا بأوامر وضع POSIX.

إعادة تثبيت نظام NAS لا تعيد بالضرورة تعيين أذونات البيانات

عادةً ما تنتمي الأذونات إلى الملفات ومجموعة بيانات نظام الملفات، وليس فقط إلى تكوين نظام تشغيل NAS. لذلك قد يؤدي إعادة تثبيت نظام التمهيد إلى ترك نفس ملكية الملفات غير القابلة للوصول وإدخالات ACL على مجمع التخزين المستورد.

توضح حالة من مجتمع TrueNAS كيف تظل أذونات نظام الملفات مرتبطة بمجمع التخزين ويجب مطابقتها مع المستخدمين الصحيحين وتكوين الوصول المناسب. كما توضح المخاطر المرتبطة بإجراء تغييرات متكررة كبيرة دون فهم نموذج الهوية المقصود أولاً.

قبل إعادة التثبيت أو إعادة بناء الخدمات، افحص مالك مجموعة البيانات، ACL، ومستخدمي التطبيق. قد تكون البيانات سليمة وتحتاج فقط إلى استعادة قواعد الوصول الخاصة بها بشكل صحيح.

لماذا chmod 777 التكراري ليس إصلاحًا حقيقيًا

عندما تصبح آلاف الملفات غير قابلة للوصول، chmod -R 777 يبدو كطريقة سريعة لاستعادة الوصول. يمنح إذن القراءة والكتابة والتنفيذ للمالك، المجموعة، وكل هوية محلية أخرى.

ذلك قد يكشف بيانات خاصة، يسمح لخدمات غير ذات صلة بتعديل الملفات، يضبط إذن التنفيذ على مستندات عادية، ويتلف هيكل ACL الموروث بعناية. كما أنه لا يصحح المالك الخاطئ، UID الحاوية غير المتطابق، فقدان عضوية المجموعة، أو تعيين هوية SMB المعطوب.

استخدم نموذج الوصول المقصود بدلاً من ذلك: حدد المالك الصحيح والمجموعة المشتركة، أعد بناء ACL المناسب، اضبط أوضاع الدليل والملف بشكل منفصل، وصحح الوراثة المستقبلية وإعدادات umask. اختبر على مجلد صغير قبل تطبيق التغييرات التكرارية.

إصلاح الأذونات من الهوية إلى الخارج

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

لكل سير عمل متأثر، سجّل:

• المستخدم أو العملية التي تحاول الوصول
• UID وGID الرقميان حيثما ينطبقان
• البروتوكول أو التثبيت المستخدم
• المالك والمجموعة الحاليان للملف
• ACL الكامل والإدخالات الموروثة
• الوصول المطلوب فعليًا: قراءة، إنشاء، تعديل، أو حذف

ثم عدل فقط الطبقة الخاطئة. أضف المستخدم إلى مجموعة مسموح بها، صحح الملكية، أصلح ACL، ووفق UID الحاوية، أو حدّث قاعدة الإنشاء. تجنب منح وصول أوسع مما يحتاجه سير العمل.

اتبع ترتيب استكشاف الأخطاء متعدد الطبقات

تغيير ACL المشاركة، هوية الحاوية، تصدير NFS، وأوضاع الملفات في نفس الوقت يدمر الأدلة المفيدة. اختبر طبقة إذن واحدة في كل مرة.

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

منع مشاكل الأذونات قبل ترحيل NAS كبير

إصلاح الأذونات عبر مئات الآلاف من الملفات أصعب بكثير من اختبار نموذج الوصول قبل الترحيل. أنشئ مجلد وجهة صغير بنفس ACL وتكوين التطبيق المخطط لمجموعة البيانات النهائية.

انسخ عدة أنواع من الملفات، والمجلدات المتداخلة، والملفات للقراءة فقط، والبرامج النصية القابلة للتنفيذ، والملفات ذات السمات الموسعة. اختبرها من كل مسار مطلوب: SMB، NFS، واجهة NAS، وبرامج النسخ الاحتياطي، والحاويات ذات الصلة.

ابدأ الترحيل الكامل فقط بعد أن تتلقى الملفات الجديدة باستمرار المالك الصحيح، والمجموعة، و ACL، والوصول إلى التطبيق. احتفظ بلقطة أو نسخة احتياطية قبل تطبيق أي تغييرات متكررة على الملكية أو الأذونات للبيانات الموجودة.

النتيجة النهائية

تتعطل أذونات الملفات بعد نقل البيانات إلى NAS لأن النقل عادةً ما ينشئ كائنات نظام ملفات جديدة. تحكم هذه الكائنات بواسطة حساب NAS المستخدم للنقل، و ACL الوجهة، وقيم UID/GID، و umask، وتعيين البروتوكول، وهوية التطبيق أو الحاوية.

لا تبدأ بـ chmod 777أولاً أجب عن ثلاثة أسئلة: من أنشأ الملف، من يملكه الآن، وأي هوية يتم رفضها. ثم افحص وصول المشاركة، و ACLs نظام الملفات، والوراثة، ومعرفات الحاوية، وقواعد الإنشاء المستقبلية.

يجب أن يقوم الإصلاح الناجح بأمرين: استعادة الوصول المناسب للملفات الموجودة وضمان أن الملف التالي الذي يتم نسخه أو تنزيله أو إنشاؤه على NAS يحصل تلقائيًا على الأذونات الصحيحة.

الأسئلة الشائعة

لماذا ترث الملفات المنسوخة أذونات مجلد NAS؟

عادةً ما ينشئ النقل إلى NAS ملفات جديدة على نظام ملفات مختلف. تُمنح الكائنات الجديدة عادةً أذونات من ACL مجلد الوجهة، وعلامات الوراثة، وقواعد الإنشاء على الخادم.

لماذا يمكنني فتح ملفات NAS عبر SMB لكن حاوية Docker الخاصة بي لا تستطيع؟

جلسة SMB والحاوية تستخدم هويات مختلفة. تحقق من UID و GID الفعليين للحاوية، وملكية المسار المركب الرقمية، وعضوية المجموعة، وما إذا كان التركيب للقراءة فقط.

هل يجب أن أستخدم chmod 777 لإصلاح مشاركة NAS؟

لا. يمنح كل هوية محلية وصولًا واسعًا، قد يضر بوراثة ACL، ولا يحل مشكلة الملكية غير الصحيحة أو تعيين UID/GID. عرّف المستخدمين والمجموعات المقصودة، ثم أصلح الملكية و ACLs وفقًا لذلك.

هل يمكن لـ rsync الحفاظ على أذونات ملفات NAS؟

يمكنه الحفاظ على أذونات POSIX والبيانات الوصفية الأخرى عندما تدعم الخيارات المحددة، وصلاحيات التنفيذ، وكلا نظامي الملفات ذلك. تتطلب ACLs والسمات الموسعة خيارات إضافية مثل -A و -X.

لماذا تستمر الملفات الجديدة في التعطل بعد إصلاح الملفات القديمة؟

مسار الإنشاء لا يزال خاطئًا. تحقق من ACL الموروث لمجلد الوجهة، وهوية SMB أو NFS، و umask التطبيق، وقواعد إنشاء Samba، و UID/GID للحاوية.