تنسيقات اسم الحاسوب¶

يمكن تحديد عملاء NFS بعدة طرق:

single host

يمكنك تحديد مضيف إما باسم مختصر يتعرف عليه المُحلل، أو باسم النطاق المؤهل بالكامل، أو بعنوان IPv4، أو بعنوان IPv6. يجب ألا تكون عناوين IPv6 داخل أقواس مربعة في /etc/exports لئلا تُخلط مع مطابقات أحرف البدل لفئات المحارف.

IP networks

يمكنك أيضًا تصدير الأدلة إلى جميع المضيفين على شبكة IP (فرعية) في آن واحد. يُنجز هذا بتحديد زوج عنوان IP وقناع الشبكة كـ address/netmask حيث يمكن تحديد قناع الشبكة بتنسيق عشري منقط، أو كطول قناع متصل. على سبيل المثال، إلحاق `/255.255.252.0' أو `/22' بعنوان IPv4 الأساسي للشبكة يؤدي إلى شبكات فرعية متطابقة بـ 10 بتات للمضيف. يجب أن تستخدم عناوين IPv6 طول قناع متصل ويجب ألا تكون داخل أقواس مربعة لتجنب الخلط مع أحرف بدل فئات المحارف. لا تعمل أحرف البدل عموماً مع عناوين IP، رغم أنها قد تعمل بالصدفة عند فشل عمليات بحث DNS العكسية.

wildcards

قد تحتوي أسماء الحواسيب على أحرف البدل * و ??، أو قد تحتوي على قوائم فئات محارف داخل [أقواس مربعة]. يمكن استخدام هذا لجعل ملف exports أكثر إيجازاً؛ على سبيل المثال، يطابق *.cs.foo.edu كل المضيفين في النطاق cs.foo.edu. وبما أن هذه الأحرف تطابق أيضًا النقاط في اسم النطاق، فإن النمط المعطى سيطابق أيضًا كل المضيفين داخل أي نطاق فرعي من cs.foo.edu.

netgroups

يمكن إعطاء مجموعات الشبكة NIS كـ @group. يُراعى فقط جزء المضيف لكل عضو من أعضاء مجموعة الشبكة عند التحقق من العضوية. تُتجاهل أجزاء المضيف الفارغة أو تلك التي تحتوي على شرطة واحدة (-).

anonymous

يُحدد هذا بحرف * واحد (لا ينبغي الخلط بينه وبين إدخال wildcard أعلاه) وسيُطابق جميع العملاء.

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

أمن RPCSEC_GSS¶

يمكنك استخدام السلاسل الخاصة "gss/krb5" أو "gss/krb5i" أو "gss/krb5p" لتقييد الوصول إلى العملاء الذين يستخدمون أمن rpcsec_gss. ومع ذلك، هذا التركيب مهجور؛ ففي أنوية لينكس منذ 2.6.23، ينبغي عليك بدلاً من ذلك استخدام خيار التصدير "sec=":

sec=

خيار sec=، متبوعاً بقائمة من أنماط الأمن مفصولة بنقطتين رأسيتين، يقيد التصدير للعملاء الذين يستخدمون تلك الأنماط. تشمل أنماط الأمن المتاحة sys (المبدئي--بدون أمن تعمية)، و krb5 (للاستيثاق فقط)، و krb5i (حماية النزاهة)، و krb5p (حماية الخصوصية). لأغراض تفاوض نمط الأمن، الترتيب مهم: ينبغي إدراج الأنماط المفضلة أولاً. لا يهم ترتيب خيار sec= بالنسبة للخيارات الأخرى، ما لم ترغب في فرض بعض الخيارات بشكل مختلف بناءً على النمط. في هذه الحالة يمكنك تضمين خيارات sec= متعددة، وسيُفرض الخيارات التالية فقط للوصول باستخدام الأنماط المدرجة في خيار sec= المباشر الذي يسبقها. الخيارات الوحيدة المسموح بتغييرها بهذه الطريقة هي ro و rw و no_root_squash و root_squash و all_squash.

أمن طبقة النقل¶

يسمح خادوم NFS في لينكس باستخدام RPC-with-TLS (المعيار RFC 9289) لحماية حركة مرور RPC بينه وبين عملائه. بدلاً من ذلك، يمكن للمديرين تأمين حركة مرور NFS باستخدام شبكة افتراضية خاصة (VPN)، أو نفق ssh أو آلية مشابهة، بطريقة تكون شفافة للخادوم.

