On Thursday April 5th numerous users started experiencing abrupt workstation reboots (i.e. crashes without proper shutdown or BSOD) when they copied, saved, or renamed files on our Samba shares. This Samba server has run flawlessly for years in essentially the same configuration as now, and exactly the same configuration since Christmas. The problem does not occur when writing to Microsoft or Novell (NCP) shares. All tested workstations were running Windows XP with Service Pack 2.
This problem always and only occurs on workstations which are running both the Novell Client and Symantec AntiVirus. We can only induce the problem by installing both, and removing either one always cures the problem.
Regarding Symantec, it was a virus definition file from soon after March 27th 2007 (probably one from the week of April 2nd) that triggers the problem. The same program version (10.1.5.5000) and scan engine version (18.104.22.168) with virus definition files earlier than March 27th do not trigger the problem. As far as we know, all virus definition updates since the problem first appeared have continued to perpetuate the problem.
Regarding the Novell Client, a default installation is adequate to replicate the problem -- no need for the Zenworks client, or even to log in. Also, moving the Novell Client to the bottom of the "provider order" list does not fix the problem. Tested versions were 22.214.171.12461109 and 126.96.36.19951209.
Regarding Samba, we mostly tested default installations from samba.org source code (as opposed to OS distro packages) running on Slackware 10.2. Of the versions we tested, 3.0.22 is not susceptible; 3.0.23, 3.0.23d, and 3.0.24 are susceptible; and version 3.0.25rc2 is not susceptible. (Versions 2.2.5 and 2.2.12 are also not susceptible.)
Although the timing of the problem's first appearance corresponds suspiciously with the release of Microsoft's patch KB925902 (the out-of-cycle animated cursor patch), we have eliminated this patch as a factor.
Even though I believe that Symantec is more directly responsible for this problem, I'm also reporting it to you as a Samba bug because of the fact that only a specific narrow range of recent Samba versions seem to be susceptible. As far as I can tell (from the release notes, Bugzilla, and the mailing list) you haven't been previously aware of this problem (sorry if I'm wrong about that; I don't understand everything I read), and thus it seems that the susceptibility has been introduced and then fixed by accident without your awareness of it, and therefore could be re-introduced again in the future by accident unless you are made aware of it.
quick check: Try with 'host msdfs = no' and 'msdfs root = no' in [global]
I tested again in version 3.0.23, with the msdfs options turned off as suggested by Volker in comment #1, and the problem disappeared!
Should I have known to try this? Is it really a bug?
For the record, here's my smb.conf (sorry I forgot to include it in my initial report):
netbios name = testserver
workgroup = lis
server string = testserver
security = user
encrypt passwords = yes
hosts allow = all
hosts deny = all
local master = no
mangled names = no
# host msdfs = no <-- added at Volker's advice, fixes problem
# msdfs root = no <-- added at Volker's advice, fixes problem
path = /home/tom
writable = yes
valid users = tom
write list = tom
create mask = 644
directory mask = 755
force create mode = 644
force directory mode = 755
Created attachment 2448
Closed due to spam attachement
Comment on attachment 2448