nfs 為 linux 客戶端上的所有使用者安裝 rw nexenta 共享 - 失敗
情況：
我們使用 Nexenta 設備進行 NFS 文件服務 (nfs v3)。我們正在共享一條匿名讀/寫訪問的路徑。
我們有一個 Linux 主機，我們想掛載該導出的讀/寫共享，並允許匿名讀/寫訪問該客戶端機器上的掛載共享。不幸的是，最終發生的是 root 可以寫入共享，但非特權使用者不能。
使用以下方法掛載共享：
# mount -t nfs -o rw 10:10:xx:xx:/path/to/share /mnt/mounted_path # mount -t nfs -o rw,users 10:10:xx:xx:/path/to/share /mnt/mounted_path # mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -o rw我們有特定使用者打算用於共享上的匿名使用。所以我嘗試以該使用者身份安裝卷：
# su - shared_user $ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw mount.nfs: an incorrect mount option was specified去讀了一些：http: //nfs.sourceforge.net/nfs-howto/ar01s06.html。
決定嘗試以下方法，嘗試安裝時會出現以下錯誤：
# mount -t nfs -orw,no_root_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path mount.nfs: an incorrect mount option was specified # mount -t nfs -orw,nroot_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path # for grins and giggles. mount.nfs: an incorrect mount option was specified $ sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw,no_root_squash mount.nfs: an incorrect mount option was specified我只是 SOL 還是我在這裡根本缺少什麼？這是我試圖尋找的聖杯嗎？我從來沒有大量使用過 NFS，所以現在我有點不知所措。蒂亞！
好的。弄清楚了。首先，我使用的 Nexenta 版本是 3.1.3.5。Nexenta 是一個基於 OpenSolaris 的設備，它通過 CIFS、NFS、Rsync、WebDAV 和 FTP 提供塊儲存。在我們的例子中，我們僅將它用於 NFS（預設為 v3。v4 不適用於此版本）。
所以，tl；博士；在 Nexenta 方面：
以 root 身份登錄 Nexenta：
$ ssh root@xx.xx.xx.xx Password: Last login: Wed Aug 24 11:17:33 2016 from xx.xx.xx.xx nmc@nex01:/$ option expert_mode = 1 nmc@nex01:/$ !bash You are about to enter the Unix ("raw") shell and execute low-level Unix command(s). Warning: using low-level Unix commands is not recommended! Execute? Yes root@nex01:/volumes# root@nex01:/volumes# grep nfs /etc/passwd nfs:x:60001:60001:NFS Anonymous Access User:/:/bin/sh注意第一個後面的數字
x:#####:#####——它們分別是 uid 和 gid。在客戶端：創建使用者：
# groupadd nfs -g 60001 && useradd nfs -g 60001 ## untested. I did it the long way through natural process of elimination, so be careful here.現在一切都好。
掛載卷並驗證您新創建的 nfs 使用者是否可以寫入 NFS 卷。
長版：
據我所知，我已經正確設置了 NFS 端。該文件很有幫助，但在某些方面它只是劃分麵包屑。
“允許匿名訪問此共享。共享頂級目錄將被授予匿名使用者 ’nfs’ 的讀寫訪問權限。如果遞歸共享模式設置為 true，此屬性將傳播到現有子文件夾。請注意，匿名讀取/write 訪問不可繼承 - 除非明確請求，否則不允許匿名訪問未來的子文件夾。匿名使用者名是 ’nfs’。"
我
shared_user最終變成了“nfs”，但仍然失敗（參見 OP）。我決定，因為我認為這是一個很長的嘗試，讓我在客戶端的 UID 與設備上“nfs”的 UID 匹配。我必須登錄到設備，啟動一個 bash shell，然後執行id命令來獲取 UID，在我的例子中是 60001。在客戶端上，我更改了
nfs使用者以匹配設備上的 UID。顯然，該設備確實需要 UID/GID 與其自己的匹配才能正常工作。我認為 NFS 伺服器會忽略這一點。這顯然是問題的癥結所在。現在，該設備將 nfs:nobody 用於 user:group。
nobody在客戶端（Linux）端是一個不同的 UID，並且為任何人更改 UID 會涉及更多一點，我不知道通過更改該 groupid 會無意中影響什麼，所以我沒有碰它。在我開始胡鬧之前，客戶端機器上的nfs使用者是不存在的，所以沒有破壞任何東西的風險。客戶端有一個nfsnobody。我沒有測試使用它，我很確定它不會起作用，因為文件是特定於使用者 ID 的。我還應該在這裡聲明，該設備專門設置為使用 sysauth 進行身份驗證。使用 auth=none 不是一個選項，因為 NFSv3 似乎不喜歡它。:)
就這些。