گزینه‌های پشتیبانی‌شده در تمام نسخه‌ها (Options supported by all versions)

این گزینه‌ها برای استفاده با هر نسخه از NFS معتبر هستند.

nfsvers=n

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

vers=n

این گزینه جایگزینی برای گزینه nfsvers است. این گزینه جهت سازگاری با سایر سیستم‌های عامل گنجانده شده است.

soft / softerr / hard

رفتار بازیابی کلاینت NFS را پس از اتمام مهلت زمانی (timeout) یک درخواست NFS تعیین می‌کند. اگر هیچ گزینه‌ای مشخص نشود (یا اگر گزینه hard مشخص شود)، درخواست‌های NFS تا بی‌نهایت تکرار می‌شوند. اگر هر یک از گزینه‌های soft یا softerr مشخص شوند، کلاینت NFS پس از ارسال retrans تلاش ناموفق مجدد، درخواست NFS را با خطا پایان می‌دهد و باعث می‌شود کلاینت NFS خطای EIO (برای گزینه soft) یا ETIMEDOUT (برای گزینه softerr) را به برنامه فراخواننده بازگرداند.

توجه: پایان مهلت زمانی به اصطلاح "نرم" (soft) در برخی موارد می‌تواند باعث تخریب پنهان داده‌ها شود. از این رو، از گزینه soft یا softerr تنها زمانی استفاده کنید که پاسخ‌دهی کلاینت مهم‌تر از یکپارچگی داده‌ها باشد. استفاده از NFS روی TCP یا افزایش مقدار گزینه retrans ممکن است برخی از خطرات ناشی از استفاده از گزینه soft یا softerr را کاهش دهد.

softreval / nosoftreval

در مواردی که سرور NFS از دسترس خارج شده است، ممکن است مفید باشد که پس از به پایان رسیدن تلاش‌های retrans برای اعتبارسنجی مجدد کش، به کلاینت NFS اجازه داده شود به ارائه مسیرها و ویژگی‌ها از حافظه موقت (کش) ادامه دهد. این ویژگی ممکن است برای مثال هنگام تلاش برای لغو اتصال (unmount) یک درخت سیستم پرونده از سروری که برای همیشه از کار افتاده، مفید واقع شود.

امکان ترکیب softreval با گزینه اتصال soft وجود دارد، که در این صورت عملیاتی که امکان ارائه آن‌ها از کش وجود ندارد، پس از تلاش‌های retrans با اتمام مهلت زمانی متوقف شده و خطایی بازمی‌گردانند. ترکیب با گزینه اتصال پیش‌فرض hard به این معنی است که آن عملیات کش‌نشده تا زمان دریافت پاسخ از سرور، به تلاش مجدد ادامه می‌دهند.

نکته: گزینه اتصال پیش‌فرض nosoftreval است که استفاده از نسخه پشتیبان کش در صورت شکست اعتبارسنجی را ممنوع می‌کند و در عوض از رفتار دیکته‌شده توسط گزینه اتصال hard یا soft پیروی می‌نماید.

intr / nointr

این گزینه برای سازگاری با نسخه‌های پیشین ارائه شده است. پس از هسته 2.6.25 نادیده گرفته می‌شود.

timeo=n

مدت زمان به دسی‌ثانیه (ده‌یک ثانیه) که کلاینت NFS قبل از تکرار درخواست NFS، منتظر پاسخ می‌ماند.

برای NFS روی TCP، مقدار پیش‌فرض timeo برابر با 600 (۶۰ ثانیه) است. کلاینت NFS یک بازگشت خطی (linear backoff) انجام می‌دهد: پس از هر ارسال مجدد، مهلت زمانی به میزان timeo افزایش می‌یابد تا حداکثر به ۶۰۰ ثانیه برسد.

با این حال، برای NFS روی UDP، کلاینت از یک الگوریتم تطبیقی برای برآورد مقدار مهلت زمانی مناسب برای انواع درخواست‌های پرکاربرد (مانند درخواست‌های READ و WRITE) استفاده می‌کند، اما برای انواع درخواست‌های کم‌کاربرد (مانند درخواست‌های FSINFO) از تنظیم timeo بهره می‌برد. اگر گزینه timeo مشخص نشده باشد، انواع درخواست‌های کم‌کاربرد پس از ۱.۱ ثانیه تکرار می‌شوند. پس از هر ارسال مجدد، کلاینت NFS مهلت زمانی را برای آن درخواست دو برابر می‌کند تا به حداکثر ۶۰ ثانیه برسد.

هر مقدار timeo بزرگتر از مقدار پیش‌فرض، به مقدار پیش‌فرض بازگردانده می‌شود. برای TCP و RDMA مقدار پیش‌فرض 600 (۶۰ ثانیه) است. برای UDP مقدار پیش‌فرض 60 (۶ ثانیه) است.

retrans=n

تعداد دفعاتی که کلاینت NFS قبل از اقدام به بازیابی بعدی، یک درخواست را تکرار می‌کند. اگر گزینه retrans مشخص نشده باشد، کلاینت NFS هر درخواست UDP را سه بار و هر درخواست TCP را دو بار امتحان می‌کند.

کلاینت NFS پس از retrans بار تکرار، پیام "server not responding" (سرور پاسخ نمی‌دهد) تولید می‌کند و سپس اقدام به عملیات بازیابی بعدی می‌نماید (بسته به این که آیا گزینه اتصال hard اعمال شده است یا خیر).

rsize=n

حداکثر تعداد بایت‌ها در هر درخواست READ شبکه که کلاینت NFS می‌تواند هنگام خواندن داده از یک فایل در سرور NFS دریافت کند. اندازه واقعی داده مفید (payload) هر درخواست READ پروتکل NFS برابر یا کوچکتر از تنظیم rsize است. بزرگترین اندازه داده مفید خواندن پشتیبانی‌شده توسط کلاینت NFS لینوکس ۱,۰۴۸,۵۷۶ بایت (یک مگابایت) است.

مقدار مجاز rsize مضربی صحیح و مثبت از اندازه صفحه (page size) سیستم یا توانی از ۲ در صورتی که کمتر از اندازه صفحه سیستم باشد است. مقادیر مشخص‌شده rsize کمتر از ۱۰۲۴ با ۴۰۹۶ جایگزین می‌شوند؛ مقادیر بزرگتر از ۱۰۴۸۵۷۶ با ۱۰۴۸۵۷۶ جایگزین می‌شوند. اگر یک مقدار تعیین‌شده در محدوده پشتیبانی‌شده باشد اما چنین مقدار مجازی نباشد، به نزدیک‌ترین مقدار مجاز به سمت پایین گرد می‌شود.

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

گزینه اتصال rsize همان‌طور که در خط فرمان mount(8) مشخص شده است در پرونده /etc/mtab ظاهر می‌شود. با این حال، مقدار مؤثر rsize مذاکره‌شده توسط کلاینت و سرور در پرونده /proc/mounts گزارش می‌گردد.

wsize=n

حداکثر تعداد بایت‌ها در هر درخواست WRITE شبکه که کلاینت NFS می‌تواند هنگام نوشتن داده روی یک فایل در سرور NFS ارسال کند. اندازه واقعی داده مفید هر درخواست WRITE پروتکل NFS برابر یا کوچکتر از تنظیم wsize است. بزرگترین داده مفید نوشتن پشتیبانی‌شده توسط کلاینت NFS لینوکس ۱,۰۴۸,۵۷۶ بایت (یک مگابایت) است.

مشابه rsize، مقدار مجاز wsize مضربی صحیح و مثبت از اندازه صفحه سیستم یا توانی از ۲ در صورت کمتر بودن از اندازه صفحه سیستم است. مقادیر تعیین‌شده wsize کمتر از ۱۰۲۴ با ۴۰۹۶ و مقادیر بزرگتر از ۱۰۴۸۵۷۶ با ۱۰۴۸۵۷۶ جایگزین می‌شوند. اگر یک مقدار در محدوده پشتیبانی‌شده باشد اما مقدار مجاز نباشد، به نزدیک‌ترین مقدار مجاز به سمت پایین گرد می‌شود.

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

گزینه اتصال wsize همان‌طور که در خط فرمان mount(8) تعیین شده در پرونده /etc/mtab نمایش داده می‌شود. با این حال، مقدار مؤثر wsize مذاکره‌شده در پرونده /proc/mounts گزارش می‌شود.

ac / noac

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

برای بهبود کارایی، کلاینت‌های NFS ویژگی‌های فایل را کش می‌کنند. هر چند ثانیه یک بار، کلاینت NFS نسخه ویژگی‌های هر فایل در سرور را برای به‌روزرسانی بررسی می‌کند. تغییراتی که در سرور در آن فواصل کوتاه رخ می‌دهند، تا زمانی که کلاینت مجدداً سرور را بررسی نکند، شناسایی‌نشده باقی می‌مانند. گزینه noac مانع از کش کردن ویژگی‌های فایل توسط کلاینت می‌شود تا برنامه‌ها بتوانند با سرعت بیشتری تغییرات فایل را در سرور تشخیص دهند.

