[Samba] Receiving SMB: Server stopped responding

Jason A. Nunnelley jason at jasonn.com
Fri Aug 29 13:33:05 GMT 2008

Jason A. Nunnelley wrote:
 > This seems to be an ongoing, never-ending problem with our installation of Samba 
3.0.31, patched, running in FreeBSD 7.0 Stable RELENG updated.
 > tail -f /var/log/samba/winbindd.log
 > [2008/08/28 10:26:31, 0, pid=1839] libsmb/clientgen.c:cli_receive_smb(111)
 >   Receiving SMB: Server stopped responding
 > [2008/08/28 10:26:43, 0, pid=1839] libsmb/clientgen.c:cli_receive_smb(111)
 >   Receiving SMB: Server stopped responding
 > [2008/08/28 10:26:56, 0, pid=1839] libsmb/clientgen.c:cli_receive_smb(111)
 >   Receiving SMB: Server stopped responding

Posting over myself to update those that were paying attention.

I had every intention of looking more deeply into this problem and reporting a daemon 
level activity during the "quiet times" seen with this incarnation of Samba.  But, here's 
what I have to report instead -- and there's no known/clear logic yet.  The folks come 
into the office in a few hours and we'll see how it behaves under real-world activity.

Previous condition:
Samba 3.0.31 patched for the winbinds problem reported recently
FreeBSD port version
"Server stopped responding," with no more feedback in the log
Full smb.conf (present) attached below for consideration (domain modified)

1) I made a few modest changes to the smb.conf which /shouldn't/ necessarily have had that 
severe an impact on overall performance.  But, seemingly it did.
2) We ran real-world tests with Paradox (a Windows-based dB using files on the SMB shares) 
that stressed the NIC to its limits all night.  We pushed a script to 5 client machines to 
search, index, etc. the smb share data to the peak of its ability with the present network 
3) The winbinds error listed above went away immediately with the modification to the 
smb.conf, and has not returned during testing or quiet on the network.


Here's what I changed:
auth methods = sam
hosts allow = 192.168.1.


I removed from the host allow.  That should have had no effect.  But, it was one 
of the changes I made.  I also added an authentication specifier, which is what I think 
made the difference.  Unfortunately, this is on a production network and I need to let 
these poor folks make a few dollars before I start playing with the config to see if I can 
recreate the error and capture the feedback from some auditing/developing tool.

I'll post more information on this issue.


Jason A Nunnelley
President Tech Anything, Inc.

1 888 846 4109 Fax
1 256 962 0290 Voice


Full smb.conf as it is now:

workgroup = SMBGROUP
map to guest = Bad User
add machine script = /usr/sbin/pw useradd -d /var/lib/nobody -g 100 -s /bin/false -n %u
log level = 1 winbind:2
debug pid = yes
log file = /var/log/samba/%m.log
logon drive = H:
domain logons = yes
domain master = yes
netbios name = SMBHOST
os level = 65
preferred master = yes
logon script = logon.bat
veto oplock files = 
wins support = yes
auth methods = sam
use client driver = yes
veto files = /*.eml/*.nws/riched20.dll/*.{*}/
hosts allow = 192.168.1.
hosts deny =
server string = SMB Server
idmap domains = ALLDOMAINS
idmap config ALLDOMAINS:default = yes
idmap config ALLDOMAINS:backend = tdb
idmap config ALLDOMAINS:range   = 10000 - 50000
idmap alloc backend = tdb
idmap alloc config:range = 10000 - 50000

comment = Home Directories
browseable = no
Writable = yes
force group = sambagroup
force create mode = 0660
force directory mode = 0770
create mask = 0770

comment = Network Logon Service
path = /home/netlogon
guest ok = yes
writable = no
share modes = no

# X:
comment = Data Drive
path = /data/DATA
read only = No
guest ok = No
force group = sambagroup
force create mode = 0770
force directory mode = 0770

More information about the samba mailing list