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: groups cxm21 dept21 root hotline acct m829sec coverage d21os d21mpt rootusr eos unixos adminjr usaweb esadm esdomadm spltadm mkdir /tmp/BAD 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 worked. 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. Thanks, Craig
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.
Craig, 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
Hi, 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 the file. 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.