為什麼 NFSv4 不能以可用的方式翻譯 POSIX ACL？
我有一個 XFS 文件系統，其中某些文件夾（使用模式設置）沒有公共可訪問性，組所有者俱有隻讀權限。有一個程序（以使用者 cryosparc_user 執行）需要對所有文件的讀取權限，所以我添加了一個預設的 POSIX ACL 授予 cryosparc_user 讀取權限。
不幸的是，大部分處理都是在 NFSv4 掛載此文件系統的工作站上完成的，並且由於某種原因，POSIX ACL 沒有在工作站上被翻譯或接受（嗯，它們是，但顯然不是以可用的方式），我可以不知道為什麼。
伺服器和工作站都在執行 Ubuntu 18.04，我不能簡單地將 cryosparc_user 添加到組中，因為該組是 Active Directory 安全組（我們正在通過 AD 進行身份驗證），而 cryosparc_user 是本地使用者，不能在 AD 中設置。
以下是文件伺服器上的權限：
root@kraken:/EM/EMtifs# getfacl pgoetz # file: pgoetz # owner: pgoetz # group: cns-cnsitlabusers user::rwx group::r-x other::--- default:user::rwx default:user:cryosparc_user:r-x default:group::r-x default:mask::r-x default:other::--- root@kraken:/EM/EMtifs# id cryosparc_user uid=1017(cryosparc_user) gid=1017(cryosparc_user) groups=1017(cryosparc_user),10002(mclellan),10003(taylorlab)以下是它們在安裝了 NFSv4 的工作站上的樣子：
root@javelina:/EM/EMtifs# getfacl pgoetz # file: pgoetz # owner: pgoetz # group: cns-cnsitlabusers user::rwx group::r-x other::--- root@javelina:/EM/EMtifs# id cryosparc_user uid=1017(cryosparc_user) gid=1017(cryosparc_user) groups=1017(cryosparc_user) root@javelina:/EM/EMtifs# nfs4_getfacl pgoetz A::OWNER@:rwaDxtTcCy A::GROUP@:rxtcy A::EVERYONE@:tcy A:fdi:OWNER@:rwaDxtTcCy A:fdi:1017:rxtcy A:fdi:GROUP@:rxtcy A:fdi:EVERYONE@:tcy請注意 NFS4 ACL 查詢中倒數第三行。似乎為 cryosparc_user 使用者提供了讀取權限（兩個系統上的本地 UID 均為 1017），但是
cryosparc_user@javelina:/EM/EMtifs$ whoami cryosparc_user cryosparc_user@javelina:/EM/EMtifs$ ls pgoetz ls: cannot open directory 'pgoetz': Permission denied從我讀過的所有內容來看，沒有要設置的掛載標誌或類似的東西；這應該會自動工作，我不知道為什麼它不工作。
我的備份計劃是恢復在這些文件夾上使用本地組（以便可以將 cryosparc_user 添加到本地組），但這需要在每個系統上複製 AD 身份驗證結構，這將是一個維護難題。
另一個想法是也使用 cryosparc_user 使用者憑據對該文件系統進行只讀 SMB 掛載，但我對雙重掛載 500T 文件系統也不是很興奮。我寧願身份驗證以合理的方式工作。
我的問題原來是未能理解 POSIX ACL 的工作原理。特別是我假設預設ACL 在它們已應用到的目錄上設置權限，而實際上這些僅適用於在將預設 ACL 應用於父對象之後創建的子目錄和文件，實際上並不應用父對象完全反對。
讓我知道的是 NFS 開發人員列出的關於此問題的上訴。一位開發人員指出（知道這一點很重要），NFS 對此完全不可知，只是訴諸伺服器底層文件系統上設置的權限。這為我指明了查看伺服器文件系統上的 POSIX ACL 的方向，並且——經過一些實驗（這沒有很好的記錄）——我實現了上述功能並重新創建了 POSIX ACL 以實際執行我希望他們執行的操作. 之後這個問題就消失了。