由於 MS 最近取消了對 Windows 7 的支持，我們終於讓最後一批頑固的 Windows 7 用戶轉向了 Windows 10，所以現在整個企業要么是 Ubuntu 18.04，要么是 Windows 10。
由於 Windows 10 有 NFS 用戶端，因此現在的問題是是否放棄 SAMBA 而改用 NFS。
具體來說，既然我們所有的 Windows 用戶端都支援 NFS，是否還有理由保留 SAMBA？
答案1
SMB 3.xx 比「通用」TCP 連線具有更好的調整效能，並且具有 RDMA 和多通道支援等 Microsoft 未通過「他們的」（實際上是許可的）NFS 用戶端實現的功能。
答案2
Samba 軟體使用的伺服器訊息區塊 (SMB) 協定可能更容易部署且具有足夠的安全性。網路檔案系統，簡稱NFS，被戲稱為「無檔案安全」。這是一個開玩笑的名稱，但「無檔案級安全性」可能是一個具有某些準確含義的名稱。換句話說，NFS 安全性是基於共用分割區，而不是單一文件，因此 NFS 協定不強制執行文件級權限。
根據我的閱讀，NFS 伺服器有可能關注文件並拒絕無效請求。然而，並非所有 NFS 軟體都會這樣做。該協定傾向於讓客戶端請求磁碟機上的資料區塊，伺服器可以透過從磁碟讀取該資料區塊來滿足該請求，而不必注意該資料區塊屬於哪個檔案。
即使您發現 NFS 實作是安全的，什麼可以防止後續變更導致 NFS 實施/部署安全性降低的可能性？如果您有安全疑慮，那麼回答這樣的問題可能非常值得。
使用 SMB，人們共享目錄而不是分區。這可以幫助您確信您只是共享您想要共享的目錄，而不是位於磁碟機層次結構不同部分的其他目錄。
編輯：新的挑戰者來了。對此答案的評論聲稱這是偏離目標的。因此，我尋找了一些歷史悠久的文檔來幫助支持這一點。我很容易找到支持我的回答的材料：
首先也是最重要的，“安全網路公司”發布了 1997 年 3 月 7 日發布的“安全警告”，標題為“4.4BSD NFS 檔案句柄”。 （此超連結來自 OpenBSD 網站：SecList.org BugTraq 郵件清單存檔（1997 年）：4.4BSD NFS 檔案句柄顯示作為舊郵件清單的一部分發布的相同內容，但添加了標題。 PacketStormSecurity：SNI BSD 檔案處理諮詢也顯示了相同的文檔。
本文討論 NFS 如何提供資料的基於區塊的性質（這可能是我對這個特定漏洞的理解的來源）。
該文件由多個組織託管。這是一份不同的報告，顯然與該文件完全無關：“Why NFS Sucks”，作者：“SUSE/Novell Inc.”的“Olaf Kirch”[電子郵件受保護]說：
“NFS 並不關心您導出的是 reiser、ext3 還是 XFS、CD 還是 DVD。其直接後果是 NFS 需要一種相當通用的機制來識別駐留在文件系統上的對象。” ...“只有伺服器需要了解文件句柄的內部格式。” ...「Linux 引入了目錄快取的概念，又稱為 dcache。dcache 中的條目稱為 dentry」...「幾乎 VFS 層中的所有函數都希望使用 dentry 作為參數，而不是（或另外）到）他們曾經使用的inode 物件。 「這使得 NFS 伺服器變得有趣，因為 inode 資訊不再足以創建 VFS 層願意操作的內容」...「攻擊者可以攔截具有有效憑證的資料包並修改 NFS 請求以執行操作自己的邪惡命令。 」
至於我對暱稱的主張， https://news.ycombinator.com/item?id=10967064備份：
1987 年，Sun 的工程師都知道 NFS 代表“No File Security”
第一個畫面顯示了一些不同的漏洞，包括根據客戶端電腦報告的主機名稱來信任某人。
Google Books：引用《A Practical Guide to Ubuntu Linux》中的資料筆記：
預設 NFS 安全性微不足道甚至不存在（一個常見的笑話是 NFS 代表「無檔案安全」或「惡夢檔案系統」），因此不應允許網路外部對您不信任的電腦進行此類存取。
eTutorials.org 有關 NFS 配置的部分筆記：
如果你透過網路掛載你的檔案系統，傳輸的檔案隨時可能受到干擾甚至竄改（有人開玩笑說NFS是「No File Security」的縮寫）。