SMB مقابل NFS: أي طريقة لمشاركة الملفات يجب أن تستخدمها في المنزل؟

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

يصبح NFS أكثر جاذبية عندما تكون الأجهزة العميلة في الغالب خوادم لينكس، أو مضيفي Proxmox، أو أنظمة شبيهة بيونكس تقوم بتركيب التخزين كجزء من سير عمل بنية تحتية مُدارة. يمكن أن يكون فعالًا ومتوقعًا، لكن فقط عندما يتم التخطيط بشكل صحيح لقيم UID/GID، وقواعد التصدير، وسلوك التركيب، وملكية الملفات.

اختر البروتوكول بناءً على العميل، وليس على معيار الأداء

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

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

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

عادةً ما يكون SMB الخيار الأسهل الافتراضي لبيئة منزلية مختلطة

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

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

بالنسبة لشبكات مختلطة من ويندوز، وmacOS، ولينكس، يمكن لـ SMB 3.x الحديث تضييق معظم فجوة الأداء مع الحفاظ على توافق أوسع مع العملاء. هذا يجعل SMB نقطة البداية العملية للوثائق، وصور العائلة، والتنزيلات المشتركة، وتصفح NAS العام.

يناسب NFS سير عمل لينكس المُدار بشكل أكثر طبيعية

غالبًا ما يكون دمج NFS أسهل عندما يكون العميل خادم لينكس بدلاً من شخص يتصفح المجلدات. يمكن تثبيت المشاركة في دليل ثابت أثناء بدء التشغيل واستخدامها بواسطة برامج النسخ الاحتياطي، وخدمات الوسائط، ومضيفي التمثيل الافتراضي، أو عمليات النظام الأخرى.

يعمل هذا بشكل جيد عندما يتحكم مسؤول واحد في كل من NAS والعملاء. يمكنك تحديد الشبكة الفرعية المسموح بها، ومحاذاة المستخدمين والمجموعات، واختيار خيارات التثبيت، والتأكد من بدء الخدمات فقط بعد توفر المشاركة الشبكية.

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

يستخدم SMB و NFS نماذج وصول مختلفة

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

تعمل تكوينات NFS المنزلية الشائعة بشكل مختلف. غالبًا ما يتم تقييد التصدير إلى مضيفين أو شبكات فرعية محددة، بينما يعتمد الوصول إلى الملفات على قيم UID و GID الرقمية في يونكس التي يرسلها العميل. يمكن لـ NFSv4 استخدام تكوينات هوية و Kerberos أكثر تقدمًا، لكن العديد من الإعدادات المنزلية تستمر في الاعتماد على شبكات العملاء الموثوق بها والملكية الرقمية.

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

تخطيط UID و GID هو المنحنى التعليمي الرئيسي لـ NFS

اسم مستخدم لينكس هو مجرد تسمية قابلة للقراءة. يسجل نظام الملفات في النهاية معرفات المستخدم والمجموعة الرقمية. قد يحتوي جهازان على مستخدم يسمى الوسائط، لكنهما هويتان مختلفتان إذا استخدم أحدهما UID 1000 والآخر UID 1001.

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

قبل استخدام NFS لعدة أنظمة لينكس، قارن نتائج id username على العميل والخادم. نوع مطابقة UID و GID الرقمية المطلوبة لمشاركات NFS القابلة للكتابة غالبًا ما يكون الخطوة المفقودة عندما يمكن للمستخدم دخول دليل لكنه لا يستطيع إنشاء ملفات.

Root Squash ليس فشل إذن عشوائي

تستخدم تصديرات NFS عادةً root squashing لمنع مستخدم الجذر على جهاز العميل من أن يصبح جذرًا تلقائيًا على NAS. يتم تعيين الطلبات من UID 0 البعيد إلى هوية مجهولة أقل امتيازًا.

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

لا تقم بتعطيل root squashing لمجرد أنه يمنع سير عمل واحد. حدد أولاً أي مستخدم غير الجذر أو مجموعة يجب أن تمتلك البيانات، ثم امنح تلك الهوية الوصول المطلوب. باستخدام no_root_squash يتخلى عن حد أمني مهم ولا ينبغي اعتباره اختصارًا عاديًا لخادم المنزل.

NFS ليس أسرع تلقائيًا من SMB

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

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

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

عادةً لا تحتاج ملفات الوسائط الكبيرة إلى البروتوكول الأسرع

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

