The Samba-Bugzilla – Bug 1126
Samba 3.0.2 does not recognized user group permissions
Last modified: 2005-01-24 06:40:19 UTC
Samba 3.0.2 does not work like Samba 2.2.8a in how group permissions work.
Samba 3.0.2 is broken in that it will not recognize multiple unix group
permissions for users, only the first group is recognized. Example:
user cxm21 is in the unixos group on unix but his primary group is dept21:
dept21 root hotline acct m829sec coverage d21os d21mpt rootusr eos unixos
adminjr usaweb esadm esdomadm spltadm
chown dcr21 /tmp/BAD
chgrp unixos /tmp/BAD
chmod 775 /tmp/BAD
cxm21 on windows cannot write to /tmp/BAD directory even though he is a member
of the unixos group and should have write permission. Under Samba 2.2.8a this
Cannot access this file.
Check security privileges over the network drive.
chgrp dept21 /tmp/BAD
now cxm21 on windows can write to /tmp/BAD directory as expected.
This is a serious bug that affects our users. We will need to backout Samba
3.0.2 if this is not fixed soon.
please refer to bug 395 and ensure that this is not
a Solaris bug first. Thanks.
This is not a Solaris only bug. Samba 2.2.8a works fine with the same version
and patch level of Solaris 8 and 9. Only Samba 3.x has this problem. Only
Samba was changed on the systems which caused this problem. We are forced to
backout Samba 3.0.2 on our production systems due to this problem. We are back
to running Samba 2.2.8a which works fine.
Are you using winbindd ? If so, please try the patch
posted in bug 1165. Thanks.
No, we are not using winbindd. We are using NIS for the group file.
In that case I need a level 10 debug log to start
debugging this. If you can't get one (since there server
has moved back to 2.2.8a) I'm kind of stuck here.
Created attachment 439 [details]
Samba 3.0.2 debug 10 output
We experienced exactly the same behavior on an i386-debian but with the same
samba-version .. we also use NIS to resolve groups ( 1 Master , 3 Slaves )..
we experienced ,that samba uses some getshadow-passwd routines to resolve
permissions for groups .. in one case the Master-NIS-Server used one of the
Slaves to nis-auth the request , the Master-NIS tried to use unprivileged
ports to fullfill this request .. and was blocked on the slave due to the
setting "* : * : shadow.byname : port" in the ypserv.conf .. we changed this
to allow the SAMBA-Server (which is also the NIS-Master) to allow these
requests on untrusted ports .. but this is only a workaround for us .. so
finally our Problem was, that the Master tried to contact the slave .. so it
was a NIS-misconfiguration
I'm working on it and will hopefully have a patch by the end of today.
*** This bug has been marked as a duplicate of 1165 ***
I tested with Samba 3.0.3pre1 and the problem still exists. From the release
notes, it looked like this release should have fixed the problem. It does not
for Solaris using NIS (no winbind). Please advise. Thanks.
I'll look back over you logs again. The secondary group
bug fixed in 3.0.3pre1 was related to winbind setups.
*** Bug 1769 has been marked as a duplicate of this bug. ***
I believe I'm affected by this same bug. Tried in both Samba 3.0.8 and 3.0.9.
I have two different problems that seems to be group permission related:
1. I have the following file:
-r--rw---- 1 apache_user developers_group 13285 Dec 9 12:53 index.html
I am a member of developers_group (not my primary group) and I can't edit this
file. If I give apache_user (the file's owner) the write right then I can edit
This only happens when I access the file through Samba, on the server itself
these rights work as I expect, i.e., no need of write right to the owner for my
user to get write access.
2. I have the following directory:
dr-xrws--- 1 apache_user developers_group 0 Mar 18 2004 userimages/
Again I, as a member of developers_group, should be able to create a new file
but I can't: permission denied.
BTW I using ldap based authentication.
I have 'unix extensions = yes'.
Has there been any advances on this matter since 2004-03-24?
This issue may Solaris bug 5014922... Sun have (just recently) fixed this in
Solaris 9 patch 112960-22 and in Solaris 10.
solaris bug. Thanks for the update.