We are currently running Samba 3.2 on our Sun Solaris servers, as this version is reaching end of life and we are planning to move to Windows 7, I have been investigating upgrading to release 3.4. We have an issue that causes Samba to fail if a user belongs to move than 16 groups. This I understand is caused by the Sun Solaris imposing a limit of 16 to the ngroups_max kernel parameter. This value cannot be increased without breaking other elements of the OS. I have raised this issue with Sun, but don't expect much to change in the short term. Are there any plans to provide a tweak that could allow Sun system users to circumvent this issue, at least in the short term?.
Sorry, there is no way for Samba to work around this issue. SUN decided that no single user can be in more than 16 groups. It is a decision they force upon their customers willfully. SUN is particularly hostile against Samba in this respect. They have fixed the issue for their in-kernel CIFS server, but they explicitly and in a very calculating manner refuse to supply the corresponding functionality to competing implementations in userspace like Samba. Closing this bug as INVALID, this is really a decision by SUN Microsystems and not a Samba issue. Volker
"This value cannot be increased without breaking other elements of the OS." Can you explain more about this statement ? What other elements break if you use Sun's workaround ? I'm just trying to fully understand this issue as at the CIFS conference last week Sun engineers claimed that Sun's workaround for the 16 group case was an acceptable fix. If this isn't the case for customers in the field then I'd like to push back on Sun's claim. Jeremy.
The only fix I have heard about from Sun was to increase the value of ngroups_max from 16 to 32, however I understand that this stops nfs working on the server and we use this throughout our setup.
Can you test this please ? I doubt that NFS would simply stop working, more likely as the NFSv3 protocol only allows 16 groups, you'd get NFS accesses being restricted to the first 16 groups but Samba would be able to use more. If it really does stop NFS working then I must say I don't appreciate Sun forcing customers to chose between a working NFS or a working third-party CIFS. Of course their own CIFS would keep working but that appears to be a measure to force customers to use the CIFS server tied to Solaris, a throughly anti-competitive move worthy of Microsoft at their worst. Jeremy.
Hi Jeremy, I don't have a test server to try this out on, so I guess I will have to wait for Sun to get back to me regarding the problem. Hopefully they will do something about the situation, as I feel sure there will be many customers affected by this issue, if not now then very soon. Thanks for your comments/help Neil
Please keep me posted on what the official response from Sun is. I know some Sun engineers quite well and will follow up internally if I can. Thanks, Jeremy.
Ok, here's what I've found: http://www.science.uva.nl/pub/solaris/solaris2/Q7.6.html which eventually leads to: http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=3126eb01e11580e19117e55d39e0?bug_id=4088757 Looks like the Solaris hard limit for userspace is 32 groups at the moment. This is fixed in the kernel for Sun's internal cifs server. What I need you you do is to strongly advocate for Sun to open up this internal API to a userspace application like Samba. Jeremy.
Also here: http://blogs.sun.com/peteh/entry/increasing_unix_group_membership_easy So this bug has been extent since 1997 and Sun *STILL* haven't fixed it. Jeremy
Please find the response from SUN regarding this issue below: There will be no fix for this issue in the current release of SPARC Solaris. There is a bodge around using ACL's as suggested in the following link, but that won't work on the scale of things used here: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4088757 However Solaris Nevada will have a fix for this issue, not much help to me at this time!.