Bug 4535 - Workstation with Symantec + Novell crashes writing to Samba 3.0.23 - 3.0.24
Summary: Workstation with Symantec + Novell crashes writing to Samba 3.0.23 - 3.0.24
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.24
Hardware: x86 Linux
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-23 18:34 UTC by Thomas McNeely
Modified: 2007-04-27 07:08 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas McNeely 2007-04-23 18:34:26 UTC
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 (71.2.0.12) 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 4.91.3.20061109 and 4.91.2.20051209.

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.
Comment 1 Volker Lendecke 2007-04-24 00:17:27 UTC
quick check: Try with 'host msdfs = no' and 'msdfs root = no' in [global]
Comment 2 Thomas McNeely 2007-04-24 10:40:07 UTC
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):
  [global]
    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

  [tom]
    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

Thanks!
Tom
Comment 3 SPAMMER 2007-04-27 05:41:05 UTC
Created attachment 2448
Comment 4 Volker Lendecke 2007-04-27 05:43:03 UTC
Closed due to spam attachement
Comment 5 Gerald (Jerry) Carter (dead mail address) 2007-04-27 07:08:38 UTC
Comment on attachment 2448


><HTML><HEAD/><BODY/></HTML>