لتمكين استخدام RPC-with-TLS، يجب على مدير الخادوم تثبيت وضبط tlshd للتعامل مع طلبات المصافحة الخاصة بأمن طبقة النقل القادمة من النواة المحلية. يمكن للعملاء حينئذ اختيار استخدام RPC-with-TLS أو قد يستمرون في العمل بدونه.

قد يفرض المديرون استخدام RPC-with-TLS لحماية الوصول إلى صادرات فردية. هذا مفيد بشكل خاص عند استخدام أنماط أمن غير تعميوية مثل sec=sys. يمكن لخيار xprtsec=، متبوعاً بقائمة غير مرتبة من سياسات الأمن مفصولة بنقطتين رأسيتين، تقييد الوصول إلى التصدير للعملاء الذين تفاوضوا على أمن طبقة النقل فقط. تشمل سياسات أمن طبقة النقل المدعومة حالياً ما يلي:

none

يسمح الخادوم للعملاء بالوصول إلى التصدير دون استخدام أمن طبقة النقل.

tls

يسمح الخادوم للعملاء الذين تفاوضوا على جلسة RPC-with-TLS دون استيثاق النظراء (السرية فقط) بالوصول إلى التصدير. لا يُطلب من العملاء تقديم شهادة x.509 عند إنشاء جلسة أمن طبقة النقل.

mtls

يسمح الخادوم للعملاء الذين تفاوضوا على جلسة RPC-with-TLS مع استيثاق النظراء بالوصول إلى التصدير. يتطلب الخادوم من العملاء تقديم شهادة x.509 عند إنشاء جلسة أمن طبقة النقل.

إذا ضُبطت RPC-with-TLS ومُكِّنت ولم يُحدد الخيار xprtsec=، فإن الإعداد المبدئي للتصدير هو xprtsec=none:tls:mtls. مع هذا الإعداد، يسمح الخادوم للعملاء باستخدام أي آلية لأمن طبقة النقل أو عدم استخدام أي منها للوصول إلى التصدير.

خيارات عامة¶

تفهم exportfs خيارات التصدير التالية:

secure

يتطلب هذا الخيار أن تنشأ الطلبات التي لا تستخدم gss على منفذ إنترنت أقل من IPPORT_RESERVED (1024). هذا الخيار مُفعّل مبدئياً. لإيقافه، حدد insecure. (ملاحظة: النوى القديمة (قبل إصدار النواة المنبعي 4.17) كانت تفرض هذا المتطلب على طلبات gss أيضًا.)

rw

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

async

يسمح هذا الخيار لخادوم NFS بانتهاك بروتوكول NFS والرد على الطلبات قبل التزام أي تغييرات أجراها ذلك الطلب في التخزين المستقر (مثل محرك القرص).

عادة ما يؤدي استخدام هذا الخيار إلى تحسين الأداء، ولكن بتكلفة أن إعادة تشغيل الخادوم غير النظيفة (أي الانهيار) قد تتسبب في فقدان البيانات أو تلفها.

sync

الرد على الطلبات فقط بعد التزام التغييرات في التخزين المستقر (انظر async أعلاه).

في إصدارات nfs-utils حتى 1.0.0 وما قبلها، كان الخيار async هو المبدئي. في جميع الإصدارات بعد 1.0.0، أصبح sync هو المبدئي، ويجب طلب async صراحة إذا دعت الحاجة.

no_wdelay

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

nohide

يعتمد هذا الخيار على خيار يحمل الاسم نفسه موفر في IRIX NFS. عادةً، إذا صدّر خادوم نظامي ملفات أحدهما موصول على الآخر، فسيتعين على العميل وصل نظامي الملفات صراحةً للوصول إليهما. إذا وصل العميل النظام الأب فقط، فسيشاهد دليلاً فارغاً في المكان الذي وُصل فيه نظام الملفات الآخر. ذلك النظام ملفات "مخفي".

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

ومع ذلك، لا تتعامل بعض عملاء NFS بشكل جيد مع هذا الموقف، حيث يمكن -على سبيل المثال- أن يكون لملفين في نظام ملفات واحد ظاهر نفس رقم الـ inode.

الخيار nohide فعال حالياً فقط في تصديرات المضيف الفردي. لا يعمل بشكل موثوق مع تصديرات netgroup أو الشبكة الفرعية أو أحرف البدل.

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

يمكن تعطيل الخيار صراحة لـ NFSv2 و NFSv3 باستخدام hide.

هذا الخيار غير ذي صلة عند استخدام NFSv4. لا يخفي NFSv4 أبداً أنظمة الملفات التابعة. أي نظام ملفات مُصدَّر سيكون مرئياً في المكان المتوقع عند استخدام NFSv4.

