XP NTBackup with NT 3.50

[jjjdavidson]

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!

 

[Andrew McLaren]

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

 

[jjjdavidson]

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...n/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).

 

[jjjdavidson]

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.

 

[Andrew McLaren]

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

 

[jjjdavidson]

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!