Hi all,
Here is the smb.conf used on my test files server.
_________________________________________________________________________
[global]
workgroup = AD
realm = AD.DOMAIN
netbios name = SMBFS20
security = ads
client ldap sasl wrapping = seal
ldap server require strong auth = allow_sasl_over_tls
client use spnego = yes
client ntlmv2 auth = yes
client ipc signing = mandatory
client ipc min protocol = SMB2_10
server signing = mandatory
kerberos method = secrets and keytab
dedicated keytab file = /etc/smbfs20.keytab
disable spoolss = yes
load printers = no
log file = /var/log/samba/%m.log
log level = 1
# Set to NO as we use NTFS
acl_xattr:ignore system acls = yes
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
inherit permissions = yes
# Important: The ranges of the default (*) idmap config
# and the domain(s) must not overlap!
# Default idmap config used for BUILTIN and local accounts/groups
idmap config *:backend = tdb
idmap config *:range = 2-9
# idmap config for domain AD
idmap config AD:backend = ad
idmap config AD:schema_mode = rfc2307
idmap config AD:range = 2000-99999999999
# Use settings from AD for login shell and home directory
winbind nss info = rfc2307
allow trusted domains = yes
template shell = /bin/false
winbind refresh tickets = yes
winbind use default domain = true
winbind offline logon = false
# to be removed in PROD for perofrmance reasons
winbind enum users = yes
winbind enum groups = yes
log level = 1 passdb:5 winbind:5 auth:6
syslog = 9
syslog only = yes
#============================ Share Definitions
=============================[PTA_test]
path = /srv/PTA_test
writable = yes
_________________________________________________________________________
Using https://wiki.samba.org/index.php/Shares_with_Windows_ACLs, we would
like to create a share with Windows (extended) ACLs.
As we are using "acl_xattr:ignore system acls = yes" I initially
thought
that only system rights (UGO, no ACL) are taken in account by samba to
check if it can write.
According to that forcing 777 on the share didn't same a so bad idea:
everybody can do anything but before accessing the folder itself (and UNIX
rights) Samba is there to verify who can act on these files according to
Windows ACLs.
But with this smb.conf, this share in 777, "Domain users" set in full
control on the share level and read and execute on security level, my
domain users are able to create directories.
Once I change this 777 unix mode into 770 my "Domain users" only users
lost
access to the share.
Obviously we are missing something, someone has a lead to help us?
Hai mathias, How did you change :> Once I change this 777 unix mode into 770 my "Domain users" only users lost access to the share.Im thinking.. Or bug : https://bugzilla.samba.org/show_bug.cgi?id=12028 ?(fixed already) But you didn't tell you running samba version... ;-) see also : https://lists.samba.org/archive/samba/2016-August/202154.html if it appies to you. ( long thread ) Or you used chmod and with "ignore system acls" on the share, its better that you dont do that. Use setfacl or set the rights from withing windows. I use ingore system acls also, i only set rights from within windows, on the "windows only" shares and with that i mean where i did set the "ignore system acls" on the share. Other shares, i do with setfacl. Greetz, Louis
On Mon, 5 Sep 2016 15:06:58 +0200 mathias dufresne via samba <samba at lists.samba.org> wrote:> Hi all, > > Here is the smb.conf used on my test files server. > _________________________________________________________________________ > [global] > workgroup = AD > realm = AD.DOMAIN > netbios name = SMBFS20 > > security = ads > client ldap sasl wrapping = seal > ldap server require strong auth = allow_sasl_over_tls > client use spnego = yes > client ntlmv2 auth = yes > client ipc signing = mandatory > client ipc min protocol = SMB2_10 > server signing = mandatory > > kerberos method = secrets and keytab > dedicated keytab file = /etc/smbfs20.keytab > > disable spoolss = yes > load printers = no > > log file = /var/log/samba/%m.log > log level = 1 > > # Set to NO as we use NTFS > acl_xattr:ignore system acls = yes > vfs objects = acl_xattr > map acl inherit = yes > store dos attributes = yes > inherit permissions = yes > > # Important: The ranges of the default (*) idmap config > # and the domain(s) must not overlap! > > # Default idmap config used for BUILTIN and local > accounts/groups idmap config *:backend = tdb > idmap config *:range = 2-9 > > # idmap config for domain AD > idmap config AD:backend = ad > idmap config AD:schema_mode = rfc2307 > idmap config AD:range = 2000-99999999999 > > # Use settings from AD for login shell and home directory > winbind nss info = rfc2307 > allow trusted domains = yes > > template shell = /bin/false > winbind refresh tickets = yes > winbind use default domain = true > winbind offline logon = false > > # to be removed in PROD for perofrmance reasons > winbind enum users = yes > winbind enum groups = yes > > log level = 1 passdb:5 winbind:5 auth:6 > syslog = 9 > syslog only = yes > > #============================ Share Definitions > =============================> [PTA_test] > path = /srv/PTA_test > writable = yes > _________________________________________________________________________ > > Using https://wiki.samba.org/index.php/Shares_with_Windows_ACLs, we > would like to create a share with Windows (extended) ACLs. > > As we are using "acl_xattr:ignore system acls = yes" I initially > thought that only system rights (UGO, no ACL) are taken in account by > samba to check if it can write. > According to that forcing 777 on the share didn't same a so bad idea: > everybody can do anything but before accessing the folder itself (and > UNIX rights) Samba is there to verify who can act on these files > according to Windows ACLs. > > But with this smb.conf, this share in 777, "Domain users" set in full > control on the share level and read and execute on security level, my > domain users are able to create directories. > > Once I change this 777 unix mode into 770 my "Domain users" only > users lost access to the share. > > Obviously we are missing something, someone has a lead to help us?There appears to be a problem, see here: https://lists.samba.org/archive/samba-technical/2016-August/115779.html There doesn't seem to be a great problem with your smb.conf, but I am a bit puzzled about one part of it: # Default idmap config used for BUILTIN and local accounts/groups idmap config *:backend = tdb idmap config *:range = 2-9 How do you get all the well-know SIDs into 8 IDs ? and what about the Unix local users & groups that use those IDs ? Rowland
Thank you both : ) Rowland, nice catch! That's a bullshit I kept for... months. I'm not proud. That's now changed to a range equal to 1000-1999. Louis, version is 4.4.5. I hope my issue came from the fact we created users and groups without UID/GID. Since I noticed that I'd gave them all some xID and I'm rebuilding another file server (for colleagues can play too) without my tests interfering with them. I'll read what you send me ;) Thanks again you two ^^ 2016-09-05 16:38 GMT+02:00 Rowland Penny via samba <samba at lists.samba.org>:> On Mon, 5 Sep 2016 15:06:58 +0200 > mathias dufresne via samba <samba at lists.samba.org> wrote: > > > Hi all, > > > > Here is the smb.conf used on my test files server. > > ____________________________________________________________ > _____________ > > [global] > > workgroup = AD > > realm = AD.DOMAIN > > netbios name = SMBFS20 > > > > security = ads > > client ldap sasl wrapping = seal > > ldap server require strong auth = allow_sasl_over_tls > > client use spnego = yes > > client ntlmv2 auth = yes > > client ipc signing = mandatory > > client ipc min protocol = SMB2_10 > > server signing = mandatory > > > > kerberos method = secrets and keytab > > dedicated keytab file = /etc/smbfs20.keytab > > > > disable spoolss = yes > > load printers = no > > > > log file = /var/log/samba/%m.log > > log level = 1 > > > > # Set to NO as we use NTFS > > acl_xattr:ignore system acls = yes > > vfs objects = acl_xattr > > map acl inherit = yes > > store dos attributes = yes > > inherit permissions = yes > > > > # Important: The ranges of the default (*) idmap config > > # and the domain(s) must not overlap! > > > > # Default idmap config used for BUILTIN and local > > accounts/groups idmap config *:backend = tdb > > idmap config *:range = 2-9 > > > > # idmap config for domain AD > > idmap config AD:backend = ad > > idmap config AD:schema_mode = rfc2307 > > idmap config AD:range = 2000-99999999999 > > > > # Use settings from AD for login shell and home directory > > winbind nss info = rfc2307 > > allow trusted domains = yes > > > > template shell = /bin/false > > winbind refresh tickets = yes > > winbind use default domain = true > > winbind offline logon = false > > > > # to be removed in PROD for perofrmance reasons > > winbind enum users = yes > > winbind enum groups = yes > > > > log level = 1 passdb:5 winbind:5 auth:6 > > syslog = 9 > > syslog only = yes > > > > #============================ Share Definitions > > =============================> > [PTA_test] > > path = /srv/PTA_test > > writable = yes > > ____________________________________________________________ > _____________ > > > > Using https://wiki.samba.org/index.php/Shares_with_Windows_ACLs, we > > would like to create a share with Windows (extended) ACLs. > > > > As we are using "acl_xattr:ignore system acls = yes" I initially > > thought that only system rights (UGO, no ACL) are taken in account by > > samba to check if it can write. > > According to that forcing 777 on the share didn't same a so bad idea: > > everybody can do anything but before accessing the folder itself (and > > UNIX rights) Samba is there to verify who can act on these files > > according to Windows ACLs. > > > > But with this smb.conf, this share in 777, "Domain users" set in full > > control on the share level and read and execute on security level, my > > domain users are able to create directories. > > > > Once I change this 777 unix mode into 770 my "Domain users" only > > users lost access to the share. > > > > Obviously we are missing something, someone has a lead to help us? > > There appears to be a problem, see here: > > https://lists.samba.org/archive/samba-technical/2016-August/115779.html > > There doesn't seem to be a great problem with your smb.conf, but I am a > bit puzzled about one part of it: > > # Default idmap config used for BUILTIN and local accounts/groups > idmap config *:backend = tdb > idmap config *:range = 2-9 > > How do you get all the well-know SIDs into 8 IDs ? and what about the > Unix local users & groups that use those IDs ? > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >