EXPORTS(5) فایلهای پیکربندی EXPORTS(5)

exports - پرونده پیکربندی سیستمهای پرونده اشتراکی سرور NFS

پرونده /etc/exports فهرست دایرکتوریها و گزینههای اشتراکگذاری سیستمهای پرونده سرور NFS به کلاینتها را پیکربندی میکند. این پرونده حاوی جدولی از سیستم‌های پرونده فیزیکی محلی در سرور NFS است که برای کلاینت‌های NFS قابل دسترسی هستند. محتویات این پرونده توسط مدیر سیستم سرور نگهداری می‌شود.

هر سیستم پرونده در این جدول دارای فهرستی از گزینه‌ها و یک فهرست کنترل دسترسی (ACL) است. این جدول توسط exportfs(8) برای ارائه اطلاعات به mountd(8) استفاده می‌شود.

قالب این پرونده مشابه پرونده exports در SunOS است. هر سطر شامل یک نقطه اشتراک (export point) و فهرستی از کلاینت‌های مجاز برای سوار کردن (mount) سیستم پرونده در آن نقطه است که با فاصله از هم جدا شده‌اند. بلافاصله پس از هر کلاینت فهرست‌شده، می‌تواند فهرستی از گزینه‌های اشتراک برای آن کلاینت که با کاما از هم جدا شده و داخل پرانتز قرار دارند، بیاید. هیچ فاصله‌ای بین نام کلاینت و فهرست گزینه‌های آن مجاز نیست.

همچنین، هر سطر می‌تواند پس از نام مسیر، دارای یک یا چند مشخصه برای گزینه‌های پیش‌فرض باشد که به صورت یک خط تیره ("-") به همراه یک فهرست گزینه نوشته می‌شود. این فهرست گزینه فقط برای تمام اشتراک‌های بعدی در همان سطر اعمال می‌شود.

سطرهای خالی نادیده گرفته می‌شوند. علامت هش ("#") نشان‌دهنده یک توضیح تا انتهای سطر است. مدخل‌ها می‌توانند با استفاده از یک بک‌اسلش در چندین سطر ادامه یابند. اگر نام یک اشتراک شامل فاصله باشد، باید داخل علامت‌های نقل قول دوتایی (گیومه) قرار گیرد. همچنین می‌توانید فاصله‌ها یا سایر کاراکترهای غیرمعمول در نام اشتراک را با استفاده از یک بک‌اسلش و به دنبال آن کد کاراکتر به صورت سه رقم هشت‌هشتی (octal) مشخص کنید.

برای اعمال تغییرات در این پرونده، دستور exportfs -ra را اجرا کنید یا سرور NFS را راه‌اندازی مجدد نمایید.

کلاینت‌های NFS را می‌توان به روش‌های مختلفی مشخص کرد:

میزبان تکی (single host)
می‌توانید یک میزبان را با یک نام خلاصه که توسط resolver شناسایی می‌شود، نام دامنه کامل (FQDN)، یک آدرس IPv4 یا یک آدرس IPv6 مشخص کنید. آدرس‌های IPv6 در /etc/exports نباید داخل قلاب [کروشه] قرار گیرند تا با تطبیق‌های الگوی کلاس کاراکتر اشتباه گرفته نشوند.
شبکه‌های آی‌پی (IP networks)
همچنین می‌توانید دایرکتوری‌ها را به طور همزمان برای تمام میزبان‌های یک (زیر)شبکه IP به اشتراک بگذارید. این کار با مشخص کردن یک جفت آدرس IP و ماسک شبکه به صورت address/netmask انجام می‌شود که در آن ماسک شبکه می‌تواند در قالب دهدهی نقطه‌دار یا طول ماسک پیوسته (CIDR) مشخص شود. به عنوان مثال، افزودن `/255.255.252.0' یا `/22' به آدرس پایه شبکه IPv4 منجر به زیرشبکه‌های یکسان با ۱۰ بیت میزبان می‌شود. آدرس‌های IPv6 باید از طول ماسک پیوسته استفاده کنند و نباید داخل قلاب قرار گیرند تا از سردرگمی با الگوهای کلاس کاراکتر جلوگیری شود. کاراکترهای عام (Wildcard) عموماً روی آدرس‌های IP کار نمی‌کنند، اگرچه ممکن است به صورت تصادفی در زمان شکست جستجوهای معکوس DNS کار کنند.
کاراکترهای عام (wildcards)
نام‌های دستگاه ممکن است حاوی کاراکترهای عام * و ? باشند، یا ممکن است شامل فهرست‌های کلاس کاراکتر درون [کروشه‌ها] باشند. این ویژگی می‌تواند برای فشرده‌تر کردن پرونده exports استفاده شود؛ برای نمونه، *.cs.foo.edu با تمام میزبان‌های موجود در دامنه cs.foo.edu مطابقت دارد. از آنجا که این کاراکترها با نقطه‌ها در یک نام دامنه نیز مطابقت دارند، الگوی داده‌شده با تمام میزبان‌های درون هر زیردامنه‌ای از cs.foo.edu نیز مطابقت خواهد داشت.
گروه‌های شبکه (netgroups)
گروه‌های شبکه NIS می‌توانند به صورت @group مشخص شوند. فقط بخش میزبان اعضای هر گروه شبکه هنگام بررسی عضویت در نظر گرفته می‌شود. بخش‌های میزبان خالی یا مواردی که شامل یک خط تیره منفرد (-) هستند نادیده گرفته می‌شوند.
ناشناس (anonymous)
این مورد با یک کاراکتر منفرد * مشخص می‌شود (با مدخل wildcard در بالا اشتباه نشود) و با تمام کلاینت‌ها مطابقت خواهد داشت.