علاوه بر جلوگیری از کش کردن ویژگی‌های فایل، گزینه noac نوشتن‌های برنامه را مجبور به همگام‌سازی (synchronous) می‌کند تا تغییرات محلی در یک فایل بلافاصله در سرور قابل مشاهده باشد. به این ترتیب، کلاینت‌های دیگر می‌توانند به سرعت هنگام بررسی ویژگی‌های فایل، تغییرات اخیر را مشاهده نمایند.

استفاده از گزینه noac انسجام کش (cache coherence) بهتری را در میان کلاینت‌های NFS که به فایل‌های یکسان دسترسی دارند فراهم می‌کند، اما هزینه کارایی بالایی به همراه دارد. به همین دلیل، استفاده سنجیده از قفل‌گذاری فایل توصیه می‌شود. بخش «انسجام داده و فراداده» بحث مفصلی در مورد این مصالحه‌ها دارد.

acregmin=n

حداقل زمانی (به ثانیه) که کلاینت NFS ویژگی‌های یک فایل معمولی را قبل از درخواست اطلاعات جدید ویژگی از سرور، در کش نگه می‌دارد. اگر این گزینه مشخص نشود، کلاینت NFS از حداقل ۳ ثانیه استفاده می‌کند. برای بررسی کامل کش ویژگی‌ها به بخش «انسجام داده و فراداده» مراجعه کنید.

acregmax=n

حداکثر زمانی (به ثانیه) که کلاینت NFS ویژگی‌های یک فایل معمولی را قبل از درخواست اطلاعات جدید ویژگی از سرور، در کش نگه می‌دارد. اگر این گزینه مشخص نشود، کلاینت NFS از حداکثر ۶۰ ثانیه استفاده می‌کند. برای بررسی کامل به بخش «انسجام داده و فراداده» مراجعه کنید.

acdirmin=n

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

acdirmax=n

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

actimeo=n

استفاده از actimeo همه مقادیر acregmin، acregmax، acdirmin، و acdirmax را بر روی مقداری یکسان تنظیم می‌کند. اگر این گزینه مشخص نشود، کلاینت NFS از پیش‌فرض‌های مربوط به هر یک از این گزینه‌ها که در بالا ذکر شد استفاده می‌کند.

bg / fg

رفتار دستور mount(8) را در صورت شکست در اتصال یک نقطه اشتراک تعیین می‌کند. گزینه fg باعث می‌شود که mount(8) در صورت اتمام مهلت زمانی یا شکست قطعی هر بخشی از درخواست اتصال، با وضعیت خطا خارج شود. این فرایند اتصال در "پیش‌زمینه" (foreground) نامیده می‌شود و در صورتی که هیچ‌کدام از گزینه‌های fg یا bg مشخص نشده باشند، رفتار پیش‌فرض است.

اگر گزینه bg مشخص شود، اتمام مهلت زمانی یا شکست باعث می‌شود که دستور mount(8) یک پروسه فرزند ایجاد کند که به تلاش برای اتصال نقطه اشتراک ادامه می‌دهد. پروسه والد بلافاصله با کد خروج صفر بازمی‌گردد. این فرایند به عنوان اتصال در "پس‌زمینه" (background) شناخته می‌شود.

اگر دایرکتوری نقطه اتصال محلی وجود نداشته باشد، دستور mount(8) طوری رفتار می‌کند که گویی مهلت زمانی درخواست اتصال تمام شده است. این امر به اتصالات تودرتوی NFS مشخص‌شده در /etc/fstab اجازه می‌دهد تا در هنگام راه‌اندازی سیستم به هر ترتیبی پیش بروند، حتی اگر برخی از سرورهای NFS هنوز در دسترس نباشند. به عنوان یک راهکار جایگزین، می‌توان این موارد را با استفاده از automounter حل کرد (برای جزئیات به automount(8) مراجعه کنید).

nconnect=n

هنگام استفاده از یک پروتکل مبتنی بر اتصال مانند TCP، گاهی اوقات برقراری چندین اتصال بین کلاینت و سرور می‌تواند سودمند باشد. به عنوان مثال، اگر کلاینت‌ها و/یا سرورهای شما مجهز به چندین کارت رابط شبکه (NIC) باشند، استفاده از چندین اتصال برای توزیع بار می‌تواند کارایی کلی را بهبود بخشد. در چنین مواردی، گزینه nconnect به کاربر اجازه می‌دهد تعداد اتصالات برقرارشده بین کلاینت و سرور را تا سقف ۱۶ مشخص کند.

توجه داشته باشید که گزینه nconnect ممکن است توسط برخی از درایورهای pNFS نیز برای تعیین تعداد اتصالات به سرورهای داده استفاده شود.

rdirplus / nordirplus

استفاده از درخواست‌های READDIRPLUS در نسخه ۳ یا ۴ پروتکل NFS را تعیین می‌کند. اگر این گزینه مشخص نشود، کلاینت NFS از یک روش اکتشافی برای بهینه‌سازی کارایی از طریق انتخاب بین READDIR یا READDIRPLUS بر اساس میزان استفاده فرایند فراخواننده از ویژگی‌های اضافی ارائه‌شده توسط READDIRPLUS بهره می‌گیرد. برخی از برنامه‌ها اگر کلاینت فقط از درخواست‌های READDIR برای تمام دایرکتوری‌ها استفاده کند عملکرد بهتری دارند.

rdirplus={none|force}

اگر روی "force" تنظیم شود، کلاینت NFS همیشه سعی می‌کند از درخواست‌های READDIRPLUS استفاده کند. اگر روی "none" تنظیم شود، رفتاری مشابه nordirplus خواهد داشت.

retry=n

تعداد دقایقی که دستور mount(8) عملیات اتصال NFS را در پیش‌زمینه یا پس‌زمینه قبل از انصراف تکرار می‌کند. اگر این گزینه مشخص نشود، مقدار پیش‌فرض برای اتصالات پیش‌زمینه ۲ دقیقه و مقدار پیش‌فرض برای اتصالات پس‌زمینه ۱۰۰۰۰ دقیقه (۸۰ دقیقه کمتر از یک هفته) است. اگر مقدار صفر مشخص شود، دستور mount(8) بلافاصله پس از اولین شکست خارج می‌شود.

توجه داشته باشید که این مورد تنها بر تعداد تلاش‌های مجدد اثر می‌گذارد و تأخیری که توسط هر تلاش مجدد ایجاد می‌شود را تغییر نمی‌دهد. برای UDP هر تلاش مجدد به اندازه زمان تعیین‌شده توسط گزینه‌های timeo و retrans طول می‌کشد که به طور پیش‌فرض حدود ۷ ثانیه خواهد بود. برای TCP پیش‌فرض ۳ دقیقه است، اما مهلت‌های زمانی اتصال TCP سیستم گاهی اوقات مهلت زمانی هر ارسال مجدد را به حدود ۲ دقیقه محدود می‌کند.

sec=flavors

فهرستی جداشده با دو‌نقطه از یک یا چند شیوه امنیتی برای دسترسی به فایل‌ها در نقطه اشتراک متصل‌شده. اگر سرور از هیچ‌یک از این شیوه‌ها پشتیبانی نکند، عملیات اتصال با شکست مواجه می‌شود. اگر sec= مشخص نشود، کلاینت تلاش می‌کند شیوه امنیتی‌ای را پیدا کند که هر دو کلاینت و سرور از آن پشتیبانی می‌کنند. شیوه‌های معتبر (flavors) عبارتند از: none، sys، krb5، krb5i، و krb5p. برای جزئیات به بخش «ملاحظات امنیتی» مراجعه فرمایید.

sharecache / nosharecache

تعیین می‌کند که در صورت اتصال همزمان و بیش از یک‌بار یک نقطه اشتراک، کش داده‌ها و کش ویژگی‌های کلاینت چگونه به اشتراک گذاشته شود. استفاده از کش یکسان، نیازمندی‌های حافظه را در کلاینت کاهش می‌دهد و محتوای یکسان فایل را در هنگام دسترسی به همان فایل دوردست از طریق نقاط اتصال مختلف، به برنامه‌ها ارائه می‌دهد.

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

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

resvport / noresvport

تعیین می‌کند که آیا کلاینت NFS هنگام برقراری ارتباط با سرور NFS برای این نقطه اتصال، باید از یک پورت مبدا دارای مجوز ویژه (privileged) استفاده کند یا خیر. اگر این گزینه مشخص نشود، یا گزینه resvport مشخص شود، کلاینت NFS از پورت مبدا ممتاز استفاده می‌کند. اگر گزینه noresvport مشخص شود، کلاینت از پورت غیرممتاز بهره می‌گیرد. این گزینه در هسته‌های 2.6.28 و بالاتر پشتیبانی می‌شود.

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

