We just upgraded to 4.3.9 (from 4.1.x) and are experiencing a few issues/differences around permissions on files written from Windows clients authenticated from winbind/AD. One specific issue that we have is directories with permissions like: drwxrws---+ 9 myapp 9997 2048 May 16 17:38 . It's owned by user "myapp" and GID 9997 and as you can see we have the SGID bit set on this directory. Prior to the upgrade, new files or directories created inside this directory would be owned by the 9997 GID, which is required for a particular workflow that involves uploading files from windows clients and then processing them with batch jobs on a Linux cluster. After the upgrade, the behavior is broken - now the GID ownership goes to the default group membership coming from winbind/AD. Group 9997 does not exist in AD, and never has, which I suspect is why this was originally setup this way. I have tried to override this at the share level with: create mask = 2777 force create mode = 2660 directory mask = 2777 force directory mode = 2770 but that seems to have absolutely no effect. I'm a bit surprised at that, since I found several references indicating that this has worked in the past to solve exactly the problem I have. I also tried "force group = 9997" but then I can't even map the share (not sure why - is that because the group is not in AD?). Any idea what is going on here or how to troubleshoot? Thanks Jarrod Smith
On 18/05/16 19:44, Smith, Jarrod A wrote:> We just upgraded to 4.3.9 (from 4.1.x) and are experiencing a few issues/differences around permissions on files written from Windows clients authenticated from winbind/AD. One specific issue that we have is directories with permissions like: > > drwxrws---+ 9 myapp 9997 2048 May 16 17:38 .if you notice, there is a '+' at the end of 'drwxrws---', this means there are ACLs set, try running 'getfacl /path/to/the/directory'> > It's owned by user "myapp" and GID 9997 and as you can see we have the SGID bit set on this directory. Prior to the upgrade, new files or directories created inside this directory would be owned by the 9997 GID, which is required for a particular workflow that involves uploading files from windows clients and then processing them with batch jobs on a Linux cluster. After the upgrade, the behavior is broken - now the GID ownership goes to the default group membership coming from winbind/AD. Group 9997 does not exist in AD, and never has, which I suspect is why this was originally setup this way.What is '9997', where is it created ? does it exist in /etc/group ? Does 'getent group 9997' produce any output ? Rowland> > I have tried to override this at the share level with: > > create mask = 2777 > force create mode = 2660 > directory mask = 2777 > force directory mode = 2770 > > but that seems to have absolutely no effect. I'm a bit surprised at that, since I found several references indicating that this has worked in the past to solve exactly the problem I have. > > I also tried "force group = 9997" but then I can't even map the share (not sure why - is that because the group is not in AD?). > > Any idea what is going on here or how to troubleshoot? > > Thanks > > Jarrod Smith
> On May 18, 2016, at 2:38 PM, Rowland penny <rpenny at samba.org> wrote: > > On 18/05/16 19:44, Smith, Jarrod A wrote: >> We just upgraded to 4.3.9 (from 4.1.x) and are experiencing a few issues/differences around permissions on files written from Windows clients authenticated from winbind/AD. One specific issue that we have is directories with permissions like: >> >> drwxrws---+ 9 myapp 9997 2048 May 16 17:38 . > > if you notice, there is a '+' at the end of 'drwxrws---', this means there are ACLs set, try running 'getfacl /path/to/the/directory'Yes, we have acl_xattr enabled on this share. There is a POSIX ACL on this directory and we added a default ACL that gives group 9997 rwx permissions and that part works (does get inherited on new objects created here). But the user still wants group ownership on the file to be 9997, and I would like to understand what changed and why.>> It's owned by user "myapp" and GID 9997 and as you can see we have the SGID bit set on this directory. Prior to the upgrade, new files or directories created inside this directory would be owned by the 9997 GID, which is required for a particular workflow that involves uploading files from windows clients and then processing them with batch jobs on a Linux cluster. After the upgrade, the behavior is broken - now the GID ownership goes to the default group membership coming from winbind/AD. Group 9997 does not exist in AD, and never has, which I suspect is why this was originally setup this way. > > What is '9997', where is it created ? does it exist in /etc/group ? > > Does 'getent group 9997' produce any output ? >This group doesn't exist on the Samba servers, which is why my "ls -l ." output in the first message did not resolve it. This group is defined in /etc/group on the Linux cluster that mounts this underlying filesystem via GPFS. As an aside, we are also getting complaints from other users that sound similar to an issue reported to the list on May 5 that secondary groups are not obeyed in 4.3.9. We have some shares defined to limit access to a particular (secondary) AD group and users are telling us that after the upgrade they can't map them any more. Not sure if that is related to the issue I'm reporting here (maybe not) but It seems that groups are overall behaving differently for us on 4.3.9 vs. our previous 4.1.6. Thanks Jarrod>> >> I have tried to override this at the share level with: >> >> create mask = 2777 >> force create mode = 2660 >> directory mask = 2777 >> force directory mode = 2770 >> >> but that seems to have absolutely no effect. I'm a bit surprised at that, since I found several references indicating that this has worked in the past to solve exactly the problem I have. >> >> I also tried "force group = 9997" but then I can't even map the share (not sure why - is that because the group is not in AD?). >> >> Any idea what is going on here or how to troubleshoot? >> >> Thanks >> >> Jarrod Smith