يصبح الفرق أكثر وضوحًا عندما يقوم Plex أو Jellyfin أو Sonarr أو تطبيق آخر بمسح مكتبة كبيرة. قد يفتح الخادم آلاف الملصقات والترجمات وملفات NFO ومراجع قاعدة البيانات حتى مع قراءة التشغيل الفعلي لملف وسائط كبير واحد بشكل متسلسل.

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

عادةً ما يكون SMB أفضل للوصول المباشر إلى مشغل الوسائط

إذا اتصل جهاز Apple TV أو جهاز Android TV أو هاتف أو جهاز لوحي أو كمبيوتر محمول مباشرة بـ NAS، فإن SMB عادةً ما يكون الخيار الأسهل. يمكن للعديد من تطبيقات الوسائط تصفح مشاركات SMB باستخدام عنوان الخادم واسم المستخدم وكلمة المرور.

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

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

غالبًا ما يكون NFS مناسبًا طبيعيًا لتخزين Proxmox

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

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

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

يجب اختيار تخزين Docker حسب نوع البيانات

استخدام مسار NAS داخل Docker لا يجعل NFS الخيار الصحيح تلقائيًا لكل حاوية. عبء العمل أهم من منصة الحاوية.

مكتبات الوسائط، والتنزيلات، والاستيرادات، والتصديرات، والنسخ الاحتياطية، والملفات المشتركة الكبيرة الأخرى يمكن أن تعمل جيدًا عبر SMB أو NFS. قد يجد مضيف Docker في لينكس أن NFS أسهل لأن ملكية الملفات تُعبر عنها من خلال قيم UID/GID المألوفة.

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

ركب المشاركة على المضيف قبل تمريرها إلى الحاويات

لعديد من نشرات خوادم المنازل، أنظف نموذج هو تركيب مشاركة NAS مرة واحدة على مضيف Docker ثم ربط المسار المحلي داخل الحاويات التي تحتاجه.

هذا يحافظ على بيانات الاعتماد، وإعدادات تصدير NFS، وسلوك إعادة الاتصال، وترتيب بدء التشغيل في مكان واحد. ترى الحاويات مجلدًا عاديًا فقط، بينما يدير المضيف نظام الملفات الشبكي.

النموذج يعمل مع NFS أو SMB. التفاصيل المهمة هي أن تركيب المضيف متاح قبل بدء الحاوية، وأن UID/GID الخاص بالحاوية يمكنه الوصول إلى الملفات المركبة، وأن الخدمة لا تكتب بصمت في دليل محلي فارغ عندما يكون NAS غير متصل.

لا تدع كلا البروتوكولين يكتبان نفس البيانات بدون خطة

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

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

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

استخدام كلا البروتوكولين معقول عندما تبقى أدوارهما منفصلة

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

تقسيم عملي واحد هو:

• SMB لمجلدات العائلة في ويندوز وماك
• SMB للوصول المباشر من الهاتف أو الجهاز اللوحي أو التلفاز
• NFS لنسخ Proxmox الاحتياطية والمضيفين في لينكس
• NFS لتركيب مكتبة خادم الوسائط في لينكس للقراءة فقط
• التخزين المحلي لقواعد بيانات التطبيقات وحالة التشغيل الحساسة

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

لا يجب تعريض أي من البروتوكولين مباشرةً للإنترنت

SMB و NFS مخصصان للشبكات المحلية الموثوقة أو مسارات الشبكة الخاصة. لا تقم بإعادة توجيه منفذ TCP 445 لـ SMB أو منافذ خدمة NFS من راوتر المنزل إلى الإنترنت العام.

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

التحول من SMB إلى NFS لا يجعل التعرض العام أكثر أمانًا. تعتمد الأمان على تحديد العملاء القابلين للوصول، تحديث البرامج، استخدام المصادقة المناسبة، وتجنب الخدمات العامة غير الضرورية.

قِس أكثر من سرعة النقل

يجب أن يستخدم اختبار المنزل العادل نفس مجموعة بيانات NAS، العميل، رابط الشبكة، والملفات لكلا البروتوكولين. وإلا، قد يكون النتيجة قياس مسارات تخزين مختلفة أو أجهزة عملاء مختلفة بدلاً من SMB و NFS.

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

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

استخدم هذا الترتيب في اتخاذ القرار

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

ثم فصل التصفح البشري عن الوصول بين الأجهزة. يستفيد مستخدمو المنزل عادةً من حسابات SMB ومتصفحات الملفات المألوفة. قد تستفيد خدمات لينكس المُدارة من توصيلات NFS والتحكم في الهوية الرقمية.