برای جزئیات مهم به بخش «ملاحظات امنیتی» مراجعه کنید.

lookupcache=mode

نحوه مدیریت کش مدخل‌های دایرکتوری توسط هسته را برای یک نقطه اتصال مشخص تعیین می‌کند. mode می‌تواند یکی از موارد all، none، pos، یا positive باشد. این گزینه در هسته‌های 2.6.28 و بالاتر پشتیبانی می‌شود.

کلاینت NFS لینوکس نتیجه تمام درخواست‌های LOOKUP پروتکل NFS را کش می‌کند. اگر مدخل دایرکتوری در سرور وجود داشته باشد، نتیجه با عنوان positive (مثبت) شناخته می‌شود. اگر مدخل دایرکتوری در سرور وجود نداشته باشد، نتیجه به عنوان negative (منفی) شناخته می‌شود.

اگر این گزینه تعیین نشود یا all مشخص گردد، کلاینت فرض می‌کند هر دو نوع مدخل کش دایرکتوری تا زمان انقضای ویژگی‌های کش‌شده دایرکتوری والد آن‌ها معتبر هستند.

اگر pos یا positive مشخص شود، کلاینت فرض می‌کند مدخل‌های مثبت تا زمان انقضای ویژگی‌های کش‌شده دایرکتوری والد معتبرند، اما مدخل‌های منفی را همیشه قبل از اینکه یک برنامه بتواند از آن‌ها استفاده کند، مجدداً اعتبارسنجی می‌کند.

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

بخش «انسجام داده و فراداده» حاوی بحث مفصلی در مورد این مصالحه‌ها است.

fsc / nofsc

کش کردن صفحات داده (فقط‌خواندنی) روی دیسک محلی را با استفاده از امکان FS-Cache فعال یا غیرفعال می‌کند. برای جزئیات در مورد نحوه پیکربندی امکان FS-Cache به cachefilesd(8) و مستندات هسته در Documentation/filesystems/caching مراجعه کنید. مقدار پیش‌فرض nofsc است.

sloppy

گزینه sloppy جایگزینی برای مشخص کردن گزینه mount.nfs -s است.

xprtsec=policy

استفاده از امنیت لایه انتقال (TLS) را برای حفاظت از ترافیک شبکه NFS به نیابت از این نقطه اتصال مشخص می‌کند. policy می‌تواند یکی از مقادیر none، tls، یا mtls باشد.

اگر none مشخص شود، امنیت لایه انتقال اجباراً خاموش می‌شود، حتی اگر سرور NFS از امنیت لایه انتقال پشتیبانی کند.

اگر tls مشخص شود، کلاینت از RPC-with-TLS برای تأمین محرمانگی داده‌ها در حین انتقال استفاده می‌کند.

اگر mtls تعیین شود، کلاینت از RPC-with-TLS برای احراز هویت خود و ارائه محرمانگی در حال انتقال استفاده می‌نماید.

اگر هر یک از مقادیر tls یا mtls مشخص شود و سرور از RPC-with-TLS پشتیبانی نکند یا احراز هویت طرف مقابل با شکست مواجه گردد، تلاش برای اتصال ناموفق خواهد بود.

اگر گزینه xprtsec= مشخص نشود، رفتار پیش‌فرض به نسخه هسته بستگی دارد، اما معمولاً معادل xprtsec=none است.

noalignwrite

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

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

گزینه‌ها فقط برای نسخه‌های ۲ و ۳ پروتکل NFS (Options for NFS versions 2 and 3 only)

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

proto=netid

مقدار netid پروتکل انتقالی را که برای ارتباط با سرور NFS استفاده می‌شود تعیین می‌کند. گزینه‌های موجود عبارتند از: udp، udp6، tcp، tcp6، rdma، و rdma6. مواردی که به 6 ختم می‌شوند از آدرس‌های IPv6 استفاده می‌کنند و تنها در صورتی در دسترس هستند که پشتیبانی از TI-RPC ساخته شده باشد. سایر موارد از آدرس‌های IPv4 استفاده می‌کنند.

هر پروتکل انتقال از تنظیمات پیش‌فرض retrans و timeo متفاوتی استفاده می‌کند. برای جزئیات به شرح این دو گزینه اتصال مراجعه فرمایید.

علاوه بر کنترل نحوه ارسال درخواست‌های کلاینت NFS به سرور، این گزینه اتصال همچنین نحوه ارتباط دستور mount(8) با سرویس‌های rpcbind و mountd سرور را کنترل می‌کند. تعیین یک netid که از TCP استفاده می‌کند تمام ترافیک دستور mount(8) و کلاینت NFS را وادار به استفاده از TCP می‌کند. تعیین یک netid که از UDP استفاده می‌کند تمام انواع ترافیک را مجبور به استفاده از UDP می‌نماید.

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

اگر گزینه اتصال proto مشخص نشود، دستور mount(8) تشخیص می‌دهد که سرور از چه پروتکل‌هایی پشتیبانی می‌کند و انتقال مناسبی را برای هر سرویس انتخاب می‌نماید. برای جزئیات بیشتر به بخش «روش‌های انتقال» مراجعه کنید.

udp

گزینه udp جایگزینی برای تعیین proto=udp است. این گزینه برای سازگاری با سایر سیستم‌های عامل گنجانده شده است.

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

tcp

گزینه tcp جایگزینی برای تعیین proto=tcp است. این گزینه برای سازگاری با سایر سیستم‌های عامل گنجانده شده است.

rdma

گزینه rdma جایگزینی برای تعیین proto=rdma است.

port=n

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

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

mountport=n

مقدار عددی درگاه mountd سرور. اگر سرویس mountd سرور روی درگاه مشخص‌شده در دسترس نباشد، درخواست اتصال با شکست مواجه می‌شود.

اگر این گزینه مشخص نشود، یا اگر مقدار درگاه مشخص‌شده ۰ باشد، دستور mount(8) از شماره درگاه سرویس mountd اعلام‌شده توسط سرویس rpcbind سرور استفاده می‌کند. اگر سرویس rpcbind سرور در دسترس نباشد، سرویس mountd سرور در rpcbind ثبت نشده باشد، یا سرویس mountd سرور روی درگاه اعلام‌شده در دسترس نباشد، درخواست اتصال ناموفق خواهد بود.

این گزینه می‌تواند هنگام اتصال به سرور NFS از پشت یک فایروال که پروتکل rpcbind را مسدود می‌کند استفاده شود.

mountproto=netid

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

مقدار netid می‌تواند یکی از موارد udp و tcp باشد که از آدرس IPv4 استفاده می‌کنند، یا اگر TI-RPC در دستور mount.nfs تعبیه شده باشد، udp6 و tcp6 که از آدرس‌های IPv6 استفاده می‌کنند.

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

برای اطلاعات بیشتر در مورد نحوه تعامل گزینه اتصال mountproto با گزینه اتصال proto، به بخش «روش‌های انتقال» مراجعه کنید.

mounthost=name

نام میزبان میزبانی که mountd را اجرا می‌کند. اگر این گزینه مشخص نشود، دستور mount(8) فرض می‌کند که سرویس mountd روی همان میزبانی اجرا می‌شود که سرویس NFS در حال اجرا است.

mountvers=n

شماره نسخه RPC مورد استفاده برای تماس با mountd سرور. اگر این گزینه مشخص نشود، کلاینت از شماره نسخه‌ای متناسب با نسخه NFS درخواست‌شده استفاده می‌کند. این گزینه زمانی مفید است که چندین سرویس NFS روی یک میزبان سرور دوردست در حال اجرا باشند.

namlen=n

حداکثر طول یک جزء نام مسیر در این اتصال. اگر این گزینه مشخص نشود، حداکثر طول با سرور مذاکره می‌شود. در بیشتر موارد، این حداکثر طول ۲۵۵ کاراکتر است.

برخی از نسخه‌های اولیه NFS از این مذاکره پشتیبانی نمی‌کردند. استفاده از این گزینه تضمین می‌کند که pathconf(3) در چنین مواردی حداکثر طول مؤلفه مناسب را به برنامه‌ها گزارش دهد.

lock / nolock

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

قفل‌گذاری NLM باید هنگام استفاده از NFS برای اتصال /var با گزینه nolock غیرفعال شود، زیرا /var حاوی فایل‌های مورد استفاده توسط پیاده‌سازی NLM در لینوکس است. استفاده از گزینه nolock هنگام اتصال نقاط اشتراک در سرورهای NFS که از پروتکل NLM پشتیبانی نمی‌کنند نیز الزامی است.

cto / nocto

تعیین می‌کند که آیا از معناشناسی انسجام کش «بستن تا باز کردن» (close-to-open) استفاده شود یا خیر. اگر هیچ‌کدام مشخص نشود (یا اگر cto مشخص شود)، کلاینت از معناشناسی انسجام کش close-to-open استفاده می‌کند. اگر گزینه nocto مشخص شود، کلاینت از یک روش اکتشافی غیراستاندارد برای تعیین تغییر فایل‌ها در سرور استفاده می‌کند.

استفاده از گزینه nocto ممکن است کارایی را برای اتصالات فقط‌خواندنی بهبود بخشد، اما تنها در صورتی باید استفاده شود که داده‌های روی سرور به ندرت تغییر کنند. بخش «انسجام داده و فراداده» رفتار این گزینه را با جزئیات بیشتری مورد بحث قرار می‌دهد.

acl / noacl

انتخاب می‌کند که آیا از پروتکل جانبی NFSACL در این نقطه اتصال استفاده شود یا خیر. پروتکل جانبی NFSACL یک پروتکل اختصاصی پیاده‌سازی‌شده در Solaris است که فهرست‌های کنترل دسترسی (ACL) را مدیریت می‌کند. NFSACL هرگز به بخشی استاندارد از مشخصات پروتکل NFS تبدیل نشد.

اگر هیچ‌کدام از گزینه‌های acl یا noacl مشخص نشود، کلاینت NFS با سرور مذاکره می‌کند تا بررسی کند آیا پروتکل NFSACL پشتیبانی می‌شود یا خیر، و در صورت پشتیبانی سرور از آن استفاده می‌کند. در صورتی که این مذاکره باعث بروز مشکلاتی در کلاینت یا سرور شود، غیرفعال کردن پروتکل جانبی NFSACL ممکن است ضروری باشد. برای جزئیات بیشتر به بخش «ملاحظات امنیتی» مراجعه کنید.

local_lock=mechanism

مشخص می‌کند که آیا برای هر یک یا هر دو مکانیسم قفل‌گذاری flock و POSIX از قفل‌گذاری محلی استفاده شود یا خیر. مقدار mechanism می‌تواند یکی از موارد all، flock، posix، یا none باشد. این گزینه در هسته‌های 2.6.37 و بالاتر پشتیبانی می‌شود.

کلاینت NFS لینوکس راهکاری برای محلی کردن قفل‌ها فراهم می‌کند. این بدان معناست که برنامه‌ها می‌توانند فایل‌ها را قفل کنند، اما چنین قفل‌هایی فقط در برابر سایر برنامه‌های در حال اجرا بر روی همان کلاینت مانع ایجاد می‌کنند. برنامه‌های دوردست تحت تأثیر این قفل‌ها قرار نمی‌گیرند.

اگر این گزینه مشخص نشود، یا اگر none مشخص گردد، کلاینت فرض می‌کند که قفل‌ها محلی نیستند.

اگر all مشخص شود، کلاینت فرض می‌کند که هر دو قفل flock و POSIX محلی هستند.

اگر flock مشخص شود، کلاینت فرض می‌کند فقط قفل‌های flock محلی هستند و هنگام استفاده از قفل‌های POSIX از پروتکل جانبی NLM برای قفل کردن فایل‌ها استفاده می‌کند.

اگر posix مشخص شود، کلاینت فرض می‌کند قفل‌های POSIX محلی هستند و هنگام استفاده از قفل‌های flock از پروتکل جانبی NLM برای قفل کردن فایل‌ها استفاده می‌کند.

برای پشتیبانی از رفتار سنتی flock مشابه کلاینت‌های NFS قدیمی‌تر از 2.6.12، از 'local_lock=flock' استفاده کنید. این گزینه هنگام به اشتراک‌گذاری مجدد اتصالات NFS از طریق Samba الزامی است زیرا Samba قفل‌های حالت اشتراک ویندوز را به صورت flock نقشه‌بندی می‌کند. از آنجا که کلاینت‌های NFS جدیدتر از 2.6.12 قفل flock را با شبیه‌سازی قفل‌های POSIX پیاده‌سازی می‌کنند، این امر منجر به تداخل قفل‌ها خواهد شد.

نکته: در صورت استفاده همزمان، گزینه اتصال 'local_lock' توسط گزینه اتصال 'nolock'/'lock' بازنویسی خواهد شد.

گزینه‌ها فقط برای نسخه ۴ پروتکل NFS (Options for NFS version 4 only)

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

proto=netid

مقدار netid پروتکل انتقالی را که برای برقراری ارتباط با سرور NFS استفاده می‌شود تعیین می‌کند. گزینه‌های پشتیبانی‌شده عبارتند از: tcp، tcp6، rdma، و rdma6. گزینه tcp6 از آدرس‌های IPv6 استفاده می‌کند و تنها در صورتی در دسترس است که پشتیبانی از TI-RPC وجود داشته باشد. سایر موارد از آدرس‌های IPv4 استفاده می‌کنند.

تمامی سرورهای نسخه ۴ پروتکل NFS ملزم به پشتیبانی از TCP هستند، بنابراین اگر این گزینه اتصال مشخص نشود، کلاینت نسخه ۴ پروتکل NFS از پروتکل TCP استفاده می‌کند. برای جزئیات بیشتر به بخش «روش‌های انتقال» مراجعه فرمایید.

minorversion=n

شماره نسخه فرعی (minor version) پروتکل را مشخص می‌کند. پروتکل NFSv4 مفهوم "نسخه‌بندی فرعی" را معرفی می‌کند که در آن بهبودهای پروتکل NFS می‌توانند بدون افزایش شماره نسخه اصلی پروتکل معرفی شوند. قبل از هسته 2.6.38، نسخه فرعی همیشه صفر بود و این گزینه شناسایی نمی‌شد. پس از این هسته، تعیین "minorversion=1" تعدادی از ویژگی‌های پیشرفته مانند نشست‌های NFSv4 را فعال می‌کند.

هسته‌های جدیدتر اجازه می‌دهند نسخه فرعی با استفاده از گزینه vers= مشخص شود. برای مثال، تعیین vers=4.1 همانند تعیین vers=4,minorversion=1 است.

port=n

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

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

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

cto / nocto

تعیین می‌کند که آیا از معناشناسی انسجام کش «بستن تا باز کردن» (close-to-open) برای دایرکتوری‌های NFS در این نقطه اتصال استفاده شود یا خیر. اگر هیچ‌کدام از گزینه‌های cto یا nocto مشخص نشود، پیش‌فرض استفاده از معناشناسی انسجام کش close-to-open برای دایرکتوری‌ها است.

رفتار کش داده‌های فایل تحت تأثیر این گزینه قرار نمی‌گیرد. بخش «انسجام داده و فراداده» رفتار این گزینه را با جزئیات بیشتری مورد بحث قرار می‌دهد.

clientaddr=n.n.n.n

clientaddr=n:n:...:n

یک آدرس واحد IPv4 (در قالب چهاربخشی نقطه‌دار) یا یک آدرس IPv6 غیر پیوند-محلی را مشخص می‌کند که کلاینت NFS اعلام می‌نماید تا به سرورها اجازه دهد درخواست‌های فراخوانی مجدد (callback) نسخه 4.0 پروتکل NFS را روی فایل‌های این نقطه اتصال انجام دهند. اگر سرور نتواند اتصالات فراخوانی مجدد را به کلاینت‌ها برقرار کند، ممکن است کارایی کاهش یابد یا دسترسی به فایل‌ها موقتاً متوقف (hang) شود. می‌توان مقدار IPv4_ANY (0.0.0.0) یا معادل آدرس IPv6 any را مشخص کرد که به سرور NFS اعلام می‌کند این کلاینت تفویض اختیارات (delegations) را نمی‌خواهد.

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

نسخه‌های 4.1 و 4.2 پروتکل NFS از اتصال TCP برقرارشده توسط کلاینت برای درخواست‌های فراخوانی مجدد استفاده می‌کنند، بنابراین نیازی به اتصال سرور به کلاینت ندارند. بنابراین این گزینه فقط بر اتصالات نسخه 4.0 پروتکل NFS اثر می‌گذارد.

migration / nomigration

تعیین می‌کند که آیا کلاینت از یک رشته شناسایی سازگار با مهاجرت وضعیت شفاف (TSM) در NFSv4 استفاده کند یا خیر. اگر سرور متصل‌شده از مهاجرت NFSv4 با TSM پشتیبانی می‌کند، گزینه migration را مشخص کنید.