اگر یک کلاینت با بیش از یکی از مشخصات بالا مطابقت داشته باشد، اولین تطابق از ترتیب فهرست بالا اولویت دارد - بدون توجه به ترتیبی که در سطر اشتراک ظاهر شده‌اند. با این حال، اگر یک کلاینت با بیش از یک مشخصه از همان نوع مطابقت داشته باشد (مثلاً دو گروه شبکه)، اولین تطابق از ترتیبی که در سطر اشتراک ظاهر شده‌اند اولویت خواهد داشت.

می‌توانید از رشته‌های ویژه "gss/krb5"، "gss/krb5i" یا "gss/krb5p" برای محدود کردن دسترسی به کلاینت‌هایی که از امنیت rpcsec_gss استفاده می‌کنند، بهره ببرید. با این حال، این نحو منسوخ شده است؛ در هسته‌های لینوکس از نسخه 2.6.23 به بعد، باید در عوض از گزینه اشتراک "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 را نصب و پیکربندی کند تا درخواست‌های دست‌تکانی (handshake) امنیت لایه انتقال را از هسته محلی مدیریت نماید. سپس کلاینت‌ها می‌توانند استفاده از RPC-with-TLS را انتخاب کنند یا به کار بدون آن ادامه دهند.

مدیران سیستم ممکن است استفاده از RPC-with-TLS را برای حفاظت از دسترسی به اشتراک‌های جداگانه الزامی کنند. این امر به ویژه هنگام استفاده از گونه‌های امنیتی غیررمزنگاری مانند sec=sys بسیار مفید است. گزینه xprtsec= که پس از آن فهرستی بدون ترتیب از سیاست‌های امنیتی جداشده با دونقطه می‌آید، می‌تواند دسترسی به اشتراک را تنها به کلاینت‌هایی محدود کند که امنیت لایه انتقال را مذاکره کرده‌اند. سیاست‌های امنیت لایه انتقال پشتیبانی‌شده در حال حاضر عبارتند از:

سرور به کلاینت‌ها اجازه می‌دهد بدون استفاده از امنیت لایه انتقال به اشتراک دسترسی داشته باشند.
سرور به کلاینت‌هایی که یک نشست RPC-with-TLS بدون احراز هویت همتا (فقط محرمانگی) مذاکره کرده‌اند، اجازه دسترسی به اشتراک را می‌دهد. کلاینت‌ها هنگام برقراری نشست امنیت لایه انتقال ملزم به ارائه گواهی x.509 نیستند.
سرور به کلاینت‌هایی که یک نشست RPC-with-TLS با احراز هویت همتا مذاکره کرده‌اند، اجازه دسترسی به اشتراک را می‌دهد. سرور کلاینت‌ها را هنگام برقراری نشست امنیت لایه انتقال ملزم به ارائه گواهی x.509 می‌کند.

اگر RPC-with-TLS پیکربندی و فعال شده باشد و گزینه xprtsec= مشخص نشده باشد، تنظیم پیش‌فرض برای یک اشتراک xprtsec=none:tls:mtls است. با این تنظیم، سرور به کلاینت‌ها اجازه می‌دهد از هر سازوکار امنیت لایه انتقال یا بدون هیچ‌کدام برای دسترسی به اشتراک استفاده کنند.

دستور exportfs گزینه‌های اشتراک زیر را پشتیبانی می‌کند:

این گزینه مستلزم آن است که درخواست‌هایی که از gss استفاده نمی‌کنند از درگاه اینترنتی کمتر از IPPORT_RESERVED (1024) سرچشمه بگیرند. این گزینه به طور پیش‌فرض فعال است. برای غیرفعال کردن آن، insecure را مشخص کنید. (توجه: هسته‌های قدیمی‌تر (قبل از نسخه بالادستی 4.17) این الزام را بر روی درخواست‌های gss نیز اعمال می‌کردند.)
اجازه درخواست‌های خواندن و نوشتن روی این حجم NFS را می‌دهد. پیش‌فرض این است که هر درخواستی که سیستم پرونده را تغییر دهد رد شود. این را می‌توان به صورت صریح با استفاده از گزینه ro نیز تعیین کرد.
این گزینه به سرور NFS اجازه می‌دهد پروتکل NFS را نقض کرده و قبل از اینکه هرگونه تغییر ایجادشده توسط آن درخواست روی حافظه پایدار (مانند دیسک‌درایو) ثبت شود، به درخواست‌ها پاسخ دهد.

استفاده از این گزینه معمولاً کارایی را بهبود می‌بخشد، اما به قیمت این که راه‌اندازی مجدد ناگهانی سرور (مانند کرش کردن) می‌تواند باعث از دست رفتن یا خرابی داده‌ها شود.

پاسخ به درخواست‌ها فقط پس از آنکه تغییرات در حافظه پایدار ثبت شدند ارسال می‌شود (به async در بالا مراجعه کنید).

در نسخه‌های nfs-utils تا و شامل 1.0.0، گزینه async پیش‌فرض بود. در تمام نسخه‌های بعد از 1.0.0، گزینه sync پیش‌فرض است و در صورت نیاز، async باید به صورت صریح درخواست شود.

این گزینه اگر async نیز تنظیم شده باشد تاثیری ندارد. سرور NFS به طور معمول ثبت یک درخواست نوشتن روی دیسک را کمی به تاخیر می‌اندازد اگر مشکوک باشد که درخواست نوشتن مرتبط دیگری در حال انجام است یا ممکن است به زودی برسد. این امر اجازه می‌دهد چندین درخواست نوشتن با یک عملیات روی دیسک ثبت شوند که می‌تواند کارایی را بهبود بخشد. اگر یک سرور NFS عمدتاً درخواست‌های کوچک و غیرمرتبط دریافت کند، این رفتار در واقع می‌تواند کارایی را کاهش دهد، بنابراین no_wdelay برای خاموش کردن آن در دسترس است. حالت پیش‌فرض را می‌توان به صراحت با گزینه wdelay درخواست کرد.
این گزینه بر اساس گزینه‌ای با همین نام در IRIX NFS طراحی شده است. به طور معمول، اگر یک سرور دو سیستم پرونده را به اشتراک بگذارد که یکی روی دیگری سوار شده است، کلاینت باید هر دو سیستم پرونده را به طور صریح سوار کند تا به آنها دسترسی پیدا کند. اگر فقط والد را سوار کند، یک دایرکتوری خالی در جایی که سیستم پرونده دیگر سوار شده است خواهد دید. آن سیستم پرونده "پنهان" (hidden) است.

تنظیم گزینه nohide روی یک سیستم پرونده باعث می‌شود که پنهان نباشد و یک کلاینت با مجوز مناسب بتواند از والد به آن سیستم پرونده بدون متوجه شدن تغییر حرکت کند.

با این حال، برخی از کلاینت‌های NFS به خوبی با این وضعیت کنار نمی‌آیند، زیرا برای نمونه ممکن است دو فایل در یک سیستم پرونده ظاهری دارای شماره inode یکسان باشند.

