☰

掛載 NFS：所有者是無人：nogroup

tag-icon • tag-icon nfs
掛載 NFS：所有者是無人：nogroup

我使用以下程式碼從 shell 安裝了 NFS 檔案系統：

LINE='nfs.mit.edu:/export/evodesign/beatdb /beatdb nfs tcp,intr,rw 0 0'
grep "$LINE" /etc/fstab >/dev/null || echo $LINE >> /etc/fstab
mkdir /beatdb
mount -a # Remount /etc/fstab Without Reboot in Linux

我將文件顯示為無人：無群組：

在此輸入影像描述

有辦法解決這個問題並顯示正確的所有者嗎？

我使用Ubuntu 12.04。

編輯：

客戶端（我無權存取 NFS 伺服器）：

rpcidmapd在跑：

在此輸入影像描述

rpcinfo -p:

在此輸入影像描述

/etc/idmapd.conf:

在此輸入影像描述

答案1

尋求本地支援或文件聽起來是一個非常好的主意:)。

以清單形式，我認為你需要

1) 在客戶端系統上建立所需的使用者。這可以手動完成，但您應該期望有一個可以設定的自動「目錄服務」。可能是 LDAP。

2）客戶端和伺服器之間的使用者映射。在 NFS4 中（由 tcp 選項暗示）正如 gareth 所提到的，這是由 idmapd 處理的。您只需要設定網域以匹配伺服器的想法。跨域不行，我認為這是Linux的限制。

3) kerberos 向伺服器驗證您自己的身分（在 NFS4 中可用）。如果您想以“nobody”之外的其他人的身份存取任何文件，那麼這絕對是需要的。我建議首先配置和測試 kerberos。配置它包括設定一個網域 - 您將在 idmapd.conf 中設定相同的網域。

或使用 NFS3 樣式的身份驗證，將跳過 3)，而不是 2)，您只需確保使用者的數位 UID 與伺服器的數位 UID 相符即可。這僅在伺服器信任客戶端的情況下使用:)。

答案2

我追查了類似的問題。設定 /etc/idmapd.conf Verbosity=3 有助於查看 Ubuntu 上的一些問題，但不是全部。以下是我的發現的摘要：

您的 /etc/passwd 和群組檔案仍然有可能不會與提供共用的電腦共用相同的使用者/群組。這是一個提示，您的本機電腦必須具有類似的使用者/群組名稱對應。 /etc/nsswitch.conf 否則 idmapd 的映射操作將會失敗。請注意，如果執行 Verbosity=3，您將在 /var/log/syslog 中看到一個條目，例如：

idmapd[25193]：客戶端 64：（群組）名稱「TheGroupNameYouExpected」-> id「65534

如果您修改/etc/nsswitch.conf 以對應到檔案以外的其他內容（例如ldap 或nis），那麼您還需要確保ldap 或nis 對於您想要ID 轉換的使用者名稱或群組名稱有某種類型的實際條目為了。如果條目不存在，idmapd 將無法成功映射使用者/群組。

在相關問題中，我發現 RHEL v7 不再需要為 NFS 用戶端啟用 idmapd.conf 服務：

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

然而，上述線程中存在一個運行問題，即預設情況下，執行自動 ID-用戶名映射的服務在記憶體中保留映射的 id 數量非常少。 idmapd 不會記錄錯誤，只是拒絕翻譯超過 200 個使用者。您可以從目前的內核設定中驗證這一點：

cat /proc/sys/kernel/keys/root_maxkeys

200 很可能是預設值。若要允許 NFS 掛載點正確地對應所有可用用戶，您需要變更此檔案：

/etc/sysctl.conf

並如下新增或修改這些行：

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

您的系統可能不需要那麼多的使用者/ID 鍵映射，因此請根據需要進行調整。這將允許所有 id-name 鍵在使用 NFS 掛載時保持映射狀態。這是另一個相關的帖子，顯示了當前的內核設定：

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

對於這些值：

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

最有可能的 maxbytes 和 root_maxbytes 必須足夠大才能儲存所有鍵：

https://www.kernel.org/doc/Documentation/security/keys.txt

答案3

另一個清單，假設您正在使用 Kerberos 執行 NFSv4：

  • kinit，然後看看klist。您應該看到一張票；如果沒有，請先尋找如何修復 Kerberos 驗證的答案。
  • 在rpc.gssd跑？您可能想要啟動該服務；另外，在某些發行版上，它不會自動啟動，除非您在/etc/fstab.
  • 在rpc.idmapd跑？ （同樣，這通常應該由客戶端 nfs 服務啟動；ls /etc/init.d/是一個很好的起點。
  • 看著/etc/idmapd.conf。 「網域」部分與您的 NFS 伺服器的實際網域相符嗎？ （...如果沒有別的辦法，您可以嘗試使用 Kerberos 領域。）我看到一些發行版不需要它，而有些發行版則需要它；也許在某些方面，它有更合理的 FQDN 預設值。
  • 也加入GSS_principal_attr = GSSAuthName到文件中。僅網域可能會解決一些所有權問題，但看起來這對於例如目錄也是需要的。
  • 至少重新啟動rpc.idmapd一次調整配置。調整配置後不需要重新安裝，但這並沒有什麼壞處。
  • 也! nfsidmap -c。顯然，有一個快取即使重新啟動也不會被清除；這將清除它。 （否則你可能會一直認為修復不起作用，即使它起作用了。）

相關內容