Samba 擴展 ACL 限制使用者，即使他們位於共享的授權 AD 組中？

通過 SMB+WinBind 為 CentOS 7 文件伺服器設置Samba 擴展 ACL ( https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs#Samba_Extended_ACL_Support ) 以在 Windows 10 桌面（特別是 Citrix VDI 桌面）上掛載共享. 然而，當嘗試訪問某些共享（但不是全部）時，我看到我的使用者訪問被拒絕（收到諸如“句柄無效”或“Windows 無法訪問”文件夾和“訪問被拒絕”文件之類的錯誤），即使我的測試使用者是共享安全屬性的 AD 組的一部分（根據文件，https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs#Setting_Share_Permissions_and_ACLs）。

當登錄到 smb linux 伺服器本身時，我可以看到groups命令的輸出顯示測試使用者確實在所有必需的 AD 組中（但即使在伺服器本身上，我也無法訪問我表面上具有 AD 的一些文件夾權限（例如導航到較低級別的文件夾或head -n 10 <filename>在文件上執行））。

例如。我將文件夾設置為 SMB 共享，例如…

/datastore    <----share
   /data
       /dataset1    <----share
           ...
           <data files and folders>
       /dataset2    <----share
           ...
           <data files and folders>
       /dataset3    <----share
           ...
           <data files and folders>

…並且將/datastore所有/datastore/data/dataset...文件夾作為 smb 共享和我的測試使用者添加到組中，該組具有對引用、、和連接到 smb 伺服器的電腦管理 UI 的共享的讀取訪問權限datastore（dataset1根據dataset2Samba 擴展 ACL 文件）。（我發現如果您想為較低層次結構的共享文件夾設置更細粒度的共享權限，您需要為父級文件夾授予使用者 NTFS/安全權限，因為他們需要能夠一直訪問路徑（LMK 如果這是錯誤的，可能會導致問題））。

在 Windows 上安裝datastore共享時，我發現我的測試使用者可以在 中打開內容/datastore/data/dataset1並且（如預期的那樣）無法在 中打開內容/datastore/data/dataset3，但也無法訪問/datastore/data/dataset2. （我已經三重檢查，並且確實似乎被列為共享安全選項卡中列出的 AD 組的成員）。

任何對此有更多經驗的人對可能發生的事情有任何想法嗎？這篇文章應該包含更多的調試資訊嗎？

（注意：我在此處發布了一個類似的問題，但針對的是一個幾乎完全相反的問題（尚未在此處發布答案，因為這是同一測試過程的一部分，因此所有這些掛斷的確切診斷仍不清楚））

---

以供參考…

（雖然我認為這裡沒有任何問題），我的/etc/samba/smb.conf文件看起來像……

[root@myserver ~]# cat /etc/samba/smb.conf
[global]

security = ads
#  password server = adcontrollerserver.myorg.local
#  dedicated keytab file = /etc/krb5.keytab
encrypt passwords = yes
log file = /var/log/samba/%m.log
log level = 3

winbind refresh tickets = yes
vfs objects = acl_xattr
map acl inherit = Yes
# the next line is only required on Samba versions less than 4.9.0
#  store dos attributes = Yes
winbind use default domain = yes
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
idmap config * : backend = tdb
idmap config * : range = 10000000-10999999
idmap config MYDOMAIN : backend = ad
idmap config MYDOMAIN : schema_mode = rfc2307
idmap config MYDOMAIN : range = 10000-20000
idmap config MYDOMAIN : unix_nss_info = yes
#  idmap config MYDOMAIN : unix_primary_group = no
username map = /usr/local/samba/etc/user.map
winbind enum users = yes
winbind enum groups = yes
# Template settings for login shell and home directory
template shell = /bin/bash
template homedir = /home/%U
kerberos method = system keytab
workgroup = MYDOMAIN
realm = MYDOMAIN.LOCAL
winbind offline logon = yes

# all the various share names, eg...
[datastore__data__dataset1]
  path = /datastore/data/dataset1
  read only = no
.
.
.

並且似乎具有所有 ACL 的先決條件……

[root@myserver ~]# smbd -V
Version 4.9.1
[root@myserver ~]# smbd -b | grep HAVE_LIBACL
HAVE_LIBACL
[root@myserver ~]# cat /etc/samba/smb.conf | grep "vfs objects"
vfs objects = acl_xattr
[root@myserver ~]# cat /etc/samba/smb.conf | grep "map acl inherit"
map acl inherit = Yes

---

更新：

今天再次嘗試掛載，突然開始工作（可以根據共享的NTFS/安全權限訪問那些以前無法訪問的文件夾和文件），IDK為什麼。我會注意到，在之前的測試中，我無法斷開共享，現在只是我第二次嘗試（因此我懷疑再次斷開連接並重新連接可能有所幫助（agian，IDK 為什麼如果這讓任何人有預感 LMK ））。

更糟糕的是，我無法追溯查看 samba 在拒絕我時如何處理對該特定文件夾的訪問請求，因為該/var/log/samba/<myclientIP>.log文件僅包含從今天開始的日誌（我目前沒有遇到問題）。

將繼續監控，但如果這讓任何人對可能發生的事情有任何進一步的預感，請執行 LMK。

不完全針對目前編寫的這個確切問題（更新部分中的“解決方案”仍然是我對此的最佳答案），但對其他使用者有類似的問題，答案結果是該使用者的 AD 配置文件的 UNIX UID 屬性已設置在低於idmapsamba/etc/samba/smb.conf文件範圍的數字處（如下所示：https ://wiki.samba.org/index.php/Idmap_config_ad ）。將使用者在其 AD 配置文件中的 UNIX UID 更改為在該範圍內解決了該問題。

引用自：https://serverfault.com/questions/1055980