crossmnt

هذا الخيار مشابه لـ nohide ولكنه يُمكّن العملاء من الوصول إلى جميع أنظمة الملفات الموصولة على نظام ملفات مُعلّم بـ crossmnt. وهكذا عندما يُوصل نظام ملفات تابع "B" على أب "A"، فإن ضبط crossmnt على "A" له تأثير مشابه لضبط "nohide" على B.

مع nohide يحتاج نظام الملفات التابع إلى أن يُصدّر صراحة. مع crossmnt لا يحتاج إلى ذلك. إذا لم يُصدّر تابع لنظام ملفات crossmnt صراحةً، فسيُصدّر ضمنياً بنفس خيارات تصدير الأب، باستثناء fsid=. هذا يجعل من المستحيل عدم تصدير تابع لنظام ملفات crossmnt. إذا كان يجب تصدير بعض أنظمة الملفات التابعة للأب وليس كلها، فيجب تصديرها صراحةً ولا ينبغي ضبط crossmnt على الأب.

يمكن للخيار nocrossmnt تعطيل crossmnt صراحةً إذا ضُبط سابقاً. نادراً ما يكون هذا مفيداً.

subtree_check

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

إذا صُدِّر دليل فرعي من نظام ملفات، ولم يُصدَّر نظام الملفات بالكامل، فعند وصول طلب NFS، يجب على الخادوم التحقق ليس فقط من أن الملف الذي جرى الوصول إليه موجود في نظام الملفات المناسب (وهذا سهل) ولكن أيضًا من أنه موجود في الشجرة المُصدَّرة (وهذا أصعب). يُسمى هذا الفحص subtree_check.

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

يُستخدم فحص الشجرة الفرعية أيضًا للتأكد من أن الملفات الموجودة داخل الأدلة التي لا يمكن إلا للجذر (root) الوصول إليها لا يمكن الوصول إليها إلا إذا صُدِّر نظام الملفات بـ no_root_squash (انظر أدناه)، حتى لو كان الملف نفسه يسمح بوصول أكثر عمومية.

لمزيد من المعلومات حول التبعات الأمنية، ارجع إلى قسم تصديرات الأدلة الفرعية.

كدليل عام، ينبغي تصدير نظام ملفات أدلة المستخدمين (home directory)، الذي يُصدَّر عادةً عند الجذر وقد يشهد الكثير من إعادة تسمية الملفات، مع تعطيل فحص الشجرة الفرعية. أما نظام الملفات الذي يكون للقراءة فقط غالباً، ولا يشهد الكثير من عمليات إعادة تسمية الملفات (مثل /usr أو /var) والذي قد تُصدَّر أدلته الفرعية، فينبغي على الأرجح تصديره مع تفعيل فحص الشجرة الفرعية.

المبدئي وهو تعطيل فحص الشجرة الفرعية، يمكن طلبه صراحةً باستخدام no_subtree_check.

قبل الإصدار 1.1.0 من nfs-utils، كان المبدئي هو subtree_check. منذ الإصدار 1.1.0، أصبح المبدئي هو no_subtree_check لأن فحص الشجرة الفرعية يميل إلى التسبب في مشاكل أكثر مما يستحق. إذا كنت تحتاج حقًا إلى فحص الشجرة الفرعية، فينبغي أن تضع ذلك الخيار صراحةً في ملف exports. إذا لم تضع أياً من الخيارين، فستحذرك exportfs من أن التغيير قد حدث.

sign_fh

يفرض هذا الخيار توقيع معالجات الملفات (filehandles) على التصدير. إذا ضُبط الخادوم بمفتاح سري لهذا الغرض، فستتضمن معالجات الملفات هاش (hash) للتحقق من أن الخادوم هو من أنشأ معالج الملف، وذلك للحماية من هجمات تخمين معالجات الملفات التي يمكنها تجاوز قيود الوصول المستندة إلى أسماء المسارات. لاحظ أنه بالنسبة لـ NFSv3، قد تتجاوز بعض أنظمة الملفات المُصدَّرة الحد الأقصى لحجم معالج الملف عند إضافة هاش التوقيع.

insecure_locks

no_auth_nlm

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

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

يمكن طلب السلوك المبدئي المتمثل في اشتراط الاستيثاق لطلبات NLM صراحةً باستخدام أي من المترادفات auth_nlm أو secure_locks.

mountpoint=path

mp

