Bug 2082 - Samba 3.0.8 on Solaris missing AD group with getent
Summary: Samba 3.0.8 on Solaris missing AD group with getent
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: winbind (show other bugs)
Version: 3.0.8
Hardware: Sparc Solaris
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-11-23 16:53 UTC by Mark Clarkson
Modified: 2005-08-24 10:22 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mark Clarkson 2004-11-23 16:53:40 UTC
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:

            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
            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 =
            use spnego = Yes

            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 =
            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

  $ 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

  $ wbinfo -G 50308

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
  $ getent group | awk -F: '{print $1}'|wc -l

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.
Comment 1 Mark Clarkson 2004-11-23 17:20:49 UTC
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 =
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.
Comment 2 Mark Clarkson 2004-11-23 17:26:48 UTC
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

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
Comment 3 Stephen Rondeau 2005-01-19 08:53:30 UTC
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)
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-02-08 05:58:43 UTC
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.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:22:15 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.