گزینه nohide در حال حاضر فقط روی اشتراک‌های میزبان تکی (single host) موثر است. این گزینه با اشتراک‌های گروه شبکه، زیرشبکه یا کاراکتر عام به طور قابل اعتماد کار نمی‌کند.

این گزینه می‌تواند در برخی شرایط بسیار مفید باشد، اما باید با احتیاط و فقط پس از تایید اینکه سیستم کلاینت به طور موثر با این وضعیت هماهنگ است استفاده شود.

این گزینه را می‌توان برای NFSv2 و NFSv3 به طور صریح با hide غیرفعال کرد.

این گزینه هنگام استفاده از NFSv4 کاربردی ندارد. نسخه NFSv4 هرگز سیستم‌های پرونده زیرمجموعه را پنهان نمی‌کند. هر سیستم پرونده‌ای که به اشتراک گذاشته شود در هنگام استفاده از NFSv4 در جایی که انتظار می‌رود قابل مشاهده خواهد بود.

این گزینه مشابه nohide است اما این امکان را برای کلاینت‌ها فراهم می‌کند تا به تمام سیستم‌های پرونده سوار شده روی یک سیستم پرونده نشانه‌گذاری‌شده با crossmnt دسترسی پیدا کنند. بنابراین هنگامی که یک سیستم پرونده فرزند "B" روی والد "A" سوار می‌شود، تنظیم crossmnt روی "A" تاثیری مشابه با تنظیم "nohide" روی B دارد.

با nohide سیستم پرونده فرزند باید به طور صریح به اشتراک گذاشته شود. با crossmnt نیازی به این کار نیست. اگر فرزند یک پرونده crossmnt به طور صریح به اشتراک گذاشته نشود، آنگاه به طور ضمنی با همان گزینه‌های اشتراک والد، به جز fsid=، به اشتراک گذاشته خواهد شد. این امر باعث می‌شود که عدم اشتراک‌گذاری یک فرزند از یک سیستم پرونده crossmnt غیرممکن شود. اگر برخی از سیستم‌های پرونده زیرمجموعه یک والد و نه همه آنها قرار است به اشتراک گذاشته شوند، باید به طور صریح به اشتراک گذاشته شوند و والد نباید crossmnt داشته باشد.

گزینه nocrossmnt می‌تواند در صورتی که crossmnt قبلاً تنظیم شده باشد، آن را به صراحت غیرفعال کند. این به ندرت کاربرد دارد.

این گزینه بررسی زیردرخت را فعال می‌کند که می‌تواند مزایای امنیتی ملایمی داشته باشد، اما در برخی شرایط می‌تواند قابلیت اطمینان را کاهش دهد.

اگر یک زیردایرکتوری از یک سیستم پرونده به اشتراک گذاشته شود، اما کل سیستم پرونده به اشتراک گذاشته نشود، هر زمان که یک درخواست NFS برسد، سرور باید بررسی کند نه تنها فایل مورد دسترسی در سیستم پرونده مناسب قرار دارد (که آسان است) بلکه در درخت به اشتراک گذاشته شده نیز قرار دارد (که سخت‌تر است). این بررسی subtree_check نامیده می‌شود.

برای انجام این بررسی، سرور باید اطلاعاتی درباره مکان فایل در "filehandle" که به کلاینت داده می‌شود، بگنجاند. این می‌تواند هنگام دسترسی به فایل‌هایی که در حین باز بودن توسط یک کلاینت تغییر نام می‌یابند، مشکلاتی ایجاد کند (اگرچه در بسیاری از موارد ساده همچنان کار خواهد کرد).

بررسی زیردرخت همچنین برای اطمینان از این است که فایل‌های درون دایرکتوری‌هایی که فقط ریشه به آنها دسترسی دارد، تنها در صورتی قابل دسترسی باشند که سیستم پرونده با no_root_squash (به زیر مراجعه کنید) به اشتراک گذاشته شده باشد، حتی اگر خود فایل دسترسی عمومی‌تری را مجاز بداند.

برای اطلاعات بیشتر در مورد پیامدهای امنیتی، به بخش اشتراک زیردایرکتوری‌ها مراجعه کنید.