قبل تفعيل المشاركة النهائية، أجب عن هذه الأسئلة:

1. هل يتصفح مستخدمو ويندوز أو macOS الملفات؟
2. هل تحتاج الهواتف أو تطبيقات التلفاز إلى وصول مباشر؟
3. هل معظم العملاء أنظمة لينكس مُدارة؟
4. هل يمكن أن تبقى قيم UID و GID متسقة؟
5. هل يتضمن حمل العمل قواعد بيانات أو ملفات حساسة للقفل؟
6. هل سيكتب كل من SMB و NFS إلى نفس مجموعة البيانات؟
7. كيف يجب أن يتصرف التوصيل عندما يكون NAS غير متاح؟
8. هل يمكن إبقاء البروتوكول المختار بعيدًا تمامًا عن الإنترنت العام؟

لأغلب المنازل التي تحتوي على أجهزة مختلطة، ابدأ بـ SMB. أضف NFS فقط لحمل عمل محدد على لينكس، Proxmox، النسخ الاحتياطي، أو الحاويات التي تستفيد منه ويمكنك إدارتها بشكل متسق.

الخلاصة النهائية

عادةً ما يكون SMB الخيار الافتراضي الأفضل لـ Windows وmacOS والهواتف والأجهزة اللوحية والتلفزيونات الذكية والمجلدات العائلية المشتركة. يوفر توافقًا واسعًا ونموذج وصول قائم على الحساب يسهل شرحه لمستخدمي المنزل.

غالبًا ما يكون NFS الأنسب لخوادم Linux، وتخزين Proxmox، والنسخ الاحتياطية الآلية، وسير العمل بين الأجهزة. تعتمد مزاياه على إدارة صحيحة لقيم UID/GID، والتصديرات، وخيارات التثبيت، والملكية.

يمكنك تشغيل كلا البروتوكولين في المنزل، لكن يجب أن تكون مسؤولياتهما واضحة. استخدم SMB للأشخاص والأجهزة العميلة المختلطة، واستخدم NFS للبنية التحتية المدارة على Linux، وتجنب منح كلا البروتوكولين حق الكتابة غير المنضبط على نفس مجموعة البيانات.

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

هل NFS دائمًا أسرع من SMB؟

لا. قد يقدم NFS أداءً أفضل في بعض أعباء العمل بين Linux وLinux والملفات الصغيرة، بينما يمكن لـ SMB الحديث أن يقدم أداءً جيدًا جدًا على Windows وشبكات العملاء المختلطة. اختبر الملفات الفعلية والعملاء والتخزين والشبكة التي تخطط لاستخدامها.

هل يجب أن أستخدم SMB أم NFS لـ Plex وJellyfin؟

يمكن أن يعمل أي منهما. قد يستفيد خادم وسائط Linux من NFS أثناء عمليات فحص المكتبة الكبيرة، بينما قد يكون SMB أسهل عندما تصل تطبيقات Windows أو macOS أو مشغلات الوسائط إلى NAS مباشرة. عادةً ما يعمل البث الفيديوي الكبير بشكل جيد عبر كلا البروتوكولين.

هل NFS أفضل لـ Proxmox؟

يعد NFS خيارًا شائعًا وطبيعيًا لنسخ Proxmox الاحتياطية، وتخزين ISO، والقوالب، والتخزين المشترك. لا تزال أقراص VM وأعباء العمل ذات الكتابة العالية تتطلب اختبارًا للكمون وسلوك المزامنة وتوفر NAS.

هل يمكن لحاويات Docker استخدام مشاركات SMB؟

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

لماذا يظهر NFS رفض الإذن رغم أن المشاركة تم تثبيتها؟

قد يكون مسار التصدير والشبكة صحيحًا بينما لا تتطابق قيم UID/GID الخاصة بالعميل مع المالك أو المجموعة المسموح بها على NAS. يمكن أيضًا أن يغير تقليل صلاحيات الجذر أو تعيين التصدير المستخدم الفعلي.

هل يمكنني تمكين SMB وNFS على نفس المجلد؟

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

أي بروتوكول أكثر أمانًا في المنزل؟

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

أي بروتوكول يجب أن يختاره المبتدئ؟

اختر SMB عندما يشمل المنزل أنظمة Windows أو macOS أو الهواتف أو تطبيقات التلفاز. اختر NFS عندما تكون الأجهزة العميلة في الغالب أنظمة Linux وتشعر بالراحة في إدارة عمليات التثبيت وقيم UID/GID وأذونات التصدير.