The Samba-Bugzilla – Bug 311
winbindd errors after extended idle period
Last modified: 2005-11-14 09:26:22 UTC
We have a Redhat9 Server with Samba 3.0.0 beta3.
The configuration of Samba really works fine, but there are some things
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 = 184.108.40.206
security = ADS
log file = /var/log/samba/log.%m
max log size = 1024
wins server = 220.127.116.11
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
socket options = TCP_NODELAY SO_KEEPALIVE IPTOS_LOWDELAY
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
Please provide a level 10 debug log from winbindd
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
[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.
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".
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.
RC2 will ship with this issue unresolved. We'll put it on
the plate for RC3 and hope to resolve it by then.
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.
Here's a note about convincing krb5_get_principal() to refresh an expired ticket:
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.
originally reported against 3.0.0beta3. CLeaning out
non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.