يجعل هذا الخيار من الممكن تصدير دليل فقط إذا وُصل بنجاح. إذا لم يُعطَ مسار (مثل mountpoint أو mp) فيجب أن تكون نقطة التصدير أيضًا نقطة وصل. إذا لم تكن كذلك، فلا تُصدَّر نقطة التصدير. يتيح لك هذا التأكد من أن الدليل الموجود أسفل نقطة الوصل لن يُصدَّر أبداً عن طريق الخطأ إذا، على سبيل المثال، فشل نظام الملفات في الوصل بسبب خطأ في القرص.

إذا أُعطي مسار (مثل mountpoint=/path أو mp=/path) فيجب أن يكون المسار المُحدد نقطة وصل لكي تُصدَّر نقطة التصدير.

fsid=num|root|uuid

يحتاج NFS إلى أن يكون قادراً على تحديد كل نظام ملفات يُصدِّره. عادةً سيستخدم UUID لنظام الملفات (إذا كان لنظام الملفات ذلك) أو رقم الجهاز للجهاز الذي يحمل نظام الملفات (إذا كان نظام الملفات مخزناً على الجهاز).

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

بالنسبة لـ NFSv4، هناك نظام ملفات مميز وهو جذر كل نظام ملفات مُصدَّر. يُحدد هذا بـ fsid=root أو fsid=0 وكلاهما يعني نفس الشيء تماماً.

يمكن تحديد أنظمة الملفات الأخرى بعدد صحيح صغير، أو UUID الذي يجب أن يحتوي على 32 رقماً ست عشرياً وعلامات ترقيم عشوائية.

نوى لينكس إصدار 2.6.20 وما قبلها لا تفهم إعداد UUID لذا يجب استخدام عدد صحيح صغير إذا كان يجب ضبط خيار fsid لمثل هذه النوى. دعم ضبط كل من رقم صغير و UUID مدعوم لذا يمكن جعل نفس الإعداد يعمل على النوى القديمة والجديدة على حد سواء.

nordirplus

سيعطل هذا الخيار معالجة طلب READDIRPLUS. عند ضبطه، تُرجع طلبات READDIRPLUS من عملاء NFS الخطأ NFS3ERR_NOTSUPP، ويعود العملاء لاستخدام READDIR. يؤثر هذا الخيار على عملاء NFSv3 فقط.

refer=path@host[+host][:path@host[+host]]

سيُوجَّه العميل الذي يشير إلى نقطة التصدير لاختيار موقع بديل لنظام الملفات من القائمة المُعطاة. (لاحظ أن الخادوم يجب أن يكون لديه نقطة وصل هنا، على الرغم من أن نظام ملفات مختلف غير مطلوب؛ لذا، على سبيل المثال، mount --bind /path /path كافٍ.)

يؤثر هذا الخيار على عملاء NFSv4 فقط. ستتجاهل العملاء الأخرى جميع أجزاء "refer=".

replicas=path@host[+host][:path@host[+host]]

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

pnfs

يُمكّن هذا الخيار استخدام ملحق pNFS إذا كان مستوى البروتوكول NFSv4.1 أو أعلى، وكان نظام الملفات يدعم تصديرات pNFS. مع pNFS يمكن للعملاء تجاوز الخادوم وإجراء الدخل/الخرج مباشرة إلى أجهزة التخزين. يمكن طلب المبدئي صراحة باستخدام الخيار no_pnfs.

security_label

مع ضبط هذا الخيار، سيتمكن العملاء الذين يستخدمون NFSv4.2 أو أعلى من ضبط واسترداد لصائق الأمان (مثل تلك المستخدمة بواسطة SELinux). لن يعمل هذا إلا إذا استخدم جميع العملاء سياسة أمان متسقة. لاحظ أن النوى المبكرة لم تكن تدعم خيار التصدير هذا، وبدلاً من ذلك كانت تُمكّن لصائق الأمان مبدئياً.

reexport=auto-fsidnum|predefined-fsidnum

يساعد هذا الخيار عندما يُعاد تصدير مشاركة NFS. نظراً لأن خادوم NFS يحتاج إلى معرف فريد لكل نظام ملفات مُصدَّر ولا يمكن لمشاركة NFS توفير ذلك، فعادةً ما تكون هناك حاجة إلى fsid يدوي. بمجرد استخدام crossmnt، لن يعمل تعيين fsid يدوياً بعد الآن. هذا هو المكان الذي يصبح فيه هذا الخيار مفيداً. سيقوم بتعيين fsid رقمي آلياً لمشاركات NFS المُصدَّرة. تُخزّن علاقات fsid والمسارات في قاعدة بيانات SQLite. إذا اختير auto-fsidnum، فسيُخصص fsid آلياً أيضًا. يفترض predefined-fsidnum أرقام fsid مخصصة مسبقاً وسيبحث عنها فقط. يعتمد هذا الخيار أيضًا على النواة، ستحتاج إلى إصدار نواة 5.19 على الأقل. نظراً لأن reexport= يمكنه تخصيص وتعيين fsids رقمية آلياً، فلم يعد من الممكن امتلاك fsids رقمية في صادرات أخرى بمجرد استخدام هذا الخيار في إدخال تصدير واحد على الأقل.

