Sharing violation on graphics files 2

[krebbin]

Hi, a problem keeps cropping up on our W2K server backups.
It is "E3406 Unable to read file - sharing violation"
It only happens on GIF, BMP and JPG files and affects ALL of them (over 50,000).
I have recently re-installed and re-configured Arcserve at CAs request due to other security restrictions and am happy that everything else is working well. But this is just bizarre!

 

[jimpames]

Perhaps you are trying to backup the user area holding their temporary internet files?
Post the pathname of some of these files... Jim P. Ames

http://www.jimpames.com

jimpames@hotmail.com

 

[CyberThug]

I would check the service's rights to these files location and just verify if there's some rights issue.

 

[krebbin]

Hi guys, firstly I thought about the temporary internet files, but these are dumped on the harddrive in the workstation. On the network each user has their own network space and this area is where they keep their files. Domain admins etc have total rights across the network.

A thought: I'm trying to backup these files via drivename\c$ & drivename\d$ which are admin shares only. i.e. I cannot see them if exploring My Computer on the backup server. Should I be using other sharenames?

Thanks for your input, Kreb.

 

[jimpames]

It sounds like the files are in use.
You may consider the open file agent for arcserve.
c$ and d$ are the correct way to backup.
You could also backup via a push agent. Jim P. Ames

http://www.jimpames.com

jimpames@hotmail.com

 

[webtoner]

If you are a Arcserve2000 user, Install the client agent on the servers to be backed-up. Then do your backup through the client agent. I had the same problem and once I made the change, the problem went away.

 

[krebbin]

The client agent does get rid of the problem, which indicates that it is not really a sharing violation!
It's taken me a month of chat with CA for them to reach the same conclusion - lucky I had no disasters meanwhile huh?
Thanks guys for the input - I still wanna know why this happens though!!

Col.

 

[mmaloney]

For what it's worth, we have the exact same problem, with the exact same symptoms. We've tried the obvious solutions (files are not in use, no permissions problems, reinstall, etc.) These gifs etc. are in all sorts of unrelated directories, we opened up permissions etc. It's a bug plain and simple.

 

[ericvm]

We use AS2000(build1050) on a W2Ksp2 system and only a PART of the image files, who are on a remote drive(NT4), are affected when we make a backup.
Even the sample.jpg on a W2k client is giving this error.

Strange thing is when the affected files are copied locally on the server where AS2000 is running the error is gone.

(At this time we don't want to use agents because we have had some bad experience when trying to restore a system.)

eric

 

[ericvm]

new info regarding the image files sharing error.

Here's what i tried.
Go to the services (control panel<administrative tools<services)
select the arcserve database service and select properties.
select the <log on tab> and select option <this account>. change to the domain system admin.
change all the properties from the arcserve services to this account.
stop and start the services and do a test.
works for me.
And no need for an agent.

eric

 

[mpulliam]

Last week, I began noticing some of this same behavior within ARCServe 2000. It seems to affect only graphics files. My experience fits in exactly with MMaloney's response in this thread. In my case, however, I don't get sharing violations on all graphics files in all locations. In fact, within a certain directory, some jpg's might get backed up while others do not. There is no rhyme or reason to the locations of the files that are showing sharing violations. None of these files are actually in use at the time of the backup and there are absolutely no problems with the permissions. Moreover, I would also point out that a number of these sharing violation are occuring on a server that is running an open file agent! In total I have about a dozen servers and I'm seeing this problem on a PDC running NT and a standalone running Win2K AS.

I would concur with MMaloney that this is indeed a &quot;bug.&quot; I will probably resort to installing the push agent as there seems to be a general consensus that this resolves the problem.

Mark

 

[krebbin]

Well guys, we got fed up and bought Veritas Backupexec!

It too is not straightforward, but seems to link to W2k better, and its agents backup everything, open files too!

I still prefer the look and feel of arcserve but if it don't work.............
BTW although Veritas reads arcserve tapes it will not restore any data - be warned.

Merry crimble, Kreb.

 

[MissPat]

We had the same problem. We had to get backups because some of the graphics were created by our users for our job product. (Can't say more, or I'd have to shoot you) When we went to the NT client, push-type backup, the graphics backed up just fine, and are restorable, thank God! We're a totally (or almost totally) Win2K system.

 

[ARCserveGuru]

Krebbin, you have turned to the dark side hehehe

 

[ARCserveGuru]

This is all solved quite easily provided your ARCserve system account has an administrator with all the necessary ADVANCED rights. Simply get your Job engine service to log na as &quot;this account&quot; and put in the fully distinguished DOMAIN NAME/USER NAME + password.

regards,

 

[peterbu]

Here is my two cents.

Same problem - 1 server out of 4 near identical builds.

Same 39 image files (JPG, BMG and GIF) out of about 5000 images in user directories.

Went through all the same sugestions as noted above - mostly at the advice of local (Australian) CA support.

Final solution was to stop the W2K Indexing service before the backup and then restart it after completion.

Go figure - now where did I put that Veritas demo CD?...

 

[toerag]

If you happen to be using the Arcserve 2000 Agent, remove it. I recommend using the 6.61 Agent even if CA reckon it doesn't work with Arcserve 2000. I noticed when I ran the 6.61 Client Agent connecting to Acrserve 2000 (V7) I had no issues. As soon as I installed the 2000 Agent, Including SP2 for Arcserve 2000 Server and SP2 Client Agent update all went to mustard. File Pattern Filter failed to work (*.tmp), Compression was not working and above all performance went from a respectable 300-400 mb/min to a shocking 70 mb/min. Well as soon as I noticed that my 17 NT4.0 Server backup (330 GB full backup) took 23hrs through the 6.61 Agent and an alarming 4 Days (Finally gave up after 10 servers)through the 2000 agent. I removed all the 2000 client agents and went back to the 6.61 agent and finally got some worth while sleep and got to keep my job.

 

[fero]

My two cents concerning the client agent:
The error also occurs when backing up local files. Now trying the thing with the services logging on as
domain admin.

Regards

 

[Guest_imported]

Been messing around with this for too long now, almost went with krebbin! Tried logging on services as domain admin, all appears OK now, thanks everyone. We shall see...

 

[ARCserveGuru]

It is also solved if you use the client agent, but I am unsure if I mentioned this before in the thread.

Guru