Bug 4041 - After upgrading from 3.0.23 to 3.0.23b cannot longer write to share
After upgrading from 3.0.23 to 3.0.23b cannot longer write to share
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Upgrade
3.0.23b
Other Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-21 12:40 UTC by Rudolf Kollien
Modified: 2006-08-22 11:12 UTC (History)
0 users

See Also:


Attachments
Log with debuglevel=10 when trying to copy the file to the share "netlogon" (60.24 KB, application/x-gzip)
2006-08-21 12:45 UTC, Rudolf Kollien
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rudolf Kollien 2006-08-21 12:40:17 UTC
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).
Comment 1 Rudolf Kollien 2006-08-21 12:45:08 UTC
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.
Comment 2 Jeremy Allison 2006-08-21 12:54:10 UTC
Please post your snb.conf and the permissions on the diretory giving permission denied.
Thanks,
Jeremy.
Comment 3 Gerald (Jerry) Carter 2006-08-21 14:24:55 UTC
Get the lookup_name_smbconf_v2.patch from http://www.samba.org/~jerry/patches/
We'll release 3.0.23c in a few days.
Comment 4 Rudolf Kollien 2006-08-21 15:21:29 UTC
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. 
Comment 5 Rudolf Kollien 2006-08-21 15:25:08 UTC
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
Comment 6 Gerald (Jerry) Carter 2006-08-21 15:33:08 UTC
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?
Comment 7 Rudolf Kollien 2006-08-21 18:40:57 UTC
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"??
Comment 8 Gerald (Jerry) Carter 2006-08-21 22:31:16 UTC
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).

Comment 9 Rudolf Kollien 2006-08-22 04:49:36 UTC
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"?
Comment 10 Gerald (Jerry) Carter 2006-08-22 11:12:06 UTC
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.