對於 NFS 共享，root 的補充組的行為是否與正常帳戶的不同？

作業系統：Linux CentOS 7、NFSv4

在一台機器上，我導出了一個由nfsgroup擁有的 NFS 共享組，具有 2770 組協作權限：

groupadd -g 5000 nfsgroup
chown nobody:nfsgroup /home/groupshare
chmod 2770 /home/groupshare

然後，在另一台機器上，我添加了相同的組並將其分配給 root 使用者。然後我嘗試訪問已安裝的 NFS 共享並收到“權限被拒絕”錯誤：

groupadd -g 5000 nfsgroup
usermod -a -G nfsgroup root
ls -l /mnt/groupshare       # Permission denied!

注意：為此，我嘗試以 root 身份重新登錄，甚至重新啟動機器，結果是一樣的：權限被拒絕。

然後我為普通帳戶（名為user）做同樣的事情並且沒有訪問問題

usermod -a -G nfsgroup user
su - user
ls -l /mnt/groupshare      # Works as expected, no permission errors

我可以訪問根目錄下的共享的唯一方法是更改​​有效組（儘管存在補充nfsgroup）：

su - root
newgrp nfsgroup
ls -l /mnt/groupshare     # No permission errors

我發現這種行為不一致且奇怪。有人可以闡明為什麼它會這樣嗎？

一條資訊，可能以某種方式相關，如下所示。id（在使用者帳戶下）並id user返回相同的輸出，特別是groups=1000(user),5000(nfsgroup)，而id（在root帳戶下）產生groups=0(root)並按id root預期輸出groups=0 (根),5000(nfsgroup)。

我想我找到了導致問題的原因。當 NFS 客戶端訪問 NFS 共享時，伺服器會檢查訪問使用者的 UID 和 GID。預設情況下，NFS 伺服器root_squash啟用了選項，該選項將 NFS 客戶端分配為以 root 身份訪問共享的nfsnobody的 UID/GID 。

在我將no_root_squash選項添加到文件中的導出後/etc/exports，問題就消失了。

顯然，當 NFS 伺服器“壓縮”根的 UID/GID 時，它完全忽略了補充組（對我來說似乎是錯誤的，但 NFSv4 標準可能有不同的想法）。

引用自：https://unix.stackexchange.com/questions/171284