On 18/11/15 10:24, mourik jan c heupink wrote:> > > On 18-11-2015 10:59, Rowland Penny wrote: >> OK, I am trying to understand this as well, I take it that the uidNumber >> you add is a unique number that is inside the range you have set in >> smb.conf, but what about the gidNumber? do you set it to '515' and is >> this also inside the range? > Yep. gidNumber 515, both inside the range yes. (range starts at 500) > >> Who owns the share on the disk and what are the permissions, also what >> is the share in smb.conf. > >> [ninite] >> guest ok = no >> comment = Ninite Software Updater >> path = /srv/ninite >> read only = No >> writable = yes >> valid users = @"Domain Admins", @"Domain Computers" >> create mask = 0775 >> directory mask = 0775 > > Permissions on disk: >> drwxrwxr-x 5 root Domain Admins 4096 Jul 8 14:10 ninite > > MJ >OK, I think I understand this, Mourik is setting this on the share: valid users = @"Domain Admins", @"Domain Computers" This means that only members of the 'Domain Admins' or 'Domain Computers' groups can connect to the share, whilst Louis has this showing in his ACLs from getfacl: Creator owner special. Only folders and files on underlying folders. Creator group special. Only folders and files on underlying folders. Verified users read+exec This folder underlying folders and files Domain Admins Full This folder underlying folders and files Domain users read+exec This folder underlying folders and files Domain computers read+exec This folder underlying folders and files Which gives (amongst others) 'Domain Admins' full control and 'Domain Computer' read+exec permissions. With Mourik's way of doing things, 'Domain Computers' must be known to Unix, hence the required gidNumber Louis's way will probably rely on winbind mapping 'Domain Computers' Rowland
> On 18 Nov 2015, at 13:24, Rowland Penny <rowlandpenny241155 at gmail.com> wrote: > >> On 18/11/15 10:24, mourik jan c heupink wrote: >> >> >>> On 18-11-2015 10:59, Rowland Penny wrote: >>> OK, I am trying to understand this as well, I take it that the uidNumber >>> you add is a unique number that is inside the range you have set in >>> smb.conf, but what about the gidNumber? do you set it to '515' and is >>> this also inside the range? >> Yep. gidNumber 515, both inside the range yes. (range starts at 500) >> >>> Who owns the share on the disk and what are the permissions, also what >>> is the share in smb.conf. >> >>> [ninite] >>> guest ok = no >>> comment = Ninite Software Updater >>> path = /srv/ninite >>> read only = No >>> writable = yes >>> valid users = @"Domain Admins", @"Domain Computers" >>> create mask = 0775 >>> directory mask = 0775 >> >> Permissions on disk: >>> drwxrwxr-x 5 root Domain Admins 4096 Jul 8 14:10 ninite >> >> MJ > > OK, I think I understand this, Mourik is setting this on the share: > > valid users = @"Domain Admins", @"Domain Computers" > > This means that only members of the 'Domain Admins' or 'Domain Computers' groups can connect to the share, whilst Louis has this showing in his ACLs from getfacl: > > Creator owner special. Only folders and files on underlying folders. > Creator group special. Only folders and files on underlying folders. > Verified users read+exec This folder underlying folders and files > Domain Admins Full This folder underlying folders and files > Domain users read+exec This folder underlying folders and files > Domain computers read+exec This folder underlying folders and files > > Which gives (amongst others) 'Domain Admins' full control and 'Domain Computer' read+exec permissions. > > With Mourik's way of doing things, 'Domain Computers' must be known to Unix, hence the required gidNumber > > Louis's way will probably rely on winbind mapping 'Domain Computers' > > Rowland >Hi all, A bit difficult to follow since I'm travelling. But, no, I do use Windows to manage the shares. Specifically, (I think) I am doing what is described in the wiki: I give the group full access to the shared folder, and then set the group to "domain admin" (which has a uid and is thus recognized on my nix system). Subsequently, I am managing rights to the files and folders within the shares using Windows ACL. Isn't that the correct process? Just that I also should add the line Louis suggested to each shared folder definition? Viktor
On 18-11-2015 12:24, Rowland Penny wrote:> OK, I think I understand this, Mourik is setting this on the share: > > valid users = @"Domain Admins", @"Domain Computers" > > This means that only members of the 'Domain Admins' or 'Domain > Computers' groups can connect to the share, whilst Louis has this > showing in his ACLs from getfacl: > > Creator owner special. Only folders and files on underlying folders. > Creator group special. Only folders and files on underlying folders. > Verified users read+exec This folder underlying folders and files > Domain Admins Full This folder underlying folders and files > Domain users read+exec This folder underlying folders and files > Domain computers read+exec This folder underlying folders and files > > Which gives (amongst others) 'Domain Admins' full control and 'Domain > Computer' read+exec permissions. > > With Mourik's way of doing things, 'Domain Computers' must be known to > Unix, hence the required gidNumber > > Louis's way will probably rely on winbind mapping 'Domain Computers' > > Rowland >Nice analysis, yes. :-)
On 18.11.2015 12:24, Rowland Penny wrote:> On 18/11/15 10:24, mourik jan c heupink wrote: >> >> >> On 18-11-2015 10:59, Rowland Penny wrote: >>> OK, I am trying to understand this as well, I take it that the >>> uidNumber >>> you add is a unique number that is inside the range you have set in >>> smb.conf, but what about the gidNumber? do you set it to '515' and is >>> this also inside the range? >> Yep. gidNumber 515, both inside the range yes. (range starts at 500) >> >>> Who owns the share on the disk and what are the permissions, also what >>> is the share in smb.conf. >> >>> [ninite] >>> guest ok = no >>> comment = Ninite Software Updater >>> path = /srv/ninite >>> read only = No >>> writable = yes >>> valid users = @"Domain Admins", @"Domain Computers" >>> create mask = 0775 >>> directory mask = 0775 >> >> Permissions on disk: >>> drwxrwxr-x 5 root Domain Admins 4096 Jul 8 14:10 ninite >> >> MJ >> > > OK, I think I understand this, Mourik is setting this on the share: > > valid users = @"Domain Admins", @"Domain Computers" > > This means that only members of the 'Domain Admins' or 'Domain > Computers' groups can connect to the share, whilst Louis has this > showing in his ACLs from getfacl: > > Creator owner special. Only folders and files on underlying > folders. > Creator group special. Only folders and files on underlying > folders. > Verified users read+exec This folder underlying folders and files > Domain Admins Full This folder underlying folders and files > Domain users read+exec This folder underlying folders and files > Domain computers read+exec This folder underlying folders and > files > > Which gives (amongst others) 'Domain Admins' full control and 'Domain > Computer' read+exec permissions. > > With Mourik's way of doing things, 'Domain Computers' must be known to > Unix, hence the required gidNumber > > Louis's way will probably rely on winbind mapping 'Domain Computers' > > Rowland >Hi all, So I had some time today to study the whole thread once more and see if I can finally get it to work. The good news is, yes, it works now. But I don't yet understand what the problem initially was, and I also would like to know if the way I got it to work is really optimal. At first, I tried Louis' suggestion. In contrast to MJ, I did not change my share permissions, they just contained "everybody:full control" from the start. All I did, though, when I realized I had an issue with the access on a computer level, I added the "domain computers" group to the windows ACL of the Samba share. Since getent group wouldn't reveal domain computers on the linux station, of course, since I have AD type ID mapping, I added a uid to the group "domain computers". I still wouldn't work, so I tried Louis' advice and added the line acl_xattr:ignore system acls = yes to the share but that didn't solve the issue, either, same error messages. But once, I set a uid and gid for the PC as MJ suggested, it finally worked. - Is it really necessary to specifically give access to "domain computers" on a share in order to be accessed in computer mode? Would this work in the same way in a Windows AD? - At what level does it have to be set? Is it necessary at share level or would folder level have been sufficient? Would this have any influence on the outcome? - Why did it work for Louis without setting uid/gid and I had to? After all, my configuration is closer to Louis' than to MJ's. I didn't quite understand Rowland's remark about winbindd doing the job for Louis. Anyway, for now I'm just glad it works. Thank you all for participating in the search for a solution. Viktor
On 19/11/15 10:37, Viktor Trojanovic wrote:> > > On 18.11.2015 12:24, Rowland Penny wrote: >> On 18/11/15 10:24, mourik jan c heupink wrote: >>> >>> >>> On 18-11-2015 10:59, Rowland Penny wrote: >>>> OK, I am trying to understand this as well, I take it that the >>>> uidNumber >>>> you add is a unique number that is inside the range you have set in >>>> smb.conf, but what about the gidNumber? do you set it to '515' and is >>>> this also inside the range? >>> Yep. gidNumber 515, both inside the range yes. (range starts at 500) >>> >>>> Who owns the share on the disk and what are the permissions, also what >>>> is the share in smb.conf. >>> >>>> [ninite] >>>> guest ok = no >>>> comment = Ninite Software Updater >>>> path = /srv/ninite >>>> read only = No >>>> writable = yes >>>> valid users = @"Domain Admins", @"Domain Computers" >>>> create mask = 0775 >>>> directory mask = 0775 >>> >>> Permissions on disk: >>>> drwxrwxr-x 5 root Domain Admins 4096 Jul 8 14:10 ninite >>> >>> MJ >>> >> >> OK, I think I understand this, Mourik is setting this on the share: >> >> valid users = @"Domain Admins", @"Domain Computers" >> >> This means that only members of the 'Domain Admins' or 'Domain >> Computers' groups can connect to the share, whilst Louis has this >> showing in his ACLs from getfacl: >> >> Creator owner special. Only folders and files on underlying >> folders. >> Creator group special. Only folders and files on underlying >> folders. >> Verified users read+exec This folder underlying folders and files >> Domain Admins Full This folder underlying folders and files >> Domain users read+exec This folder underlying folders and files >> Domain computers read+exec This folder underlying folders and >> files >> >> Which gives (amongst others) 'Domain Admins' full control and 'Domain >> Computer' read+exec permissions. >> >> With Mourik's way of doing things, 'Domain Computers' must be known >> to Unix, hence the required gidNumber >> >> Louis's way will probably rely on winbind mapping 'Domain Computers' >> >> Rowland >> > > Hi all, > > So I had some time today to study the whole thread once more and see > if I can finally get it to work. The good news is, yes, it works now. > But I don't yet understand what the problem initially was, and I also > would like to know if the way I got it to work is really optimal. > > At first, I tried Louis' suggestion. In contrast to MJ, I did not > change my share permissions, they just contained "everybody:full > control" from the start. All I did, though, when I realized I had an > issue with the access on a computer level, I added the "domain > computers" group to the windows ACL of the Samba share. Since getent > group wouldn't reveal domain computers on the linux station, of > course, since I have AD type ID mapping, I added a uid to the group > "domain computers". > > I still wouldn't work, so I tried Louis' advice and added the line > acl_xattr:ignore system acls = yes to the share but that didn't solve > the issue, either, same error messages. > > But once, I set a uid and gid for the PC as MJ suggested, it finally > worked. > > - Is it really necessary to specifically give access to "domain > computers" on a share in order to be accessed in computer mode? Would > this work in the same way in a Windows AD? > - At what level does it have to be set? Is it necessary at share level > or would folder level have been sufficient? Would this have any > influence on the outcome? > - Why did it work for Louis without setting uid/gid and I had to? > After all, my configuration is closer to Louis' than to MJ's. I didn't > quite understand Rowland's remark about winbindd doing the job for Louis. >Louis probably has something like this in smb.conf idmap config *:backend = tdb idmap config *:range = 2000-9999 idmap config SAMDOM:backend = ad idmap config SAMDOM:schema_mode = rfc2307 idmap config SAMDOM:range = 10000-99999 If a user or group has a uidNumber or gidNumber and is part of the 'SAMDOM' domain and the id number is inside '10000-99999, then it is treated as part of the domain, any numbers outside the range are ignored. If a user or group doesn't have a uidNumber or gidNumber and isn't part of the 'SAMDOM' domain i.e. BUILTIN\Administrators , then winbind maps them to a number inside the range '2000-9999', but because these numbers are less than '10000' they do not show with getent. If you create a file as a member of 'Domain Admins' on a domain member share (when the group doesn't have a gidNumber) and then check the ownership of said file, you will find that the group is shown as a number 2xxx Rowland