برخی از ویژگی‌های سرور در مواجهه با یک رشته شناسایی سازگار با مهاجرت رفتار نامناسبی نشان می‌دهند. گزینه nomigration استفاده از یک رشته شناسایی سنتی کلاینت را حفظ می‌کند که با سرورهای موروثی NFS سازگار است. این گزینه رفتاری است که در صورت عدم تعیین هیچ‌کدام از گزینه‌ها نیز اعمال می‌شود. هنگامی که یک کلاینت خود را از طریق یک رشته شناسایی سنتی معرفی می‌کند، وضعیت‌های باز بودن فایل و قفل آن را نمی‌توان به طور شفاف مهاجرت داد.

این گزینه اتصال در نسخه‌های فرعی NFSv4 جدیدتر از صفر که همیشه از رشته‌های شناسایی کلاینت سازگار با TSM استفاده می‌کنند، هیچ اثری ندارد.

max_connect=n

در حالی که گزینه nconnect محدودیتی برای تعداد اتصالات قابل برقراری به یک IP سرور مشخص تعیین می‌کند، گزینه max_connect به کاربر اجازه می‌دهد حداکثر تعداد اتصالات به IPهای مختلف سرور متعلق به همان سرور NFSv4.1+ (اتصالات با قابلیت session trunking) را تا سقف ۱۶ مشخص کند. هنگامی که کلاینت متوجه می‌شود یک شناسه کلاینت (client ID) با یک سرور از پیش موجود برقرار کرده است، به جای کنار گذاشتن پروتکل انتقال شبکه تازه‌ساخته‌شده، این اتصال جدید را به فهرست پروتکل‌های انتقال موجود برای آن کلاینت RPC اضافه می‌کند.

trunkdiscovery / notrunkdiscovery

هنگامی که کلاینت یک سیستم پرونده جدید را روی یک سرور NFSv4.1+ شناسایی می‌کند، گزینه اتصال trunkdiscovery باعث می‌شود که یک درخواست GETATTR برای ویژگی fs_locations ارسال کند. اگر پاسخی با طول غیرصفر دریافت کند، در میان پاسخ‌ها پیمایش می‌کند و برای هر مکان سرور یک اتصال برقرار می‌نماید، یک EXCHANGE_ID می‌فرستد و قابلیت session trunking را آزمایش می‌کند. اگر آزمایش ترانکینگ موفقیت‌آمیز باشد، اتصال با رعایت محدودیت تعیین‌شده توسط گزینه max_connect به مجموعه پروتکل‌های انتقال موجود برای سرور اضافه خواهد شد. مقدار پیش‌فرض notrunkdiscovery است.

استفاده از گزینه اتصال mountproto (Using the mountproto mount option)

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

کلاینت NFS لینوکس می‌تواند از بسترهای انتقال متفاوتی برای ارتباط با سرویس rpcbind سرور NFS، سرویس mountd آن، سرویس مدیر قفل شبکه (NLM) و سرویس NFS استفاده کند. بسترهای انتقال دقیقی که توسط کلاینت NFS لینوکس برای هر نقطه اتصال استفاده می‌شود به تنظیمات گزینه‌های انتقال بستگی دارد که شامل proto، mountproto، udp و tcp است.

کلاینت بدون توجه به گزینه‌های انتقال مشخص‌شده، اعلان‌های مدیر وضعیت شبکه (NSM) را از طریق UDP ارسال می‌کند، اما اعلان‌های NSM سرور را هم روی UDP و هم روی TCP گوش می‌دهد. پروتکل فهرست کنترل دسترسی NFS (یا NFSACL) از همان بستر انتقال سرویس اصلی NFS استفاده می‌کند.

اگر هیچ گزینه انتقالی مشخص نشده باشد، کلاینت NFS لینوکس به طور پیش‌فرض از UDP برای تماس با سرویس mountd سرور و از TCP برای تماس با سرویس‌های NLM و NFS آن استفاده می‌کند.

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

هنگامی که گزینه proto، گزینه udp، یا گزینه tcp مشخص شده باشد اما گزینه mountproto مشخص نشده باشد، بستر انتقال تعیین‌شده هم برای ارتباط با سرویس mountd سرور و هم برای سرویس‌های NLM و NFS استفاده می‌شود.

اگر گزینه mountproto مشخص شده باشد اما هیچ‌کدام از گزینه‌های proto، udp یا tcp مشخص نشده باشند، از بستر انتقال تعیین‌شده برای درخواست اولیه mountd استفاده می‌شود، اما دستور mount تلاش می‌کند آنچه را سرور برای پروتکل NFS پشتیبانی می‌کند کشف کند، و در صورتی که هر دو انتقال پشتیبانی شوند، TCP را ترجیح می‌دهد.

اگر هر دو گزینه mountproto و proto (یا udp یا tcp) مشخص شده باشند، بستر انتقال تعیین‌شده توسط گزینه mountproto برای درخواست اولیه mountd استفاده می‌شود و بستر انتقال تعیین‌شده توسط گزینه proto (یا گزینه‌های udp یا tcp) صرف‌نظر از ترتیب ظاهر شدن این گزینه‌ها، برای NFS استفاده می‌شود. در صورت مشخص شدن این گزینه‌ها، هیچ شناسایی خودکار سرویسی انجام نمی‌شود.

اگر هر یک از گزینه‌های proto، udp، tcp، یا mountproto بیش از یک بار در همان خط فرمان mount مشخص شوند، مقدار آخرین نمونه (راست‌ترین) از هر یک از این گزینه‌ها اعمال می‌شود.

استفاده از NFS روی UDP در پیوندهای پرسرعت (Using NFS over UDP on high-speed links)

استفاده از NFS روی UDP در پیوندهای پرسرعت مانند گیگابیت می‌تواند باعث تخریب پنهان داده‌ها شود .

این مشکل می‌تواند در بارهای کاری بالا رخ دهد و ناشی از مشکلات بازترکیب قطعات (IP fragment reassembly) است. عملیات خواندن و نوشتن NFS معمولاً بسته‌های UDP به اندازه ۴ کیلوبایت یا بیشتر ارسال می‌کنند که برای ارسال از طریق پیوند اترنت (که بسته‌ها را به طور پیش‌فرض به ۱۵۰۰ بایت محدود می‌کند) باید به چندین قطعه تقسیم شوند. این فرایند در لایه شبکه IP رخ می‌دهد و قطعه‌بندی (fragmentation) نامیده می‌شود.

به منظور شناسایی قطعاتی که متعلق به یکدیگر هستند، IP یک مقدار ۱۶ بیتی با عنوان IP ID به هر بسته اختصاص می‌دهد؛ قطعات تولیدشده از یک بسته UDP یکسان، دارای IP ID یکسانی خواهند بود. سیستم گیرنده این قطعات را جمع‌آوری کرده و آن‌ها را برای تشکیل بسته اصلی UDP ترکیب می‌کند. این فرایند بازترکیب (reassembly) نامیده می‌شود. مهلت زمانی پیش‌فرض برای بازترکیب بسته‌ها ۳۰ ثانیه است؛ اگر پشته شبکه تمام قطعات یک بسته مشخص را در این بازه زمانی دریافت نکند، فرض می‌کند که قطعه(های) مفقودشده از دست رفته‌اند و قطعاتی را که قبلاً دریافت کرده دور می‌اندازد.

مشکلی که این موضوع در پیوندهای پرسرعت ایجاد می‌کند این است که امکان ارسال بیش از ۶۵۵۳۶ بسته در عرض ۳۰ ثانیه وجود دارد. در واقع، با ترافیک سنگین NFS می‌توان مشاهده کرد که IP IDها پس از حدود ۵ ثانیه تکرار می‌شوند.

این امر اثرات جدی بر روی بازترکیب دارد: اگر یک قطعه گم شود، قطعه دیگری از یک بسته متفاوت اما با همان IP ID در بازه زمانی مهلت ۳۰ ثانیه‌ای از راه می‌رسد و پشته شبکه این قطعات را برای ساخت یک بسته جدید ترکیب می‌کند. در بیشتر مواقع، لایه‌های شبکه بالاتر از IP این بازترکیب نامتناسب را تشخیص می‌دهند - در مورد UDP، چکسام UDP که یک چکسام ۱۶ بیتی روی کل داده مفید بسته است، معمولاً مطابقت نخواهد داشت و UDP بسته خراب را دور می‌اندازد.

با این حال، چکسام UDP تنها ۱۶ بیتی است، بنابراین احتمال ۱ در ۶۵۵۳۶ وجود دارد که حتی اگر داده مفید بسته کاملاً تصادفی باشد، با هم مطابقت داشته باشند (که اغلب این‌طور نیست). اگر این اتفاق بیفتد، تخریب پنهان داده‌ها (silent data corruption) رخ خواهد داد.

این پتانسیل خطر باید جدی گرفته شود، حداقل در شبکه اترنت گیگابیتی. سرعت‌های شبکه 100Mbit/s باید کمتر مشکل‌ساز تلقی شوند، زیرا در بیشتر الگوهای ترافیکی چرخش کامل IP ID بسیار بیشتر از ۳۰ ثانیه طول می‌کشد.

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

