Solaris 9 (patch 112960-10 applied) Samba 3.0.8 (configure --with-ads --with-pam --with-winbind) MIT Kerberos 1.3.5 (configure --enable-dns --enable-dns-for-kdc --enable-dns-for-realm --without-tcl) I am using Samba to share Unix files to our Windows users via a Samba share, security = ads. All the shares work just fine. Here is the relevant section of my smb.conf file: [global] workgroup = FFFC realm = FFFC.COM server string = Fileshare security = ads password server = * log level = 2 log file = /var/log/samba/%m.log min protocol = NT1 time server = Yes change notify timeout = 300 deadtime = 7 socket options = TCP_NODELAY SO_RCVBUF=8192 IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192 load printers = No os level = 99 domain master = No ldap ssl = no idmap uid = 50000-59999 idmap gid = 50000-59999 winbind separator = + winbind cache time = 10 winbind nested groups = Yes hide unreadable = Yes delete veto files = Yes inherit acls = Yes inherit permissions = Yes wins server = 10.1.240.90 10.1.240.91 use spnego = Yes [exlist$] comment = Test share path = /export/smbfiles/exlist create mask = 0777 directory mask = 0777 security mask = 0777 force group = root force user = root writeable = Yes read only = No valid users = FFFC+Citrix_Base write list = FFFC+Citrix_Base veto files = /*.?pg/*.avi/favicon.ico/robots.txt/.htaccess/*.wm*/.rhosts/*.rm/*.mp?/*.asf /*.wav/*.?peg/*.midi/*.aif*/*.au/*.as?/*.wpl/ hide files = /Thumbs.db/.*/ dos filetimes = Yes The problem that I am having is that some groups can not be accessed by a `getent group` command. I can see the group with wbinfo: $ wbinfo -g | grep FFFC+Citrix_Base FFFC+Citrix_Base $ wbinfo -n FFFC+Citrix_Base S-1-5-21-393102617-441343358-1233803906-9715 Domain Group (2) $ wbinfo -Y S-1-5-21-393102617-441343358-1233803906-9715 50308 $ wbinfo -G 50308 S-1-5-21-393102617-441343358-1233803906-9715 As you can clearly see, FFFC+Citric_Base is a valid Active Directory group. But when I use `getent`, I get different numbers of groups: $ wbinfo -g | wc -l 327 $ getent group | awk -F: '{print $1}'|wc -l 315 Also, when I try to view the group with a `getent` command, winbindd seems to hang. $ getent group FFFC+Citrix_Base I left it for a weekend and it still did not return the group. The group FFFC+Citrix_Base contains a lot of users (more than 500 for sure, possibly more than 1000). This is preventing me from using FFFC+Citrix_Base as a way to control access to this share.
Just ran winbindd -d10 -i and found this at the end of the query. Don't know if it will help though: num_mem = 1235, len = 16630, mem = FFFC+SMazziotti,FFFC+JHandel,FFFC+FShaw,FFFC+LBrinza,FFFC+RPalencia,FFFC+HXaymountry,FFFC+JBelcher,FFFC+JLewis,FFFC+SBrooke,FFFC+KCrutcher,FFFC+ACvetnich,FFFC+JPayne,FFFC+DABrown,FFFC+SMcmurtrey,FFFC+kflake,FFFC+TJewell,FFFC+ANicotra,FFFC+STaylor,FFFC+JHealy,FFFC+BRobbins,FFFC+LHarling,FFFC+CMercado,FFFC+DRodriguez,FFFC+DKay,FFFC+HTaylor,FFFC+LSalmiery,FFFC+JLopez,FFFC+BrMcManus,FFFC+STurriff,FFFC+YGalan,FFFC+JQuinones,FFFC+CDumas,FFFC+THarrison,FFFC+ASharpe,FFFC+KWalsh,FFFC+MRubman,FFFC+JuKaplan,FFFC+LFerraro,FFFC+WBirdsell,FFFC+JHyde,FFFC+NAcker,FFFC+JMoneymaker,FFFC+KIgnagni,FFFC+JWuchte,FFFC+CZith,FFFC+JPoston,FFFC+JWhelan,FFFC+JWeather,FFFC+EBoyd,FFFC+Cmartinez,FFFC+JTuccio,FFFC+ESaxton,FFFC+CPatterson,FFFC+APhan,FFFC+KJenkins,FFFC+SKline,FFFC+JReece,FFFC+VFizer,FFFC+TMayon,FFFC+MMays,FFFC+TLe,FFFC+AMorgan,FFFC+CSpeer,FFFC+JRiechert,FFFC+TNelson,FFFC+RHayes,FFFC+PhCunningham,FFFC+RMills,FFFC+PStLouis,FFFC+MTizzano,FFFC+KKahl,FFFC+DGabriele,FFFC+EEppes,FFFC+EsRobles,FFf +> ill_grent_mem returning 1 client_write: wrote 1300 bytes. client_write: need to write 16630 extra data bytes. client_write: wrote 16630 bytes. client_write: client_write: complete response written. client_read: read 0 bytes. Need 1824 more for a full request. read failed on sock 18, pid 1611: EOF Looks like the group size is 1235 members.
Actually, scratch that. I got the 6 lines from the previous post only because I changed the nsswitch.conf file to read: group: files winbind [SUCCESS=return NOTFOUND=continue UNAVAIL=continue TRY AGAIN=5] so that it would not hang forever. Once I changed it back to TRYAGAIN=forever, the last line I get from the winbindd output is: ill_grent_mem returning 1
My experience with Samba 2.2.8a on Solaris, as well as someone else's with 3.0.10 compiled on Solaris, is that winbind has a buffering problem with group members whose combined length exceeds 4096 bytes. I discovered this while trying to get winbind to work with my 2.2.8a version on Solaris (yes, I know I need to update): when I had 625 members in my "Domain Users" group, whose average user name length was 6.6 characters, winbind would fail (using "id username" would hang, or "ls -l" would hang on a directory where the group "Domain Users" should be resolved from the gid -- "ls" worked fine). Doing the math, this puts the total length over 4K bytes. I deleted some old accounts: 26 at first, and everything (id and ls -l) started to work again. Doing the math again, the break-even point for my average user name length would be about 620... I happened to check it at 599. I hope this helps! (srondeau@u.washington.edu)
we've done a lot of work on winbindd for 3.0.11. Please test that release and reopen if the bug still exists. Thanks.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.