I have a share netlogon and a share kolli. To share netlogon everyone has read access (=public) and only members of group "ntadmin" have write access. To the share kolli only i have access. Now i would copy a file from the dir Software\.....\.....\200608 to the dir win2000 in the share netlogon. When running 3.0.23b i get a "permission denied. File maybe accessed". When running 3.0.23 i can copy the file to the netlogon share as expected (and as it did all versions below 23b). No permissions or something else changed between the upgrade. As 3.0.23b didn't do the job, i invoked a "make revoke" in the 3.0.23b source dir. Both version (23 and 23b) are compiled on the same system, compiler and the exactly same config options (see bug# 4029 for config details).
Created attachment 2099 [details] Log with debuglevel=10 when trying to copy the file to the share "netlogon" This is the log when trying to copy the file to the netlogon share. The file DEFINETELLY exists, the share and the file are access- and writeable. Again: When reverting from 23b to 23, the copying functions. And - this problem exists for EVERY file trying to copy to netlogon. With 23b copying the file from the kolli share f.e. to the C:\ drive functions. Copying the file within the kolli share is also ok.
Please post your snb.conf and the permissions on the diretory giving permission denied. Thanks, Jeremy.
Get the lookup_name_smbconf_v2.patch from http://www.samba.org/~jerry/patches/ We'll release 3.0.23c in a few days.
For the completness: for "netlogon" and all dirs beyound: Permissions rwxr-xr-x Owner kolli Group users [netlogon] comment = Anmeldeverzeichnis fake oplocks = true path = /u/samba/pc/netlogon write list = @ntadmin writeable = no public = yes locking = no kolli is member of ntadmin and currently the only one who uses this share for write access. Therefore group "users" shouldn't matter. As written, with 3.0.23 there are no problems. I'm sorry to say, that this problem is NOT solved by the lookup_name_smbconf_v2.patch. I already applied the patch against 3.023b for the bug 4029. Bug 4029 was solved by the patch, this bug isn't.
Forgot to say: Write access to the netlogon share is only done when all users are logged off. As of some problems in the time past with win98 and win95 clients logging on concurrently, we had inserted the "fake oplock" and "locking no". This was of versions 2.x of samba. Don't know, if it is still required on 3.x as AFAIK the oplock code was rewritten. B
I still think this is fixed. Do you have a group mapping entry for the ntadmins group? If so, please read on.... btw...There is no access denied in your log file except for [reuschel] comment = Reuschel-Verzeichnis valid users = @reucash path = /u/reuschel public = no writeable = yes printable = no create mode = 666 force user = disk On to the matter at hand.... When the user logs in, he gets the SID from the group mapping db. For your domain admins group, this would be something like S-1-5-21-XXX-XXX-XXX-512. When you put valid users = +ntadmin, you are mixing mapped and unmapped names. The root unix group is unmapped and therefore resolves to the S-1-22-2-X SID. However, if you set 'valid users = "Domain Admins"', it should work fine because DOmain Admins will resolve to S-1-5-21-XXX-XXX-XXX-512. You should not have to fully qualify "Domain Admins". If you do, that is a bug, but you do have to use the mapped name if the group exists in the passdb. Make sense?
Hmm, on line 9596 of the logfile, there is a "Permission denied opening win2000/Windows2000-KB917008-x86-DEU.EXE". Which is the destination on the share "netlogon". The file doesn't exist. Share ist read/writeable. But access is denied on opening a unexisting file??? I confirm that there is a mapping from unix group "ntadmin" to Win "Domain Admins". I forgot this, as it is from the stoneage of samba 3.x. And i understood sambas group mapping as a way, that _Win2k/XP_ machines accept unix users with the mapped group as correct domain members. I didn't realize, that samba itself now started to use the mapped group for accesshandling on local samba shares and not longer the unix groups. In this case, shouldn't all groups be mapped to an corresponding alias???? But - could it be you mixed the two bugs i reported??? In the logfile from this bug (4041) there is definitely no access to the share "reuschel" logged? And you mention the "valid users" param. This is not used in the definition of share "netlogon"... I now starting to get a little bit confused... To me it seems bug 4029 and 4041 are different? What do you mean with 'You should not have to fully qualify "Domain Admins"'. Where? What is the abreviation "abbreviation"??
OK. Found the error you were referrnig to. The log file is a little cluttered. This is your token: NT user token of user S-1-5-21-1072873184-2303547677-1027225787-2030 contains 20 SIDs SID[ 0]: S-1-5-21-1072873184-2303547677-1027225787-2030 SID[ 1]: S-1-5-21-1072873184-2303547677-1027225787-513 SID[ 2]: S-1-1-0 SID[ 3]: S-1-5-2 SID[ 4]: S-1-5-11 SID[ 5]: S-1-5-21-1072873184-2303547677-1027225787-512 SID[ 6]: S-1-22-2-103 SID[ 7]: S-1-22-2-201 SID[ 8]: S-1-22-2-202 SID[ 9]: S-1-22-2-204 SID[ 10]: S-1-22-2-208 SID[ 11]: S-1-22-2-210 SID[ 12]: S-1-22-2-212 SID[ 13]: S-1-22-2-500 SID[ 14]: S-1-22-2-1001 SID[ 15]: S-1-22-2-1002 SID[ 16]: S-1-22-2-1003 SID[ 17]: S-1-22-2-5000 SID[ 18]: S-1-22-2-10000 SID[ 19]: S-1-5-32-544 If you have a mapping to the ntadmin group, then set 'write list = "Domain Admins"' (i.e. the mapped name, not the Unix group name).
Ok. Now i understand. I will test this wednesday evening (MEST). No time frame before as this is a production server. Is there a directive when unix groups are used and when mapped group names? I searched the man for smb.conf and didn't find any hint that on the samba side of user management the Windows (=mapped) groups are siginificant. As of current man of smb.conf: .... A name starting with a '@' is interpreted as an NIS netgroup first (if your system supports NIS), and then as a UNIX group if the name was not found in the NIS netgroup database. A name starting with '+' is interpreted only by looking in the UNIX group database. A name starting with '&' is interpreted only by looking in the NIS netgroup database (this requires NIS to be working on your system). The characters '+' and '&' may be used at the start of the name in either order so the value +&group means check the UNIX group database, followed by the NIS netgroup database, and the value &+group means check the NIS netgroup database, followed by the UNIX group database (the same as the '@' prefix). .... Interpreting this right, than ONLY unix side (pam and NIX) groups and usernames are allowed. When a groupname is prepend with a "+" it should ONLY lookup in the unix group, a "&" should only use NIX and a "@" should search ONLY NIS and pam. But there is no word about "mapped group names". To my mind it BEAKS completly the behavor of the group modifiers. Wouldn't it be a better way to introduce a new modifier like "^" to use mapped group names (but don't know, why this some should do? Every mapped group name must exist as unix group). Would it be better to create a new bug case as this may not be a "permission problem"?
Ignore my previous comments. I've been convinced that this is too big of changes and breaks backwards compatibilty with too many existing configurations. Try v3 of the lookup_name_smbconf patch at http://www.samba.org/~jerry/patches/. That should fix things. Please reopen if it does not.