به عنوان یک راهنمای کلی، سیستم پرونده دایرکتوری خانگی که به طور معمول در ریشه به اشتراک گذاشته می‌شود و ممکن است تغییر نام‌های زیادی در فایل‌ها را مشاهده کند، باید با بررسی زیردرخت غیرفعال به اشتراک گذاشته شود. یک سیستم پرونده که عمدتاً فقط‌خواندنی است و حداقل تغییر نام‌های زیادی در آن رخ نمی‌دهد (مانند /usr یا /var) و برای آن ممکن است زیردایرکتوری‌ها به اشتراک گذاشته شوند، احتمالاً باید با بررسی‌های زیردرخت فعال به اشتراک گذاشته شود.

حالت پیش‌فرض غیرفعال بودن بررسی‌های زیردرخت را می‌توان به صراحت با no_subtree_check درخواست کرد.

قبل از انتشار نسخه 1.1.0 بسته nfs-utils، حالت پیش‌فرض subtree_check بود. از زمان انتشار 1.1.0، پیش‌فرض no_subtree_check است زیرا بررسی زیردرخت معمولاً بیش از ارزشش دردسر ایجاد می‌کند. اگر واقعاً به بررسی زیردرخت نیاز دارید، باید آن گزینه را صریحاً در پرونده exports قرار دهید. اگر هیچ‌یک از این دو گزینه را قرار ندهید، exportfs به شما هشدار می‌دهد که این تغییر رخ داده است.

این گزینه (هر دو نام مترادف هستند) به سرور NFS می‌گوید که برای درخواست‌های قفل‌گذاری (یعنی درخواست‌هایی که از پروتکل NLM استفاده می‌کنند) نیازی به احراز هویت نداشته باشد. به طور معمول، سرور NFS نیاز دارد که یک درخواست قفل دارای گواهی اعتباری برای کاربری باشد که دسترسی خواندن به فایل دارد. با این فلگ هیچ بررسی دسترسی انجام نخواهد شد.

پیاده‌سازی‌های اولیه کلاینت NFS همراه با درخواست‌های قفل گواهی اعتباری ارسال نمی‌کردند، و هنوز کلاینت‌های NFS زیادی وجود دارند که بر اساس پیاده‌سازی‌های قدیمی هستند. اگر متوجه شدید فقط می‌توانید فایل‌هایی را قفل کنید که برای همه قابل خواندن هستند، از این فلگ استفاده کنید.

رفتار پیش‌فرض الزام به احراز هویت برای درخواست‌های NLM را می‌توان با هر یک از نام‌های مترادف auth_nlm یا secure_locks به صراحت درخواست کرد.

این گزینه امکان اشتراک‌گذاری یک دایرکتوری را تنها در صورتی که با موفقیت سوار شده باشد فراهم می‌کند. اگر هیچ مسیری داده نشود (مانند mountpoint یا mp) آنگاه نقطه اشتراک باید یک نقطه سوار کردن (mount point) نیز باشد. اگر نباشد، نقطه اشتراک صادر نمی‌شود. این به شما اطمینان می‌دهد که اگر سیستم پرونده به عنوان مثال به دلیل خطای دیسک سوار نشود، دایرکتوری زیر نقطه سوار شدن هرگز به اشتباه به اشتراک گذاشته نخواهد شد.

اگر مسیری داده شود (مانند mountpoint=/path یا mp=/path) آنگاه مسیر تعیین‌شده باید یک نقطه سوار کردن باشد تا نقطه اشتراک به اشتراک گذاشته شود.

پروتکل NFS باید بتواند هر سیستم پرونده‌ای را که به اشتراک می‌گذارد شناسایی کند. به طور معمول از یک UUID برای سیستم پرونده (در صورت وجود چنین چیزی) یا شماره دستگاه مربوط به دستگاه نگه‌دارنده سیستم پرونده (اگر سیستم پرونده روی دستگاه ذخیره شده باشد) استفاده می‌کند.

از آنجا که همه سیستم‌های پرونده روی دستگاه‌ها ذخیره نمی‌شوند، و همه آنها دارای UUID نیستند، گاهی لازم است صریحاً به NFS بگویید چگونه یک سیستم پرونده را شناسایی کند. این کار با گزینه fsid= انجام می‌شود.

برای NFSv4، یک سیستم پرونده متمایز وجود دارد که ریشه تمام سیستم‌های پرونده به اشتراک گذاشته شده است. این با fsid=root یا fsid=0 مشخص می‌شود که هر دو دقیقاً به یک معنی هستند.

