Bug 4029 - After upgrading from 3.0.23 to 3.0.23b shares with groups in "valid users" not more accessable
Summary: After upgrading from 3.0.23 to 3.0.23b shares with groups in "valid users" no...
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.23b
Hardware: x86 Linux
: P3 critical
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2006-08-17 13:27 UTC by Rudolf Kollien
Modified: 2006-08-18 10:04 UTC (History)
0 users

See Also:

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):
  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.


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 (dead mail address) 2006-08-17 22:41:33 UTC
Please test 
That should fix it.
Comment 5 Rudolf Kollien 2006-08-18 10:04:41 UTC
Many thanks. Now works as expected. Solved.