تُخزّن الارتباطات بين أرقام fsid والمسارات في قاعدة بيانات SQLite. لا تحرر أو تحذف قاعدة البيانات إلا إذا كنت تعرف بالضبط ما تفعله. predefined-fsidnum مفيد عندما تكون قد استخدمت auto-fsidnum من قبل ولا تريد تخزين إدخالات إضافية.

تخطيط مُعرّف المستخدم¶

يبني nfsd تحكمه في الوصول إلى الملفات على جهاز الخادوم بناءً على uid و gid المُقدمين في كل طلب NFS RPC. السلوك العادي الذي يتوقعه المستخدم هو أنه يمكنه الوصول إلى ملفاته على الخادوم تماماً كما يفعل على نظام ملفات عادي. يتطلب هذا استخدام نفس uids و gids على جهاز العميل والخادوم. هذا ليس صحيحاً دائماً، ولا هو مرغوب فيه دائماً.

في كثير من الأحيان، ليس من المرغوب فيه أن يُعامل مستخدم الجذر (root) على جهاز العميل كجذر أيضًا عند الوصول إلى الملفات على خادوم NFS. لهذا الغرض، يُخطط uid 0 عادةً إلى معرف مختلف: ما يسمى uid مجهول أو nobody. نمط التشغيل هذا (المسمى 'root squashing') هو المبدئي، ويمكن إيقافه باستخدام no_root_squash.

مبدئياً، تختار exportfs uid و gid بقيمة 65534 للوصول المكبوت (squashed). يمكن أيضًا تجاوز هذه القيم بواسطة الخيارين anonuid و anongid. أخيراً، يمكنك تخطيط جميع طلبات المستخدم إلى الـ uid المجهول عن طريق تحديد الخيار all_squash.

إليك القائمة الكاملة لخيارات التخطيط:

root_squash

خطط الطلبات من uid/gid 0 إلى uid/gid المجهول. لاحظ أن هذا لا ينطبق على أي uids أو gids أخرى قد تكون حساسة بنفس القدر، مثل المستخدم bin أو المجموعة staff.

no_root_squash

أوقف كبت الجذر (root squashing). هذا الخيار مفيد بشكل رئيسي للعملاء بلا أقراص.

all_squash

خطط جميع uids و gids إلى المستخدم المجهول. مفيد لأدلة FTP العامة المُصدَّرة بـ NFS، وأدلة التخزين المؤقت للأخبار، إلخ. الخيار المعاكس هو no_all_squash، وهو الإعداد المبدئي.

anonuid و anongid

تضبط هذه الخيارات صراحةً uid و gid للحساب المجهول. هذا الخيار مفيد بشكل أساسي لعملاء PC/NFS، حيث قد ترغب في أن تظهر جميع الطلبات وكأنها من مستخدم واحد. كمثال، انظر إدخال التصدير لـ /home/joe في قسم الأمثلة أدناه، الذي يخطط جميع الطلبات إلى uid 150 (الذي يُفترض أنه للمستخدم joe).

تصديرات الأدلة الفرعية¶

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

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

ثانياً، قد لا تُنفَّذ خيارات التصدير بالطريقة التي تتوقعها. على سبيل المثال، لن يعمل الخيار security_label على تصديرات الأدلة الفرعية، وإذا غيَّرت تصديرات الأدلة الفرعية المتداخلة خيارات security_label أو sec=، فعادةً سيرى عملاء NFSv4 خيارات التصدير الأب فقط. أيضًا، حيثما تختلف خيارات الأمان، قد يستخدم عميل ضار هجمات تخمين معالجات الملفات للوصول إلى الملفات من دليل فرعي واحد باستخدام خيارات من آخر.

جداول تصدير إضافية¶

بعد قراءة /etc/exports تقرأ exportfs الملفات الموجودة في دليل /etc/exports.d كجداول تصدير إضافية. تُؤخذ الملفات التي تنتهي بـ .exports فقط في الاعتبار. الملفات التي تبدأ بنقطة تُتجاهل. تنسيق جداول التصدير الإضافية هو نفس تنسيق /etc/exports