سایر سیستم‌های پرونده را می‌توان با یک عدد صحیح کوچک یا یک UUID که باید شامل ۳۲ رقم هگزادسیمال و علائم نگارشی دلخواه باشد شناسایی کرد.

نسخه‌های هسته لینوکس 2.6.20 و قبل‌تر تنظیمات UUID را متوجه نمی‌شوند، بنابراین اگر نیاز به تنظیم گزینه fsid برای چنین هسته‌هایی باشد، باید از یک عدد صحیح کوچک استفاده شود. تنظیم همزمان یک عدد کوچک و یک UUID پشتیبانی می‌شود، بنابراین می‌توان همان پیکربندی را به کار برد تا روی هسته‌های قدیمی و جدید یکسان کار کند.

این گزینه پردازش درخواست‌های READDIRPLUS را غیرفعال می‌کند. هنگامی که تنظیم شود، درخواست‌های READDIRPLUS از کلاینت‌های NFS خطای NFS3ERR_NOTSUPP را برمی‌گردانند و کلاینت‌ها به READDIR برمی‌گردند. این گزینه فقط بر کلاینت‌های NFSv3 اثر می‌گذارد.
کلاینتی که به نقطه اشتراک مراجعه می‌کند، هدایت خواهد شد تا از فهرست داده‌شده مکانی جایگزین برای سیستم پرونده انتخاب کند. (توجه داشته باشید که سرور باید یک نقطه سوار کردن در اینجا داشته باشد، اگرچه به سیستم پرونده متفاوتی نیاز نیست؛ بنابراین به عنوان مثال، mount --bind /path /path کفایت می‌کند.)

این گزینه فقط بر کلاینت‌های NFSv4 اثر می‌گذارد. سایر کلاینت‌ها تمام بخش‌های "refer=" را نادیده می‌گیرند.

اگر کلاینت مکان‌های جایگزین برای نقطه اشتراک را درخواست کند، این فهرست از جایگزین‌ها به آن داده می‌شود. (توجه داشته باشید که تکرار واقعی سیستم پرونده باید در جای دیگری مدیریت شود.)
این گزینه در صورتی که سطح پروتکل NFSv4.1 یا بالاتر باشد و سیستم پرونده از اشتراک‌های pNFS پشتیبانی کند، استفاده از افزونه pNFS را فعال می‌سازد. با pNFS، کلاینت‌ها می‌توانند سرور را دور بزنند و عملیات ورودی/خروجی (I/O) را مستقیماً روی دستگاه‌های ذخیره‌سازی انجام دهند. حالت پیش‌فرض را می‌توان با گزینه no_pnfs صریحاً درخواست کرد.
با تنظیم این گزینه، کلاینت‌هایی که از NFSv4.2 یا بالاتر استفاده می‌کنند قادر خواهند بود برچسب‌های امنیتی (مانند برچسب‌های مورد استفاده در SELinux) را تنظیم و دریافت کنند. این تنها در صورتی کار خواهد کرد که همه کلاینت‌ها از یک سیاست امنیتی سازگار استفاده کنند. توجه داشته باشید که هسته‌های اولیه از این گزینه اشتراک پشتیبانی نمی‌کردند و در عوض برچسب‌های امنیتی را به طور پیش‌فرض فعال می‌کردند.
این گزینه هنگام باز-اشتراک‌گذاری (re-export) یک اشتراک NFS کمک می‌کند. از آنجا که سرور NFS برای هر سیستم پرونده اشتراکی به یک شناسه یکتا نیاز دارد و یک اشتراک NFS نمی‌تواند چنین شناسه‌ای را ارائه دهد، معمولاً یک fsid دستی مورد نیاز است. به محض استفاده از crossmnt، تخصیص دستی fsid دیگر کار نخواهد کرد. اینجاست که این گزینه مفید واقع می‌شود. این گزینه به طور خودکار یک fsid عددی را به اشتراک‌های NFS اختصاص می‌دهد. روابط fsid و مسیر در یک پایگاه داده SQLite ذخیره می‌شوند. اگر auto-fsidnum انتخاب شود، fsid نیز به طور خودکار تخصیص می‌یابد. predefined-fsidnum اعداد fsid از پیش تخصیص‌داده‌شده را فرض می‌کند و فقط آنها را جستجو می‌نماید. این گزینه همچنین به هسته بستگی دارد؛ شما حداقل به هسته نسخه 5.19 نیاز خواهید داشت. از آنجا که reexport= می‌تواند به طور خودکار fsidهای عددی را تخصیص داده و اختصاص دهد، به محض استفاده از این گزینه در حداقل یک مدخل اشتراک، دیگر امکان داشتن fsidهای عددی در سایر اشتراک‌ها وجود ندارد.

