Bug 311 - winbindd errors after extended idle period
Summary: winbindd errors after extended idle period
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: winbind (show other bugs)
Version: 3.0.0preX
Hardware: All Windows XP
: P2 normal
Target Milestone: 3.0.0rc3
Assignee: Tim Potter
QA Contact:
Depends on:
Reported: 2003-08-18 03:57 UTC by Heiko Garbe
Modified: 2005-11-14 09:26 UTC (History)
0 users

See Also:

Level 10 Log from winbind (105.74 KB, application/octet-stream)
2003-08-25 00:39 UTC, Heiko Garbe
no flags Details
Appears to be the same problem described by this person (55.22 KB, text/plain)
2003-08-26 07:54 UTC, Brian King
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Garbe 2003-08-18 03:57:58 UTC
We have a Redhat9 Server with Samba 3.0.0 beta3.
The configuration of Samba really works fine, but there are some things 
disturbing me:
When I try to access to a share early in the morning after booting my WindowsXP-
Box a username-password mask appears. Sometimes when I enter my username and 
password I get access to the share and sometimes not.
After rebooting my XP-Box everything okay, and i can connect without entering a 
username and password.

Here are some cuts from the log-files:

write_socket: Error writing 4 bytes to socket
getpeername failed Socket not connected

Not a user account? atype=0x30000000
user 'peter' does not exist

It seems to me, that winbindd is not working correctly, although it displays 
the users and groups of our domain with wbinfo -u and wbinfo -g.
When I create new files in a share they belong to my domain-user-account and 
the domain-users group. So that all works very good, but how come that 
sometimes early in the morning I need to reboot my PC to access the share(s).

Here's the smb.conf:

# Global parameters
	realm = realm.de
	workgroup = realm
	server string = Linux File-Server
	encrypt passwords = yes
	password server =
	security = ADS
	log file = /var/log/samba/log.%m
	max log size = 1024
	wins server =
	idmap uid = 10000-20000
	idmap gid = 10000-20000
	template shell = /bin/bash
	winbind cache time = 0
	winbind enum users = yes
	winbind enum groups = yes
	show add printer wizard = no
	load printers = no
	locking = no
	level2 oplocks = no

	comment = Users
	path = /sahres/users
	read only = no
	browseable = yes
	valid users = @REALM\Support
	directory mask = 0700
	force directory mode = 0700
        create mode = 0700
	force create mode = 0700
	directory security mask = 0700
Comment 1 Gerald (Jerry) Carter (dead mail address) 2003-08-22 09:07:43 UTC
Please provide a level 10 debug log from winbindd
Comment 2 Heiko Garbe 2003-08-25 00:39:22 UTC
Created attachment 103 [details]
Level 10 Log from winbind

Here's the log file from winbind. I deleted the old one before changing the log
level, but I also have another log-file from winbind which contains mainly the
following lines:
[2003/08/25 09:19:47, 1] nsswitch/winbindd_ads.c:query_user_list(155)
  Not a user account? atype=0x30000000
[2003/08/25 09:19:50, 1] nsswitch/winbindd_ads.c:enum_dom_groups(269)
  No rid for Administratoren !?

and so on...

Winbind uses both files for logging.

If you need to know more information or log-files from machines accessing the
samba-server please let me know.

Comment 3 Brian King 2003-08-26 07:54:39 UTC
Created attachment 106 [details]
Appears to be the same problem described by this person

In this attachment, it shows the samba server eventually recovering from the
problem, without requiring a client reboot. I was repeatedly trying to connect
to a share using "smbclient -k" and getting denied. After approximately 1-2
minutes, winbind "recovers" and starts allowing me in.

From the debug output, it appears as if the kerberos tickets allowing the Samba
server to authenticate to the AD servers expired and winbind waits until a user
request comes in to decide to renew them. In the meantime, it denies users
access by returning a "user does not exist".
Comment 4 Brian King 2003-08-26 07:58:55 UTC
Forgot to mention the binary versions in use. I am experiencing this with CVS 
code from Aug.22 (CVS 3.0.0rc2). Also, debug level 10 was set part way through 
the log file using 'smbcontrol'. Before that it was debug level 1.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2003-08-27 13:05:12 UTC
RC2 will ship with this issue unresolved.  We'll put it on 
the plate for RC3 and hope to resolve it by then.
Comment 6 Tim Potter 2003-08-30 01:20:36 UTC
Apparently the krb5_get_credentials can be convinced to fetch a new ticket if
the old one has expired.  You need to update a timestamp in the input credential
or something like that.
Comment 7 Tim Potter 2003-08-30 17:48:01 UTC
Here's a note about convincing krb5_get_principal() to refresh an expired ticket:

Comment 8 Gerald (Jerry) Carter (dead mail address) 2003-09-04 21:48:12 UTC
I think this should be fixed by the patch I did for bug 364.
It provides a simple means of working around connections that are dead
but we don't know it until we try one.

I think this should be fixed now.  If not, then reopen.
Comment 9 Gerald (Jerry) Carter (dead mail address) 2005-02-07 08:41:24 UTC
originally reported against 3.0.0beta3.  CLeaning out 
non-production release versions.
Comment 10 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:22:25 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 11 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:26:22 UTC
database cleanup