Bug 4029 - After upgrading from 3.0.23 to 3.0.23b shares with groups in "valid users" not more accessable
After upgrading from 3.0.23 to 3.0.23b shares with groups in "valid users" no...
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.23b
x86 Linux
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-17 13:27 UTC by Rudolf Kollien
Modified: 2006-08-18 10:04 UTC (History)
0 users

See Also:


Attachments
logfile snap with debuglevel=10 (8.15 KB, application/zip)
2006-08-17 13: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-17 13:27:21 UTC
SuSE 9.0, kernel 2.4.21-303-smp
selfcompiled from tar-ball
configure options: 
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc/samba3 
--with-privatedir=/etc/samba3 --libdir=/etc/samba3 --with-libdir=/etc/samba3 --with-logfilebase=/var/log/samba3 --with-lockdir=/var/lock 
--with-piddir=/var/run --with-automount --with-msdfs --with-vfs --enable-cups --with-acl-support --with-quotas --with-libsmbclient

A share with the following options is perfectly accessable from 3.0.23 (same configure options):
...
[reuschel]
  comment = Reuschel-Verzeichnis
  valid users = @reucash
  path = /u/reuschel
  public = no
  writeable = yes
  printable = no
  create mode = 666
...

Now when i try to access this share with 3.0.23b running, i'm no more able to connect. A debuglevel of 4 shows up the following error message in the log (connecting as user kolli which is member or group "reuschel"):

...
[2006/08/17 20:05:09, 4] smbd/reply.c:reply_tcon_and_X(668)
  Client requested device type [?????] for share [REUSCHEL]
[2006/08/17 20:05:09, 3] lib/util_sid.c:string_to_sid(223)
  string_to_sid: Sid +reucash does not start with 'S-'.
[2006/08/17 20:05:09, 3] smbd/sec_ctx.c:push_sec_ctx(208)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
[2006/08/17 20:05:09, 3] smbd/uid.c:push_conn_ctx(345)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 0
[2006/08/17 20:05:09, 3] smbd/sec_ctx.c:set_sec_ctx(241)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
[2006/08/17 20:05:09, 3] smbd/sec_ctx.c:pop_sec_ctx(339)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 0
[2006/08/17 20:05:09, 2] smbd/service.c:make_connection_snum(571)
  user 'kolli' (from session setup) not permitted to access this share (reuschel)
[2006/08/17 20:05:09, 3] smbd/error.c:error_packet(146)
  error packet at smbd/reply.c(676) cmd=117 (SMBtconX) NT_STATUS_ACCESS_DENIED
...

"reucash" exists as unix group and as NIS. User "kolli" is member of it. I tried to change the "@" with a "+" but same thing. 

Using groups (with "@" or "+") in the parameters "read list" or "write list" work as expected. Only the "valid users" don't work anymore.
Comment 1 Rudolf Kollien 2006-08-17 13:45:24 UTC
Created attachment 2095 [details]
logfile snap with debuglevel=10

I accessed the share with debuglevel increased to 10. Hope, some more usefull information.
Comment 2 Volker Lendecke 2006-08-17 15:07:09 UTC
We'd need a more complete logfile, the one you sent was truncated. Probably you have 'max log size' set to something small. You could also generate per-client log files with 'log file  = /var/log/samba/log.%I', this makes it easier to read.

Thanks,

Volker
Comment 3 Rudolf Kollien 2006-08-17 16:55:58 UTC
This is the whole logfile of one client accessing the share.

I removed the old logfile, increased the loglevel, refreshed the smbd process and than accessed the share. The only thing above the entries shown is the reload of the smbd. No more happend. With the last entry shown in the logfile, the standard win2000 credential dialog appeared where i have had the possibility to enter a different user/password. 

As this is a production server and we process high sensitive data, i think, i'm not able to provide more information in logfiles. Maybe the above logfile contained more data than i wanted to provide (f.e. the NIS-Domain).
Comment 4 Gerald (Jerry) Carter 2006-08-17 22:41:33 UTC
Please test 
http://www.samba.org/~jerry/patches/samba-3.0.23b-lookup_name_smbconf_v2.patch
That should fix it.
Comment 5 Rudolf Kollien 2006-08-18 10:04:41 UTC
Many thanks. Now works as expected. Solved.