ارتباط بین شماره‌های fsid و مسیرها در یک پایگاه داده SQLite ذخیره می‌شود. پایگاه داده را ویرایش یا حذف نکنید مگر اینکه دقیقاً بدانید چه کاری انجام می‌دهید. predefined-fsidnum زمانی مفید است که قبلاً از auto-fsidnum استفاده کرده‌اید و نمی‌خواهید مدخل‌های بیشتری ذخیره شوند.

دیمن nfsd کنترل دسترسی خود به فایل‌های روی ماشین سرور را بر اساس uid و gid ارائه‌شده در هر درخواست NFS RPC قرار می‌دهد. رفتار معمولی که یک کاربر انتظار دارد این است که بتواند همان‌طور که در یک سیستم پرونده عادی دسترسی دارد، به فایل‌های خود در سرور نیز دسترسی داشته باشد. این امر مستلزم آن است که از همان uidها و gidها در ماشین کلاینت و سرور استفاده شود. این همیشه درست نیست، و همیشه هم مطلوب نیست.

بسیار پیش می‌آید که مطلوب نیست کاربر ریشه (root) در یک ماشین کلاینت، هنگام دسترسی به فایل‌ها در سرور NFS نیز به عنوان ریشه در نظر گرفته شود. برای این منظور، معمولاً uid 0 به یک شناسه متفاوت نگاشت می‌شود: شناسه اصطلاحاً ناشناس یا nobody. این حالت عملیاتی (که «root squashing» نامیده می‌شود) حالت پیش‌فرض است و می‌توان آن را با no_root_squash خاموش کرد.

به طور پیش‌فرض، exportfs شناسه uid و gid برابر با ۶۵۵۳۴ را برای دسترسی خردشده (squashed) انتخاب می‌کند. این مقادیر همچنین می‌توانند توسط گزینه‌های anonuid و anongid بازنویسی شوند. در نهایت، می‌توانید تمام درخواست‌های کاربر را با مشخص کردن گزینه all_squash به شناسه کاربری ناشناس نگاشت کنید.

در اینجا فهرست کامل گزینه‌های نگاشت آمده است:

درخواست‌ها از uid/gid برابر با 0 را به uid/gid ناشناس نگاشت می‌کند. توجه داشته باشید که این گزینه برای سایر uidها یا gidهایی که ممکن است به همان اندازه حساس باشند، مانند کاربر bin یا گروه staff اعمال نمی‌شود.
حالت خرد کردن ریشه (root squashing) را خاموش می‌کند. این گزینه عمدتاً برای کلاینت‌های بدون دیسک مفید است.
تمام uidها و gidها را به کاربر ناشناس نگاشت می‌کند. برای دایرکتوری‌های FTP عمومی به اشتراک گذاشته شده با NFS، دایرکتوری‌های news spool و غیره مفید است. گزینه مخالف no_all_squash است که تنظیم پیش‌فرض می‌باشد.
این گزینه‌ها صریحاً uid و gid حساب کاربری ناشناس را تعیین می‌کنند. این گزینه عمدتاً برای کلاینت‌های PC/NFS مفید است، جایی که ممکن است بخواهید تمام درخواست‌ها از طرف یک کاربر به نظر برسند. به عنوان مثال، مدخل اشتراک برای /home/joe در بخش مثال زیر را در نظر بگیرید که تمام درخواست‌ها را به uid 150 نگاشت می‌کند (که ظاهراً متعلق به کاربر joe است).

به طور معمول شما فقط باید ریشه یک سیستم پرونده را به اشتراک بگذارید. سرور NFS همچنین به شما امکان می‌دهد یک زیردایرکتوری از یک سیستم پرونده را به اشتراک بگذارید، اما این کار معایبی دارد:

اولاً، ممکن است برای یک کاربر مخرب این امکان وجود داشته باشد که با حدس زدن دستگیره فایل (filehandle) برای سایر فایل‌ها، به فایل‌های روی سیستم پرونده در خارج از زیردایرکتوری اشتراکی دسترسی پیدا کند. در برخی موارد، یک کاربر مخرب ممکن است بتواند با جایگزین کردن زیردایرکتوری به اشتراک گذاشته شده با یک پیوند نمادین به هر دایرکتوری دیگر، به فایل‌های روی سیستم‌های پرونده دیگری که به اشتراک گذاشته نشده‌اند نیز دسترسی یابد. تنها راه برای جلوگیری از این امر استفاده از گزینه subtree_check است که خود می‌تواند مشکلات دیگری ایجاد کند.

ثانیاً، گزینه‌های اشتراک ممکن است آن‌طور که انتظار دارید اعمال نشوند. به عنوان مثال، گزینه security_label روی اشتراک‌های زیردایرکتوری کار نخواهد کرد، و اگر اشتراک‌های زیردایرکتوری تودرتو گزینه‌های security_label یا sec= را تغییر دهند، کلاینت‌های NFSv4 معمولاً فقط گزینه‌های موجود در اشتراک والد را مشاهده می‌کنند. همچنین، در جایی که گزینه‌های امنیتی تفاوت دارند، یک کلاینت مخرب ممکن است از حملات حدس زدن دستگیره فایل برای دسترسی به فایل‌های یک زیردایرکتوری با استفاده از گزینه‌های زیردایرکتوری دیگر استفاده کند.

پس از خواندن /etc/exports برنامه exportfs پرونده‌های موجود در دایرکتوری /etc/exports.d را به عنوان جدول‌های اشتراک اضافی می‌خواند. فقط پرونده‌هایی که به .exports ختم می‌شوند در نظر گرفته می‌شوند. پرونده‌هایی که با نقطه شروع می‌شوند نادیده گرفته می‌شوند. قالب جدول‌های اشتراک اضافی مشابه /etc/exports است.

# sample /etc/exports file
/               master(rw) trusty(rw,no_root_squash)
/projects       proj*.local.domain(rw)
/usr            *.local.domain(ro) @trusted(rw)
/home/joe       pc001(rw,all_squash,anonuid=150,anongid=100)
/pub            *(ro,insecure,all_squash)
/srv/www        -sync,rw server @trusted @external(ro)
/foo            2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw)
/build          buildhost[0-9].local.domain(rw)

سطر اول کل سیستم پرونده را به دستگاه‌های master و trusty به اشتراک می‌گذارد. علاوه بر دسترسی نوشتن، تمام عملیات‌های نگاشت ناشناس ریشه (uid squashing) برای میزبان trusty خاموش است. مدخل دوم و سوم مثال‌هایی برای نام‌های میزبان دارای کاراکتر عام و گروه‌های شبکه را نشان می‌دهند (این مدخل `@trusted' است). سطر چهارم مدخل مربوط به کلاینت PC/NFS مورد بحث در بالا را نشان می‌دهد. سطر ۵ دایرکتوری عمومی FTP را برای هر میزبانی در جهان صادر می‌کند و تمام درخواست‌ها را تحت حساب کاربری nobody اجرا می‌نماید. گزینه insecure در این مدخل همچنین به کلاینت‌هایی با پیاده‌سازی‌های NFS که از یک درگاه رزرو شده برای NFS استفاده نمی‌کنند، اجازه دسترسی می‌دهد. سطر ششم یک دایرکتوری را به صورت خواندن-نوشتن به دستگاه 'server' و همچنین گروه شبکه `@trusted' و به صورت فقط‌خواندنی به گروه شبکه `@external' به اشتراک می‌گذارد که هر سه سوار کردن با گزینه `sync' فعال هستند. سطر هفتم یک دایرکتوری را به هر دو زیرشبکه IPv6 و IPv4 صادر می‌کند. سطر هشتم تطابق کاراکتر عام کلاس کاراکتر را نشان می‌دهد.

/etc/exports /etc/exports.d

exportfs(8), netgroup(5), mountd(8), nfsd(8), showmount(8), tlshd(8).

مه ۲۰۲۵ nfs-utils