From: jjjdavidson on
It took a little while, but Microsoft got out a hotfix for this problem:

http://support.microsoft.com/KB/983458

I've been running the hotfix for a couple of weeks now and XP/NT
communication seems to be working correctly again. Thanks for your help!

"Andrew McLaren" wrote:

> Thanks, that's interesting info ...
>
> I'm not sure exactly which of the 980232 vulnerabilities is in play
> here. But I'd guess the NT 3.5 machine is returning a SMB packet to XP,
> which has "incomplete" information in one of the headers; and hence
> resembles a malformed or malicious SMB assault. In the relatively lax
> world of NT 3.5 that was acceptable; but in the more rigorous world of
> contemporary XP, that is no longer acceptable. So XP now rejects some
> packet which NT 3.5 sends back to it, during the NTbackup. It seems to
> affect ACL data ... which is a bummer, in your context.
>
> The "CNC software" may be CAD/CAM? Masterware?? If so, may be time to
> (reluctantly) upgrade??? I'm sure they have lots of whizz-bang features
> in their latest version :-) Anyways, good luck with it ...
>
> Cheers,
>
> Andrew
> Sydney Australia
>
>
> On 8/05/2010 06:13, jjjdavidson wrote:
> > I was able to modify my backup batch file to use XCOPY - with one
> > qualification. I can't use the XCOPY /O or /X parameters to copy owner, ACL,
> > or audit settings. Apparently KB980232 improves the SMB client's handling of
> > ACLs or other security information on files - improves it to the point that
> > NT3.5 and NT4.0 can't talk to XP any more.
> >
> > One of the Technet threads I found mentions today that a hotfix might come
> > out soon. X'd fingers.
> >
> > "jjjdavidson" wrote:
> >
> >> Yes, it was a classic. Even though I miss my right mouse button, I love the
> >> stability. In _eleven years_ I've never seen that workstation crash once.
> >> But it has never played well with Win2K and later.
> >>
> >> I read up on all the April patches and found that KB980232 updates the SMB
> >> client. Googling for problems, I'm not alone (apparently a lot of people
> >> still run NT4.0 servers):
> >>
> >> http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/bae1e32a-b878-4af2-8d27-9b747e11bf21
> >> http://social.answers.microsoft.com/Forums/en/vistawu/thread/fc1669c5-2e30-4207-8fe2-54a54f02679a
> >>
> >> This appears to be a pretty broad problem with KB980232 and pre-Win2K
> >> systems. It seems the files can be read just fine (hence my usable backups)
> >> but the ACLs are inaccessible. That's the second patch in three months
> >> (KB978037 zombie windows) to break something on my systems--unprecedented.
> >>
> >> Thanks for the input. For the time being, I probably will have to update my
> >> batch job to run an XCOPY (uninstalling KB980232 seems excessive).
> >>
> >> "Andrew McLaren" wrote:
> >>
> >>> Hi jjjdavidson
> >>>
> >>> I didn't see any other replies, so here's my 2 cents ...
> >>>
> >>> This error message from NTBackup is fairly common and usually happens
> >>> when there is some kind of problem in the SMB network session to the
> >>> mapped drive. To say what the problem is exactly, you'd probably need to
> >>> get a network trace, using Microsoft NetMon or Wireshark. These are both
> >>> free downloads; and fairly easy to use if you have a background in
> >>> networking. Otherwise they may be a bit opaque ....
> >>>
> >>> Because the problem started after the April security fixes were applied
> >>> to the XP machine, they would seem to be implicated - perhaps they
> >>> enforce a more rigorous behaviour which the old NT 3.5 machine cannot
> >>> comply with (I've seen this with many security patches in the past). One
> >>> workaround would be to uninstall the security patch from the XP machine
> >>> - but, I don't really recommend that.
> >>>
> >>> An alternative workaround might be to XCOPY the files from the U: drive
> >>> to the local XP machine (since this seems to work okay) and then back
> >>> them up from there. In the case of a restore, you'd XCOPY the files back
> >>> across to the NT 3.5 machine. Not a perfect solution but it might keep
> >>> you going.
> >>>
> >>> Nice to see a NT 3.5 machine still running, out there ... it was a
> >>> classic OS!
> >>>
> >>> Hope this helps a bit,
> >>>
> >>> Andrew
> >>>
> >>> --
> >>> amclar at optusnet dot com dot au
> >>>
> >>>
> >>>
> >>> On 6/05/2010 06:29, jjjdavidson wrote:
> >>>> Our network has one elderly NT 3.50 workstation named LASER1 (running
> >>>> proprietary CNC software). I've long been running weekly backups of critical
> >>>> files on LASER1. On a nearby XP workstation, I map a drive (U:) to a network
> >>>> share on LASER1, then use XP's NTBackup. For six years it's run without any
> >>>> serious problems.
> >>>>
> >>>> Three weeks ago the XP workstation's backup log reported, "The network disk
> >>>> drive has stopped responding. Backup set aborted." The next week it did the
> >>>> same thing. Both times, the backup file was obviously much too small for the
> >>>> backup to have been successful.
> >>>>
> >>>> Last week, NTBackup instead logged messages like, "Could not access portions
> >>>> of file U:\100HOLES.CNC. You may not have permission to open the file, or the
> >>>> file may be missing or damaged," apparently for all 6000 files and
> >>>> directories on LASER1. However, the backup file size went back up to normal.
> >>>>
> >>>> Manually running the backup job today, I again got "Could not access
> >>>> portions" messages for everything, with a normal-sized backup file. A test
> >>>> restore apparently could retrieve all of the LASER1 files successfully;
> >>>> Windiff showed no differences between existing files on LASER1 and the
> >>>> test-restored files. But since the backup itself got errors, the verify step
> >>>> was never run.
> >>>>
> >>>> Connecting to LASER1 over the network, I can read any desired file normally.
> >>>>
> >>>> Any idea what's suddenly causing these errors, and how to get rid of them?
> >>>> NT 3.50 on LASER1 never gets updated; the XP workstation running NTBackup had
> >>>> the April Microsoft security updates installed the morning before the first
> >>>> backup failed.
> >>>>
> >>>> Thanks!
> >>>
> >>> .
> >>>
>
> .
>