اگر کاملاً مجبور به استفاده از NFS روی UDP در اترنت گیگابیتی هستید، می‌توان اقداماتی برای کاهش مشکل و کاهش احتمال تخریب داده‌ها انجام داد:

فریم‌های بزرگ (Jumbo frames):

بسیاری از کارت‌های شبکه گیگابیتی قادر به ارسال فریم‌های بزرگتر از حد ۱۵۰۰ بایتی اترنت سنتی، معمولاً ۹۰۰۰ بایت، هستند. استفاده از فریم‌های بزرگ ۹۰۰۰ بایتی به شما امکان می‌دهد NFS را روی UDP با اندازه صفحه 8K بدون قطعه‌بندی اجرا کنید. البته، این کار تنها در صورتی امکان‌پذیر است که تمام ایستگاه‌های درگیر از فریم‌های بزرگ پشتیبانی کنند.

برای فعال کردن ارسال فریم‌های بزرگ در ماشین‌هایی با کارت‌هایی که از آن پشتیبانی می‌کنند، کافی است رابط شبکه را برای مقدار MTU برابر با ۹۰۰۰ پیکربندی کنید.

کاهش مهلت زمانی بازترکیب (Lower reassembly timeout):

با کاهش این مهلت زمانی به کمتر از زمانی که طول می‌کشد شمارنده IP ID یک دور کامل بزند، می‌توان از بازترکیب نادرست قطعات نیز جلوگیری کرد. برای انجام این کار، کافی است مقدار مهلت زمانی جدید (به ثانیه) را در پرونده /proc/sys/net/ipv4/ipfrag_time بنویسید.

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

انسجام کش بستن تا باز کردن (Close-to-open cache consistency)

معمولاً اشتراک‌گذاری فایل کاملاً ترتیبی است. ابتدا کلاینت A یک فایل را باز می‌کند، چیزی در آن می‌نویسد و سپس آن را می‌بندد. سپس کلاینت B همان فایل را باز کرده و تغییرات را می‌خواند.

هنگامی که یک برنامه فایلی ذخیره‌شده در یک سرور نسخه ۳ پروتکل NFS را باز می‌کند، کلاینت NFS با ارسال یک درخواست GETATTR یا ACCESS بررسی می‌کند که فایل در سرور وجود دارد و گشایش‌دهنده اجازه دسترسی به آن را دارد. کلاینت NFS بدون در نظر گرفتن تازگی ویژگی‌های کش‌شده فایل، این درخواست‌ها را ارسال می‌کند.

هنگامی که برنامه فایل را می‌بندد، کلاینت NFS هرگونه تغییر معوقه را روی فایل بازنویسی می‌کند تا گشایش‌دهنده بعدی بتواند تغییرات را مشاهده کند. این همچنین به کلاینت NFS فرصت می‌دهد تا خطاهای نوشتن را از طریق کد بازگشتی دستور close(2) به برنامه گزارش دهد.

رفتار بررسی در زمان باز کردن و تخلیه داده‌ها در زمان بستن به عنوان انسجام کش بستن تا باز کردن یا CTO شناخته می‌شود. این قابلیت را می‌توان برای کل یک نقطه اتصال با استفاده از گزینه اتصال nocto غیرفعال کرد.

انسجام ضعیف کش (Weak cache consistency)

همچنان فرصت‌هایی وجود دارد که کش داده‌های یک کلاینت حاوی داده‌های قدیمی و نامعتبر باشد. پروتکل NFS نسخه ۳ ویژگی "انسجام ضعیف کش" (که با نام WCC نیز شناخته می‌شود) را معرفی کرد که روشی برای بررسی کارآمد ویژگی‌های یک فایل قبل و بعد از یک درخواست واحد ارائه می‌دهد. این به کلاینت اجازه می‌دهد تغییراتی را که ممکن است توسط سایر کلاینت‌ها ایجاد شده باشد شناسایی کند.

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

کش ویژگی‌ها (Attribute caching)

برای دستیابی به انسجام کش ویژگی‌ها در میان چندین کلاینت، از گزینه اتصال noac استفاده کنید. تقریباً هر عملیات سیستم پرونده، اطلاعات ویژگی‌های فایل را بررسی می‌کند. کلاینت این اطلاعات را برای مدتی در حافظه موقت نگه می‌دارد تا بار شبکه و سرور کاهش یابد. هنگامی که noac اعمال می‌شود، کش ویژگی‌های فایل کلاینت غیرفعال می‌گردد، بنابراین هر عملیاتی که نیاز به بررسی ویژگی‌های یک فایل دارد مجبور است به سرور مراجعه کند. این امر به کلاینت اجازه می‌دهد تا تغییرات یک فایل را بسیار سریع و به قیمت بسیاری از عملیات اضافی شبکه مشاهده کند.

مراقب باشید که گزینه noac را با "عدم کش داده‌ها" اشتباه نگیرید. گزینه اتصال noac مانع از کش کردن فراداده فایل توسط کلاینت می‌شود، اما همچنان شرایط رقابتی (race conditions) وجود دارند که ممکن است منجر به عدم انسجام کش داده بین کلاینت و سرور شوند.

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

نگهداری برچسب زمانی فایل (File timestamp maintenance)

سرورهای NFS مسئول مدیریت برچسب‌های زمانی فایل و دایرکتوری هستند (atime، ctime، و mtime). هنگامی که به فایلی در سرور NFS دسترسی پیدا می‌شود یا به‌روزرسانی می‌گردد، برچسب‌های زمانی فایل دقیقاً مانند زمانی که روی یک سیستم پرونده محلی برای یک برنامه قرار دارد، به‌روز می‌شوند.

کلاینت‌های NFS ویژگی‌های فایل از جمله برچسب‌های زمانی را کش می‌کنند. برچسب‌های زمانی یک فایل روی کلاینت‌های NFS زمانی به‌روز می‌شوند که ویژگی‌های آن از سرور NFS بازیابی شوند. بنابراین ممکن است قبل از اینکه به‌روزرسانی‌های برچسب زمانی روی سرور NFS برای برنامه‌های روی کلاینت‌های NFS ظاهر شوند، مقداری تأخیر وجود داشته باشد.

برای مطابقت با استاندارد سیستم پرونده POSIX، کلاینت NFS لینوکس به سرورهای NFS متکی است تا برچسب‌های زمانی mtime و ctime یک فایل را به درستی به‌روز نگه دارند. کلاینت این کار را با تخلیه تغییرات داده‌های محلی به سرور قبل از گزارش mtime به برنامه‌ها از طریق فراخوانی‌های سیستمی مانند stat(2) انجام می‌دهد.

با این حال، کلاینت لینوکس به‌روزرسانی‌های atime را با سهل‌گیری بیشتری مدیریت می‌کند. کلاینت‌های NFS کارایی مناسب را با کش کردن داده‌ها حفظ می‌کنند، اما این بدان معناست که خواندن‌های برنامه که معمولاً atime را به‌روز می‌کنند، به سروری که در آن atime یک فایل واقعاً نگهداری می‌شود منتقل نمی‌شوند.

به دلیل این رفتار کش کردن، کلاینت NFS لینوکس از گزینه‌های اتصال عمومی مرتبط با atime پشتیبانی نمی‌کند. برای جزئیات در مورد این گزینه‌ها به mount(8) مراجعه کنید.

به طور خاص، گزینه‌های اتصال atime/noatime، diratime/nodiratime، relatime/norelatime، و strictatime / nostrictatime هیچ تأثیری بر روی اتصالات NFS ندارند.

پرونده /proc/mounts ممکن است گزارش دهد که گزینه اتصال relatime روی اتصالات NFS تنظیم شده است، اما در واقع معناشناسی atime همیشه همان‌طور است که در اینجا توضیح داده شده است، و مانند معناشناسی relatime نیست.

کش مدخل‌های دایرکتوری (Directory entry caching)

کلاینت NFS لینوکس نتیجه تمام درخواست‌های NFS LOOKUP را کش می‌کند. اگر مدخل دایرکتوری درخواست‌شده روی سرور وجود داشته باشد، نتیجه با عنوان نتیجه جستجوی positive (مثبت) شناخته می‌شود. اگر مدخل دایرکتوری درخواست‌شده روی سرور وجود نداشته باشد (یعنی سرور خطای ENOENT بازگرداند)، نتیجه به عنوان نتیجه جستجوی negative (منفی) شناخته می‌شود.

برای تشخیص اینکه مدخل‌های دایرکتوری چه زمانی روی سرور اضافه یا حذف شده‌اند، کلاینت NFS لینوکس mtime دایرکتوری را زیر نظر می‌گیرد. اگر کلاینت تغییری در mtime دایرکتوری تشخیص دهد، تمام نتایج LOOKUP کش‌شده برای آن دایرکتوری را کنار می‌گذارد. از آنجا که mtime دایرکتوری یک ویژگی کش‌شده است، ممکن است مدتی طول بکشد تا کلاینت متوجه تغییر آن شود. برای اطلاعات بیشتر در مورد مدت‌زمان کش شدن mtime دایرکتوری، شرح گزینه‌های اتصال acdirmin، acdirmax، و noac را مشاهده کنید.

