[Samba] Group permission problems with winbind & NFS

Don Meyer dlmeyer at uiuc.edu
Tue May 1 04:35:32 GMT 2007

I am wondering whether anyone might also be seeing the problems I am 
currently encountering -- and maybe even someone knows of a solution 
that I cannot seem to find.

First, to whet your appetite, the problem:

I have an otherwise functional samba+winbind system, that I am 
primarily using winbind to instantiate users & groups from a 
Win2K3-based ADS, to allow clients ssh/scp/sftp access to website 
file storage.

Winbind appears to be working reasonably correctly - I have 3.0.24 
installed on this RHEL4 system.  I have successfully tweaked the 
pam.d/sshd config to restrict ssh login access to members of a 
particular group.  Once on the system, home directories are properly 
created if necessary, and they can successfully modify/add files in 
their home directory, in /tmp/, as necessary.   As long as it is on 
local file storage...

This system NFS mounts the remote file storage resource on a backend 
RHEL4 server.   The public facing web frontends also mount these same 
resources.   Here is where things get hinky -- some users can write 
to the directories on the NFS mount, and some cannot.   If the 
directory in question is owned by the user, then no problems 
writing.   If not, but the directory's owning group contains the user 
as a member, then only sometimes can the user add/change/remove files 
in the directory.

The first thing I would think to check here are the permissions -- 
directory permissions in my testcase are 2775, file perms are 0664 -- 
shouldn't be any problems there, right?

The most interesting behavior is that some groups work and some do 
not.   If I set the group for a directory to "Domain Users", then all 
can successfully write to it.  I can use "Domain Admins" also, and 
the domain admin users can write to it.  Set it to another group that 
we created mid-year last year, and also those users have no 
problems.   However, set the test directory to a group that was 
created last week, and permission is denied.  The same denial if I 
use a group that was created over a month ago.

Now, I have created directories on the local filesystem, set them to 
each of these groups and successfully  written to them while su'd to 
the same user account that cannot write under some of the groups on 
the NFS mounted filesystem.

At first I thought it was groups with underscores in the group name - 
a recently adopted convention on our AD, but a recently created test 
group using hyphens instead of underscores exhibits the same failure 
state.   I have eliminated ACLs & xattrs from the equation, as the 
same behavior exists on mounts that are not mounted with those 
options and whose underlying filesystems don't have the options either.

I also thought it might have something to do with nested groups, but 
even simple groups with only users as members exhibit the failure 
over NFS.   I have had the thought that it could be the length of 
some of the groupnames, as some of them are pretty long:  the longest 
is 64 bytes.  The one I did most testing with is only 10 bytes long, however.

I have even tried groups created in the domain root versus groups 
created under various OUs -- all recent groups exhibit the same 
failure state.   The problem appears to apply to groups created after 
a certain point, but that point is still to be narrowed down.   (I'm 
currently running with 737 groups and 3797 users, according to wbinfo -g & -u.)

Details & configs:

We have a somewhat unusual domain structure:
   1) an empty root domain, with our main domain in the same forest
   2) a related single domain/forest with a two-way forest-level trust
   3) an old NT4 domain with two-way trust (unsure of forest-level or 

(I limited my testing to users and groups from the main domain, to 
try to reduce externalities.)

smb.conf:     (output from testparm)
         workgroup = ACES
         netbios name = ACES-SITE-MAINT
         server string = %L (Samba v%v)
         security = ADS
         obey pam restrictions = Yes
         password server = college.acesnet.uiuc.edu
         username map = /etc/samba/smbusers
         client NTLMv2 auth = Yes
         client lanman auth = No
         client plaintext auth = No
         log file = /var/log/samba/%m.log
         max log size = 0
         name resolve order = host lmhosts wins bcast
         deadtime = 15
         socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
         local master = No
         dns proxy = No
         wins server = 128.174.x.x, 128.174.x.x
         idmap uid = 10000-100000000
         idmap gid = 10000-100000000
         template shell = /bin/bash
         winbind cache time = 10
         winbind enum users = Yes
         winbind enum groups = Yes
         winbind use default domain = Yes
         create mask = 0664
         directory mask = 02775
         inherit permissions = Yes
         inherit acls = Yes
         case sensitive = No

  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

  ticket_lifetime = 24000
  default_realm = COLLEGE.ACESNET.UIUC.EDU
  dns_lookup_realm = false
  dns_lookup_kdc = false

   kdc = college.acesnet.uiuc.edu:88
   admin_server = college.acesnet.uiuc.edu:749
   default_domain = college.acesnet.uiuc.edu

   kdc = acesnet.uiuc.edu:88
   admin_server = acesnet.uiuc.edu:749
   default_domain = acesnet.uiuc.edu

   kdc = ad.uiuc.edu
   admin_server = ad.uiuc.edu
   default_domain = ad.uiuc.edu

   kdc = extension.uiuc.edu
   admin_server = extension.uiuc.edu
   default_domain = extension.uiuc.edu

  .college.acesnet.uiuc.edu = COLLEGE.ACESNET.UIUC.EDU
  college.acesnet.uiuc.edu = COLLEGE.ACESNET.UIUC.EDU
  .acesnet.uiuc.edu = ACESNET.UIUC.EDU
  acesnet.uiuc.edu = ACESNET.UIUC.EDU
  .extension.uiuc.edu = EXTENSION.UIUC.EDU

  profile = /var/kerberos/krb5kdc/kdc.conf

  pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false

passwd:     files winbind
shadow:     files winbind
group:      files winbind

Any insights that anyone can offer will be extremely welcome.

(Frankly, even just hearing that someone else is seeing a similar 
problem would be welcome at this point... ;-)


Don Meyer                                           <dlmeyer at uiuc.edu>
Network Manager, ACES Academic Computing Facility
Technical System Manager, ACES TeleNet System
UIUC College of ACES, Information Technology and Communication Services

   "They that can give up essential liberty to obtain a little 
temporary safety,
         deserve neither liberty or safety."     -- Benjamin Franklin, 1759 

More information about the samba mailing list