disciple_of_chim-chim
asked on
Arcserve 12 - Inaccessible File System Device
CA ARCserve Backup r12 build 5454 on Windows 2000 SP4. Have been using remote FSDs on Server 2003 box for a long time. Shared folders are on 500GB USB drives that are rotated as they fill up. Recently upgraded from 11.5. Just did a swap and get "Inaccessible File System Device". First it was telling me that the FSDs (GRP3 "mail" and GRP4 "file") were write protected when I tried to format or erase (new one on me). I stopped all CA services, unshared the folders, deleted the old data. Reshared and now get the present message. Deleted them altogether and made new ones. In Device Group Configuration, they are now listed as "PGRP0 <Device:5> FSD1" and "PGRP1 <Device:6> FSD2". Attempt to format gives "Device <5> Format Failed! FAILED TO WRITE VOLUME HEADER" and erase gives "Device <5> Erase Failed! COMMAND ABORTED"
All share permissions on folders the same as usual. Using the domain administrator account, not the ARCserve system account, as usual. The device path is correct for each FSD under "summary". Snaplock "no". Volume free space 98%.
Just 2 more weeks with this wretched, diabolical program; 11, 11.5, now 12. This is the last time I will have to do this.
Thank you.
All share permissions on folders the same as usual. Using the domain administrator account, not the ARCserve system account, as usual. The device path is correct for each FSD under "summary". Snaplock "no". Volume free space 98%.
Just 2 more weeks with this wretched, diabolical program; 11, 11.5, now 12. This is the last time I will have to do this.
Thank you.
ASKER
FSD on the ARCserve server works.
FSD on a different remote system - "Inaccessible File System Device"
FSD on this same remote system but not on the USB drive - "Inaccessible File System Device"
FSD on a different remote system - "Inaccessible File System Device"
FSD on this same remote system but not on the USB drive - "Inaccessible File System Device"
Based off the tests it looks like the source of the problem is something at the ARCserve server.
As a test change the ARCserve System Account to a domain admin user.
Perhaps it is being used in some way.
After the FSD has been configured but before trying a format or erase are there any files in it?
If yes try an erase or format and then check to see if their modified or access date time stamp has changed.
As a test change the ARCserve System Account to a domain admin user.
Perhaps it is being used in some way.
After the FSD has been configured but before trying a format or erase are there any files in it?
If yes try an erase or format and then check to see if their modified or access date time stamp has changed.
Based off the tests it looks like the source of the problem is something at the ARCserve server.
As a test change the ARCserve System Account to a domain admin user.
Perhaps it is being used in some way.
After the FSD has been configured but before trying a format or erase are there any files in it?
If yes try an erase or format and then check to see if their modified or access date time stamp has changed.
As a test change the ARCserve System Account to a domain admin user.
Perhaps it is being used in some way.
After the FSD has been configured but before trying a format or erase are there any files in it?
If yes try an erase or format and then check to see if their modified or access date time stamp has changed.
ASKER
As stated, I am not using the ARCserve System Account, I am using the domain\administrator account. As stated, i erased the old backups, there is nothing on it except for a text file i used as a write test
Based off the tests it looks like the source of the problem is something at the ARCserve server.
As a test change the ARCserve System Account to a domain admin user.
Perhaps it is being used in some way.
After the FSD has been configured but before trying a format or erase are there any files in it?
If yes try an erase or format and then check to see if their modified or access date time stamp has changed.
As a test change the ARCserve System Account to a domain admin user.
Perhaps it is being used in some way.
After the FSD has been configured but before trying a format or erase are there any files in it?
If yes try an erase or format and then check to see if their modified or access date time stamp has changed.
ASKER
wanna try that again?
The ? on the System Account is because it is used for some background operations, so I was thinking it might be involved.
The other ?s were to determine if the FSD configuration program was creating the control files as it normally should and if the Tape Engine was even accessing them.
Sorry looks like I can't help in this case.
The other ?s were to determine if the FSD configuration program was creating the control files as it normally should and if the Tape Engine was even accessing them.
Sorry looks like I can't help in this case.
What exactly are you asking me to try again?
ASKER
youre comment posted at 8:21 was posted again, twice, after I responded to it. Look at the comments.
I read your update that local FSD works and all tested remote fail.
This lead me to suspect a problem at the ARCserve server. Knowing the System Account is used for some background tasks (meaning security access to the target is done via Windows authentication using the security info supplied, but there is also a lower level access done via the ARCserve System Account in some cases) hence the suggestion about the System Account.
Next to establish the boundaries of the problem the other questions came about the files in the FSD. When FSD Configuration is complete there should be one file in the directory HEADER.CTF and that is it. If this file was missing then not even the configuration utility could properly access it, etc.
So there really was thought and intent behind my responses and not just random ideas thrown out there.
This lead me to suspect a problem at the ARCserve server. Knowing the System Account is used for some background tasks (meaning security access to the target is done via Windows authentication using the security info supplied, but there is also a lower level access done via the ARCserve System Account in some cases) hence the suggestion about the System Account.
Next to establish the boundaries of the problem the other questions came about the files in the FSD. When FSD Configuration is complete there should be one file in the directory HEADER.CTF and that is it. If this file was missing then not even the configuration utility could properly access it, etc.
So there really was thought and intent behind my responses and not just random ideas thrown out there.
ASKER
The only FSD that has a HEADER.CTF in it is the one on the local Arcserve machine, the only one without the "Inaccessible File System Device" error, obviously the only one whose configuration is complete.
I changed security settings on the FSDs from the domain\administrator account to the ARCserve System Account, still "Inaccessible File System Device".
I changed security settings on the FSDs from the domain\administrator account to the ARCserve System Account, still "Inaccessible File System Device".
I changed security settings on the FSDs from the domain\administrator account to the ARCserve System Account,
Interesting idea, not what I had recommended but interesting, and that opens up to the question, what happens if you set security settings on that folder to Everyone.
Interesting idea, not what I had recommended but interesting, and that opens up to the question, what happens if you set security settings on that folder to Everyone.
ASKER
I meant in Device Configuration>security>"pl
I set the FSD's folder share security permissions to Everyone, "Inaccessible File System Device"
I've stopped and restarted all CA services, rebooted the ARCserve server and even reformatted the USB drive. "Inaccessible File System Device"
I set the FSD's folder share security permissions to Everyone, "Inaccessible File System Device"
I've stopped and restarted all CA services, rebooted the ARCserve server and even reformatted the USB drive. "Inaccessible File System Device"
I meant actually changing the ARCserve System Account to a Domain Admin account.
ASKER
posting now, standby....
ASKER
OK, Im confused. Its been so long since I installed 11.1, I dont remember the origin of "ARCserve System Account". Is it built in by default or is it the domain account I use to run the jobs? Then theres "caroot" who "owns" the jobs in the job queue.
In Device Configuration>security>"pl
In Device Configuration>security>"pl
the System Account is found at the Server Admin.
ASKER
Yes, that is set for the domain\administrator account.
ASKER
Theres the old saying "I'd p*ss on a sparkplug if I thought it would work." Im ready to start p*ssing, if I could think of something.
I thought of using the working local FSD and tricking it with folder redirection but this is an NT4 domain, no AD, no GP.
No backup in a week, very bad. You could remote in...
I thought of using the working local FSD and tricking it with folder redirection but this is an NT4 domain, no AD, no GP.
No backup in a week, very bad. You could remote in...
If there has not been a backup in a week it is best to just open an issue with CA support. Online forums can be a great help but no backups is a top priority type of thing.
ASKER
Believe me, if my CA support contract was still good, we wouldnt be having this conversation.
Set the Job Engine into Debug and the Tape Engine into Detail mode.
Then create a new FSD and post the portion of each log for the process if there is anything that looks suspect.
Not sure if the activity log will have anything on it but it is worth a try, check the Generic Logs section for that. The tape log I imagine will have something on the failure to create the header file.
You probably have it installed already but if not install SP1 for 12.0. I know you posted the build but I don't keep track of build #s and am running 12.5.
Create a new domain admin user and try that.
Check firewall setting.
Try a Copy job to see if ARCserve can copy data to this same volume.
Then create a new FSD and post the portion of each log for the process if there is anything that looks suspect.
Not sure if the activity log will have anything on it but it is worth a try, check the Generic Logs section for that. The tape log I imagine will have something on the failure to create the header file.
You probably have it installed already but if not install SP1 for 12.0. I know you posted the build but I don't keep track of build #s and am running 12.5.
Create a new domain admin user and try that.
Check firewall setting.
Try a Copy job to see if ARCserve can copy data to this same volume.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
See if a FSD on the ARCserve server works correctly.
See if a FSD on a different remote system works fine.
See if a FSD on this same remote system but not on the USB drive works fine.
The command abort is the error code returned back to ARCserve from the OS. It is a low level error, not typical of a security problem. It typically happens when the Tape Engine has already established communication with the device and then a conflict happens preventing the command from being done.