کش کردن مدخل‌های دایرکتوری کارایی برنامه‌هایی را که فایل‌ها را با برنامه‌های روی کلاینت‌های دیگر به اشتراک نمی‌گذارند بهبود می‌بخشد. با این حال، استفاده از اطلاعات کش‌شده در مورد دایرکتوری‌ها می‌تواند با برنامه‌هایی که به طور همزمان روی چندین کلاینت اجرا می‌شوند و نیاز به تشخیص سریع ایجاد یا حذف فایل‌ها دارند تداخل داشته باشد. گزینه اتصال lookupcache امکان تنظیم رفتار کش کردن مدخل‌های دایرکتوری را فراهم می‌کند.

قبل از نسخه 2.6.28 هسته، کلاینت NFS لینوکس فقط نتایج جستجوی مثبت را ردیابی می‌کرد. این امر به برنامه‌ها امکان می‌داد مدخل‌های دایرکتوری جدید ایجادشده توسط سایر کلاینت‌ها را به سرعت تشخیص دهند در حالی که هنوز برخی از مزایای کارایی کش را ارائه می‌داد. اگر برنامه‌ای به رفتار قبلی کش جستجوی کلاینت NFS لینوکس وابسته است، می‌توانید از lookupcache=positive استفاده کنید.

اگر کلاینت کش خود را نادیده بگیرد و هر درخواست جستجوی برنامه را با سرور اعتبارسنجی کند، آن کلاینت می‌تواند بلافاصله تشخیص دهد که چه زمانی یک مدخل دایرکتوری جدید توسط کلاینت دیگری ایجاد یا حذف شده است. شما می‌توانید این رفتار را با استفاده از lookupcache=none مشخص کنید. درخواست‌های اضافی NFS مورد نیاز در صورتی که کلاینت مدخل‌های دایرکتوری را کش نکند، می‌تواند جریمه کارایی به همراه داشته باشد. غیرفعال کردن کش جستجو باید جریمه کارایی کمتری نسبت به استفاده از noac داشته باشد، و هیچ تأثیری بر نحوه کش کردن ویژگی‌های فایل‌ها توسط کلاینت NFS ندارد.

گزینه اتصال sync (The sync mount option)

کلاینت NFS با گزینه اتصال sync متفاوت از برخی سیستم‌های پرونده دیگر رفتار می‌کند (برای توصیف گزینه‌های عمومی sync و async به mount(8) مراجعه کنید). اگر هیچ‌یک از گزینه‌های sync یا async مشخص نشوند (یا اگر گزینه async مشخص شود)، کلاینت NFS ارسال عملیات نوشتن برنامه به سرور را تا رخ دادن هر یک از این رویدادها به تأخیر می‌اندازد:

فشار حافظه باعث بازپس‌گیری منابع حافظه سیستم شود.

یک برنامه به صراحت داده‌های فایل را با sync(2)، msync(2)، یا fsync(3) تخلیه کند.

یک برنامه فایلی را با close(2) ببندد.

فایل از طریق fcntl(2) قفل یا باز شود.

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

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

برنامه‌ها می‌توانند از پرچم باز کردن O_SYNC استفاده کنند تا نوشتن برنامه در فایل‌های خاص را مستقیماً و بدون استفاده از گزینه اتصال sync به سرور بفرستند.

استفاده از قفل‌های فایل با NFS (Using file locks with NFS)

پروتکل مدیر قفل شبکه (NLM) یک پروتکل جانبی مجزا است که برای مدیریت قفل‌های فایل در نسخه ۳ پروتکل NFS استفاده می‌شود. برای پشتیبانی از بازیابی قفل پس از راه‌اندازی مجدد کلاینت یا سرور، پروتکل جانبی دوم - موسوم به پروتکل مدیر وضعیت شبکه (NSM) - نیز مورد نیاز است. در نسخه ۴ پروتکل NFS، قفل‌گذاری فایل مستقیماً در پروتکل اصلی NFS پشتیبانی می‌شود و پروتکل‌های جانبی NLM و NSM استفاده نمی‌شوند.

در بیشتر موارد، سرویس‌های NLM و NSM به طور خودکار شروع به کار می‌کنند و نیازی به پیکربندی اضافی نیست. تمام کلاینت‌های NFS را با نام‌های دامنه کاملاً مقید (FQDN) پیکربندی کنید تا مطمئن شوید که سرورهای NFS می‌توانند کلاینت‌ها را برای اطلاع‌رسانی در مورد راه‌اندازی مجدد سرور پیدا کنند.

پروتکل NLM فقط از قفل‌های فایل مشورتی (advisory locks) پشتیبانی می‌کند. برای قفل کردن فایل‌های NFS، از fcntl(2) همراه با دستورات F_GETLK و F_SETLK استفاده کنید. کلاینت NFS قفل‌های فایل به‌دست‌آمده از طریق flock(2) را به قفل‌های مشورتی تبدیل می‌کند.

هنگام اتصال به سرورهایی که از پروتکل NLM پشتیبانی نمی‌کنند، یا هنگام اتصال به یک سرور NFS از طریق فایروالی که درگاه سرویس NLM را مسدود می‌کند، گزینه اتصال nolock را مشخص کنید. قفل‌گذاری NLM باید هنگام استفاده از NFS برای اتصال /var با گزینه nolock غیرفعال شود زیرا /var شامل فایل‌های مورد استفاده توسط پیاده‌سازی NLM در لینوکس است.

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

ویژگی‌های کش در نسخه ۴ پروتکل NFS (NFS version 4 caching features)

رفتار کش داده‌ها و فراداده‌ها در کلاینت‌های نسخه ۴ پروتکل NFS مشابه نسخه‌های قبلی است. با این حال، نسخه ۴ دو ویژگی اضافه می‌کند که رفتار کش را بهبود می‌بخشد: ویژگی‌های تغییر (change attributes) و تفویض اختیار فایل (file delegation).

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

یک تفویض اختیار فایل (file delegation) قراردادی بین یک کلاینت و سرور نسخه ۴ پروتکل NFS است که به کلاینت اجازه می‌دهد با یک فایل موقتاً طوری رفتار کند که گویی هیچ کلاینت دیگری به آن دسترسی ندارد. سرور قول می‌دهد در صورتی که کلاینت دیگری بخواهد به آن فایل دسترسی پیدا کند، به کلاینت (از طریق یک درخواست فراخوانی مجدد/callback) اطلاع دهد. هنگامی که یک فایل به یک کلاینت تفویض شد، کلاینت می‌تواند داده‌ها و فراداده آن فایل را با اطمینان و بدون تماس مکرر با سرور کش کند.

تفویض اختیارهای فایل در دو نوع ارائه می‌شوند: خواندن (read) و نوشتن (write). تفویض اختیار خواندن به این معنی است که سرور به کلاینت درباره سایر کلاینت‌هایی که مایل به نوشتن در فایل هستند اطلاع می‌دهد. تفویض اختیار نوشتن به این معنی است که کلاینت از دسترسی‌های خواندن یا نوشتن دیگران مطلع می‌گردد.

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

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

گذر از سیستم‌های پرونده در نسخه ۴ پروتکل NFS (NFS version 4 filesystem crossing)

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

چنین مذاکره‌ای معمولاً زمانی اتفاق می‌افتد که کلاینت از سیستم پرونده شبه‌سیستمی (pseudo-fs) سرور به یکی از سیستم‌های پرونده فیزیکی به اشتراک گذاشته‌شده سرور وارد می‌شود، که اغلب تنظیمات امنیتی محدودکننده‌تری نسبت به pseudo-fs دارند.

اجاره‌ها در نسخه ۴ پروتکل NFS (NFS version 4 Leases)

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

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

بنابراین، هنگام برقراری یک اجاره، کلاینت باید خود را به سرور معرفی کند. هر کلاینت یک رشته دلخواه ارائه می‌دهد تا خود را از سایر کلاینت‌ها متمایز سازد. مدیر کلاینت می‌تواند رشته هویت پیش‌فرض را با استفاده از پارامتر ماژول nfs4.nfs4_unique_id تکمیل کند تا از تداخل با رشته‌های هویت سایر کلاینت‌ها جلوگیری به عمل آید.

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

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

