This is becoming an interesting problem. The user of the affected machine I
was dealing with was in dire need of it working. I ended up using the repair
option from the install cd and when that finished and the user logged in
everything worked. So at this point I am unsure as to what the cause is. We
also are running the dreaded Symantec AV. If I get another machine that this
pops up on then hopefully I can have the time to try and isolate the cause.

Thanks again for the info.


Thomas McNeely wrote:
> Hi Jim,
> The Samba listserv rejected this post, so Iím sending it to you
> directly. Feel free to try posting it to the listserv if you like, as
> you did for Rhiannon.
> -----
> We also have this problem. We are using Samba 3.0.23d and 3.0.24, both
> installed from source code (as opposed to the packages that come with
> the operating system), running on Slackware Linux 10.2 and 9.1,
> respectively. The problem first appeared for us on April 5th. Our
> servers had been running fine with no changes since Christmas when the
> problem first appeared.
> The problem manifests as a sudden workstation reboot (without proper
> shutdown) when users do most any kind of write operation to a Samba
> share Ė copying, renaming, or saving files. The affected workstations do
> not have a problem performing these operations on Microsoft servers Ė
> just Samba. Elsewhere on our campus is a Solaris server (unknown
> version) running an unknown version of Samba that does not have this
> problem. Iíll try to get more info about this.
> There is considerable variation among the workstations exhibiting the
> problem Ė different generations of hardware, some are domain members and
> others not, some are logged into Novell and other not. At this point I
> think all the affected workstations run the Novell Client, but that
> thought just now came to me and I havenít experimented with it yet. All
> affected workstations have been running Windows XP with SP2.
> We have definitely determined that a key cause of this problem is
> Symantec AntiVirus. We can induce and cure the problem at will by
> installing or removing Symantec, and weíve done so many times now. I
> donít have the version info available right now; Iíll try to get it soon.
> Although the timing with regard to MS patch KB925902 is extremely
> suspicious, we havenít been able to experimentally establish any
> correlation with that patch. We havenít ruled out that it could be a
> contributing factor though.
> Tom McNeely
> Western Washington University Libraries

Jim Summers
School of Computer Science-University of Oklahoma
To unsubscribe from this list go to the following URL and read the