rw
讀寫權(quán)限（默認(rèn)）
rw= list
通過 list 指定具有寫權(quán)限的客戶端主機(jī)，其他主機(jī)則為只讀權(quán)限
root_squash
將 UID 0 和 GID 0 映射到 anonuid 和 anongid（即 Ubuntu 系統(tǒng)中的 nobody 和 nogroup）
no_root_squash
允許需要 root 權(quán)限的文件操作，有安全風(fēng)險(xiǎn)
all_squash
將所有的 UID 和 GID 映射到它們的匿名形式，主要針對(duì)不信任的主機(jī)
anonuid= xxx
指定客戶端 root 權(quán)限的操作需要映射到的 UID（默認(rèn)是65534）
anongid= xxx
指定客戶端 root 權(quán)限的操作需要映射到的 GID（默認(rèn)是65534）
insecure
允許通過任意端口的遠(yuǎn)程訪問
async
服務(wù)器可以在寫入硬盤之前響應(yīng)客戶端的寫入請(qǐng)求
wdelay
通過延遲同步多個(gè)客戶端對(duì)文件的更新
sec= flavor
指定共享目錄的安全驗(yàn)證方法，包括 sys （UNIX 驗(yàn)證）， dh (DES)， krb5i ， krb5p 和 none （匿名訪問）
3. NFS 掛載選項(xiàng)
rw
以讀寫模式掛載文件系統(tǒng)（rw 也需在服務(wù)端定義）
ro
以只讀模式掛載文件系統(tǒng)
bg
如掛載失敗（服務(wù)器無響應(yīng)），在后臺(tái)繼續(xù)嘗試并執(zhí)行其他掛載請(qǐng)求
hard
如果服務(wù)器無響應(yīng)，重復(fù)發(fā)送請(qǐng)求直到服務(wù)器回復(fù)
soft
如果服務(wù)器無響應(yīng)，重復(fù)發(fā)送請(qǐng)求，超過一定時(shí)間后返回錯(cuò)誤，而不會(huì)一直阻塞
intr
允許用戶中斷阻塞的文件操作（并返回錯(cuò)誤）
nointr
不允許用戶中斷客戶端的文件操作請(qǐng)求
retrans= n
在 soft 模式下，指定返回錯(cuò)誤前重復(fù)發(fā)送請(qǐng)求的次數(shù)
timeo= n
設(shè)置超時(shí)后重復(fù)發(fā)送請(qǐng)求的時(shí)間間隔（單位 1/10 秒）
rsize= n
設(shè)置讀取 buffer 大小為 n bytes
wsize= n
設(shè)置寫入 buffer 大小為 n bytes
sec= flavor
設(shè)置安全驗(yàn)證方法
proto= proto
設(shè)置傳輸協(xié)議，NFSv4 必須為 TCP
4. NFS 協(xié)議討論
傳輸協(xié)議
最初的 NFSv2 由于性能原因使用 UDP 協(xié)議，雖然 NFS 添加了自己的 包序列重組 和 錯(cuò)誤檢查 功能，但 UDP 和 NFS 都不具備 阻塞控制 算法，所以在大型的互聯(lián)網(wǎng)絡(luò)環(huán)境中缺乏足夠的性能。
NFSv3 提供了 UDP 和 TCP 協(xié)議之間的選擇。NFSv4 只能使用 TCP 協(xié)議。
隨著 CPU，內(nèi)存等硬件設(shè)備和網(wǎng)絡(luò)傳輸速度的提高，最初由于性能需求而傾向 UDP 協(xié)議的選擇也變得不再必要。
State
NFSv2 和 NFSv3 是 無狀態(tài) 的連接，服務(wù)端不會(huì)跟蹤客戶端對(duì)共享目錄的掛載情況，而是使用 cookie 來記錄一次成功的掛載。cookie 不會(huì)因?yàn)榉?wù)器重啟而刪除，可以用來在服務(wù)器掛掉之后保留客戶端的連接信息。
NFSv4 是 有狀態(tài) 的連接，客戶端和服務(wù)端都會(huì)維護(hù)文件操作紀(jì)錄及文件鎖的狀態(tài)。所以不再需要 cookie 的使用。
文件鎖
早期版本的 NFS 協(xié)議（v2 & v3）由于是 無狀態(tài) 的連接，它們并不清楚哪些主機(jī)正在使用哪些文件。但是文件鎖的實(shí)現(xiàn)又需要獲取狀態(tài)信息。所以早期協(xié)議中的文件鎖是獨(dú)立于 NFS 實(shí)現(xiàn)的。
而 NFSv4 將文件鎖的實(shí)現(xiàn)整合到了核心協(xié)議中，雖然此舉增加了復(fù)雜度，但同時(shí)也解決了早期版本中的很多問題。
但是為了兼容使用 V2 和 V3 協(xié)議的客戶端，獨(dú)立的 locked 和 statd 守護(hù)進(jìn)程仍舊需要。
安全相關(guān)
NFS 協(xié)議最初在設(shè)計(jì)時(shí)并不關(guān)注安全性，NFSv4 通過引入對(duì)更強(qiáng)大的安全服務(wù)和身份驗(yàn)證的支持，加強(qiáng)了該協(xié)議的安全性。
傳統(tǒng)的 NFS 協(xié)議大多使用 AUTH_SYS 驗(yàn)證方式，基于 UNIX 的用戶和組標(biāo)識(shí)。在這種方式下，客戶端只需要發(fā)送自己的 UID 和 GID 并與服務(wù)器上的 /etc/passwd 文件內(nèi)容作對(duì)比，以決定其擁有怎樣的權(quán)限。
所以當(dāng)多個(gè)客戶端存在 UID 相同的用戶時(shí)，這些用戶會(huì)擁有相同的文件權(quán)限。更進(jìn)一步，擁有 root 權(quán)限的用戶可以通過 su 命令切換到任意 UID 登錄，服務(wù)器會(huì)因此給予其對(duì)應(yīng) UID 的權(quán)限。
為了防止上面的問題出現(xiàn)，服務(wù)器可選擇使用更健壯的驗(yàn)證機(jī)制比如 Kerberos 結(jié)合 NFS PRCSEC_GSS。
NFS 共享目錄的訪問控制基于 /etc/exports 文件中定義的主機(jī)名或 IP 地址。但是客戶端很容易針對(duì)其身份和 IP 地址造假，這也會(huì)導(dǎo)致一些安全問題。
NFSv4 只使用 TCP 作為自己的傳輸協(xié)議，而且通常只開放 2049 端口進(jìn)行數(shù)據(jù)傳輸。在配置防火墻時(shí)，除了放開 2049 端口的限制外，還要時(shí)刻注意數(shù)據(jù)傳輸?shù)脑吹刂泛湍繕?biāo)地址。
5. Windows 系統(tǒng)掛載共享目錄
win10 系統(tǒng)默認(rèn)不能掛載 NFS 共享目錄，需要進(jìn)入 控制面板 – 程序 – 程序和功能 – 啟用或關(guān)閉 Windows 功能 ，勾選上 NFS 服務(wù) 。
啟用 nfs 服務(wù)
之后就可以使用 mount 命令掛載共享目錄了。
mount 命令掛載共享目錄
只是 Windows 系統(tǒng)并不使用 Linux 那樣的用戶管理，導(dǎo)致掛載的共享目錄只能讀取而沒有寫入的權(quán)限。
無法寫入文件
解決辦法是在 注冊(cè)表 中新建兩個(gè) DWORD 值，用作 匿名用戶 的 UID 和 GID。
默認(rèn)參數(shù)下的掛載選項(xiàng)，UID 和 GID 都為 -2：
默認(rèn)掛載選項(xiàng)
可進(jìn)入 注冊(cè)表編輯器 （ regedit ），定位到 HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\Microsoft\\\\ClientForNFS\\\\CurrentVersion\\\\Default ，新建兩個(gè)名為 AnonymousUid 和 AnonymousGid 的 DWORD（32位）值，改成自己需要用到的數(shù)字（我都改成了 0 ，即對(duì)應(yīng) Linux 系統(tǒng)中的 root 用戶。如需要改為 0 以外的數(shù)字，注意先轉(zhuǎn)換成 16 位）。
此時(shí)的掛載選項(xiàng)變?yōu)椋?/p>
更改 UID 和 GID
如更改未生效，可重啟電腦。
參考資料
UNIX and Linux System Administration Handbook, 4th Edition
How to Mount an NFS Share Using a Windows 10 Machine
以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持三五互聯(lián)。
更多關(guān)于云服務(wù)器，域名注冊(cè)，虛擬主機(jī)的問題，請(qǐng)?jiān)L問三五互聯(lián)官網(wǎng)：m.shinetop.cn
