Bug 10578 - Previous Versions fails to display when user is a member of a set of groups
Summary: Previous Versions fails to display when user is a member of a set of groups
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.1.6
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2014-04-30 04:05 UTC by Kirin van der Veer
Modified: 2014-07-21 06:34 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Kirin van der Veer 2014-04-30 04:05:20 UTC
When a user is a member of a particular set of groups they do not see any previous versions.
If you remove the user from any one of the groups it works.

For example:
user1 is member of (adam, dragon, piproducts, Domain Admins, public, flinders, mgmt, pistaff)
if you remove the user from adam it will work.
OR if you put the user back into the adam group and remove them from flinders then it will also work.
BUT if they are a member of all of the groups then Previous Versions will fail.

In case it helps, I have attached sanitised ldapsearch dumps of the groups that cause this to occur.

To be clear, I could add a user to 50 groups and have no problem. As long as they do not have the FULL set of the problem groups.

I have generated two level 10 logs of the same user attempting to open the previous versions tab from a Win7 Pro client. One success and one failure.
I have not attached these logs because it would be tedious (and probably unproductive) to sanitize them.
If one of the samba devs would like to see the full level 10 logs please give me an @samba.org email and I will send them through.
For the convenience of the devs I have endeavoured to make these logs quite "clean", they only contain traffic for a single IP and no actions were performed by the client except the attempt at opening the previous versions tab.

I had hoped that because this is an easily reproducable issue that I might be able to diagnose where the fault lay, but level 10 logs are just too verbose.

We are currently running 4.1.6-Debian from Wheezy backports, however this issue was also evident under a custom compile of 4.0.9.

We are using shadow_copy2 pointed to an NFS share, however I don't think that's relevant, since it works reliably for users that are not members of the affected groups.
Comment 1 Andrew Bartlett 2014-05-06 23:36:55 UTC
Almost certainly NFS and 16 group limit.  Are you using real authentication against the NFS backend, or the auth=sys stuff?
Comment 2 Kirin van der Veer 2014-05-07 03:16:49 UTC
Unfortunately the NAS that we are pushing backups to does not support modern NFS authentication.
I'll re-implement via iSCSI and hopefully that will fix the problem.

Would it be possible for samba to throw warnings in the logs if it detects a configuration that attempts to access files over AUTH_SYS NFS?
I think that 16 is a relativity small limit for most organisations.
Comment 3 Jeremy Allison 2014-05-07 20:31:01 UTC
Trouble is Samba has no way of knowing that we're accessing files over NFS. We just make POSIX calls an expect them to work. I don't see how we can do what you want here.

Can you close this out once you've confirmed it's the 16 group AUTH_SYS limit ?


Comment 4 Kirin van der Veer 2014-05-18 10:32:58 UTC
Yep, it will take me a week or two to get everything switched over though. (Lots of data to transfer).
Comment 5 Kirin van der Veer 2014-07-21 06:34:09 UTC
Confirm, iSCSI works fine. It was the NFS auth=sys limit.