هنگامی که Kerberos روی یک کلاینت NFS لینوکس پیکربندی شده باشد (یعنی یک پرونده /etc/krb5.keytab روی آن کلاینت وجود داشته باشد)، کلاینت تلاش می‌کند از یک شیوه امنیتی Kerberos برای عملیات مدیریت اجاره خود استفاده کند. کربروس احراز هویت امن هر کلاینت را فراهم می‌آورد. به طور پیش‌فرض، کلاینت از پرینسیپال سرویس host/ یا nfs/ در /etc/krb5.keytab خود برای این منظور استفاده می‌کند، همان‌طور که در rpc.gssd(8) شرح داده شده است.

اگر کلاینت دارای پیکربندی Kerberos باشد اما سرور این‌گونه نباشد، یا اگر کلاینت keytab یا پرینسیپال‌های سرویس لازم را نداشته باشد، کلاینت از AUTH_SYS و UID 0 برای مدیریت اجاره استفاده می‌کند.

استفاده از درگاه‌های مبدا غیرممتاز (Using non-privileged source ports)

کلاینت‌های NFS معمولاً از طریق سوکت‌های شبکه با سرورهای NFS ارتباط برقرار می‌کنند. به هر انتهای یک سوکت یک مقدار درگاه (پورت) اختصاص داده می‌شود، که عددی بین ۱ تا ۶۵۵۳۵ است و نقاط پایانی سوکت را در یک آدرس IP یکسان متمایز می‌سازد. یک سوکت به طور یکتا توسط یک چندتایی (تراپل) شامل پروتکل انتقال (TCP یا UDP) و مقادیر پورت و آدرس‌های IP هر دو نقطه پایانی تعریف می‌شود.

کلاینت NFS می‌تواند هر مقدار درگاه مبدایی را برای سوکت‌های خود انتخاب کند، اما معمولاً یک پورت دارای مجوز ویژه (privileged) را انتخاب می‌نماید. یک پورت دارای مجوز ویژه مقداری کمتر از ۱۰۲۴ دارد. فقط یک فرایند با دسترسی‌های ریشه (root) می‌تواند سوکتی با درگاه مبدا دارای مجوز ویژه ایجاد کند.

محدوده دقیق پورت‌های مبدا ممتازی که می‌توان انتخاب کرد توسط یک جفت از مقادیر sysctl تنظیم می‌شود تا از انتخاب درگاه‌های شناخته‌شده، مانند درگاه مورد استفاده توسط ssh، جلوگیری به عمل آید. این بدان معناست که تعداد پورت‌های مبدا موجود برای کلاینت NFS، و در نتیجه تعداد اتصالات سوکتی که می‌توانند همزمان استفاده شوند، عملاً تنها به چند صد عدد محدود است.

همان‌طور که در بالا توضیح داده شد، طرح سنتی و پیش‌فرض احراز هویت NFS، موسوم به AUTH_SYS، برای شناسایی کاربرانی که درخواست‌های NFS را ارسال می‌کنند بر ارسال شماره‌های UID و GID محلی متکی است. یک سرور NFS فرض می‌کند که اگر اتصالی از یک درگاه ممتاز برقرار شود، شماره‌های UID و GID در درخواست‌های NFS در این اتصال توسط هسته کلاینت یا مرجع محلی دیگری تأیید شده‌اند. این سیستم به راحتی قابل جعل (spoof) است، اما در یک شبکه فیزیکی مورد اعتماد میان میزبان‌های قابل اعتماد، کاملاً کافی است.

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

استفاده از پورت‌های مبدا غیرممتاز ممکن است تا حدی امنیت سرور را به خطر بیندازد، زیرا هر کاربری در نقاط اتصال AUTH_SYS اکنون می‌تواند هنگام ارسال درخواست‌های NFS وانمود کند که کاربر دیگری است. بنابراین سرورهای NFS به طور پیش‌فرض از این موضوع پشتیبانی نمی‌کنند. آن‌ها معمولاً این امکان را صریحاً از طریق یک گزینه اشتراک (export option) مجاز می‌سازند.

برای حفظ امنیت مناسب در حالی که امکان ایجاد بیشترین تعداد ممکن از نقاط اتصال فراهم باشد، بهتر است اتصالات کلاینت غیرممتاز تنها در صورتی مجاز باشند که هم سرور و هم کلاینت به احراز هویت قوی، مانند Kerberos، نیاز داشته باشند.

اتصال از میان فایروال (Mounting through a firewall)

ممکن است یک فایروال بین کلاینت و سرور NFS قرار داشته باشد، یا کلاینت یا سرور ممکن است برخی از درگاه‌های خود را از طریق قوانین فیلتر IP مسدود کنند. هنوز هم امکان اتصال به سرور NFS از پشت فایروال وجود دارد، اگرچه ممکن است برخی از سازوکارهای شناسایی خودکار نقاط پایانی سرویس در دستور mount(8) کار نکنند؛ این امر مستلزم آن است که جزئیات دقیق نقاط پایانی را از طریق گزینه‌های اتصال NFS ارائه دهید.

سرورهای NFS معمولاً یک دیمن portmapper یا rpcbind را برای اعلام نقاط پایانی سرویس خود به کلاینت‌ها اجرا می‌کنند. کلاینت‌ها از دیمن rpcbind استفاده می‌کنند تا تعیین نمایند:

هر سرویس مبتنی بر RPC از چه پورت شبکه‌ای استفاده می‌کند

هر سرویس مبتنی بر RPC از چه پروتکل‌های انتقالی پشتیبانی می‌کند

دیمن rpcbind از یک شماره درگاه شناخته‌شده (۱۱۱) برای کمک به کلاینت‌ها در یافتن نقطه پایانی سرویس استفاده می‌کند. اگرچه NFS اغلب از یک درگاه استاندارد (۲۰۴۹) استفاده می‌کند، سرویس‌های کمکی مانند سرویس NLM می‌توانند هر درگاه استفاده‌نشده‌ای را به صورت تصادفی انتخاب نمایند.

پیکربندی‌های معمول فایروال، پورت شناخته‌شده rpcbind را مسدود می‌کنند. در غیاب سرویس rpcbind، مدیر سرور شماره پورت سرویس‌های مرتبط با NFS را ثابت می‌کند تا فایروال بتواند اجازه دسترسی به درگاه‌های خاص سرویس NFS را بدهد. سپس مدیران کلاینت شماره درگاه سرویس mountd را از طریق گزینه mountport دستور mount(8) مشخص می‌کنند. همچنین در صورتی که فایروال یکی از پروتکل‌های انتقال را مسدود کند، ممکن است اجبار به استفاده از TCP یا UDP ضروری باشد.

فهرست‌های کنترل دسترسی NFS (NFS Access Control Lists)

سیسستم‌عامل Solaris به کلاینت‌های نسخه ۳ پروتکل NFS اجازه دسترسی مستقیم به فهرست‌های کنترل دسترسی POSIX (ACL) ذخیره‌شده در سیستم‌های پرونده محلی خود را می‌دهد. این پروتکل جانبی اختصاصی موسوم به NFSACL کنترل دسترسی غنی‌تری نسبت به بیت‌های حالت (mode bits) فراهم می‌کند. لینوکس این پروتکل را برای سازگاری با پیاده‌سازی NFS سولاریس اجرا می‌نماید. با این حال، پروتکل NFSACL هرگز به بخشی استاندارد از مشخصات نسخه ۳ پروتکل NFS تبدیل نشد.

مشخصات نسخه ۴ پروتکل NFS نسخه جدیدی از فهرست‌های کنترل دسترسی را الزامی می‌سازد که از نظر معنایی غنی‌تر از ACLهای POSIX هستند. ACLهای نسخه ۴ پروتکل NFS کاملاً با ACLهای POSIX سازگار نیستند؛ به همین دلیل، در محیطی که ترکیبی از ACLهای POSIX و نسخه ۴ پروتکل NFS استفاده می‌شود، مقداری تبدیل و ترجمه بین این دو مورد نیاز است.

لغو اتصال پس از اتصال مجدد (Unmounting after a remount)

برای نقاط اتصالی که از نسخه‌های ۲ یا ۳ پروتکل NFS استفاده می‌کنند، زیردستور umount مربوط به NFS به دانستن مجموعه اصلی گزینه‌های اتصال مورد استفاده برای انجام عملیات MNT متکی است. این گزینه‌ها توسط زیردستور mount مربوط به NFS روی دیسک ذخیره می‌شوند و ممکن است توسط یک اتصال مجدد پاک شوند.

برای اطمینان از اینکه گزینه‌های اتصال ذخیره‌شده در طول اتصال مجدد پاک نمی‌شوند، در حین اتصال مجدد یا دایرکتوری اتصال محلی یا نام میزبان سرور و مسیر اشتراک را مشخص کنید، نه هر دو را. برای مثال:

mount -o remount,ro /mnt

گزینه اتصال ro را با گزینه‌های اتصال از پیش ذخیره‌شده روی دیسک برای سرور NFS متصل‌شده در /mnt ادغام می‌کند.