Hi all, hope someone can help. Long story short, we had to change some domain passwords on users and in doing so, the backup no longer runs. Upon further research, the disk was being "seen" as offline, even though this NAS (a QNAP device) is accessible, there is plenty of storage, and I can browse to it as the domain admin from the server that Backup Exec is installed. I can also get to it as the domain user that was originally running the backup job.
So, after tinkering with things, I just decided to delete the jobs and storage device (nothing was working that I came across under Symantec forums/KBs) and I am now stuck on trying to setup the storage device again from scratch. Every time I try to configure it, it keeps failing. I get the error and screenshot of:
Unable to create the disk storage.
The Backup Exec service account does not have read and write permissions on the remote computer on which the network share is located. The Backup Exec service account that requires these permissions is on the Backup Exec server that you want to access the network share.
You must give read and write permissions to the Backup Exec service account, and then try again.
At this point, I do not know what to do. I've tried other locations to backup to, that hasn't worked. The product is updated from LiveUpdate and I have rebooted the Windows 2008 R2 Standard 64-bit server. I don't actually understand the part about the BE service account. What is that? Where would I be able to tell what that has permission to? To my knowledge we never had to create a specific AD user by this name to then use the product over the network. Can anyone help step me through what might be the problem? Plain and simple, it just seems to not see the NAS device over the network anymore. Thanks for any help...--Kirk
Hi there, Im not following you. I'm not trying to add a server. It is installed on the server already, I'm trying to add a storage device, under the main "Storage" tab and then start the "configure storage" wizard...
The BESA which is the account used to start most of the BE services should have these privileges.
You should also add the BESA to the NAS as a local admin with full read/write access to the entire disk.
PKH - I understand services running as users, local or domain, that you must define, etc., but as far as I can tell there isn't any specific BESA user running these services. I don not see anything created on this server specifically for Symantec. All the Backup Exec services are being ran under a local user as seen in the screenshot.
Like I said, we never created a local user on this server to run this product, and things have been running up to this point. Can you suggest what I need to do in order to get this to work? Sorry, I'm not a total noob but I think I need some help here from the ground up in getting storage setup and help with this BESA user. I mean, at what point would Symantec have asked to create this user or where would you even find this user created either on the server or in the program? Thanks --Kirk
Go to "Configuration and settings" > "Logon Accounts" > "Manage Logon Accounts".
Check to see if ur "System Logon Account" still has correct password.
If this doesn't solve it i would advise to reconfigure and check qnap to see if its connection with the activedirectory is still working correctly.
Follow the Article "Disk storage is stuck in configuring state" : http://www.symantec.com/docs/TECH190949
There might be an Active Job Running in the Background which you might be able to See on the Console. If you look at the Task pane at the Bottom of the Console You would find an Active Job
Put all the Jobs on Hold You Would get an Info as There an Active Job Running. Target the Job and Kill it.
Issue Might Also Occur it the Server is Paused. Pause the Devices Under Storage Tab. Un-Pause and Restart the Backup Exec Services.
These Solution Should Work.
I have Installed Symantec Backup Exec 2012 on Microsoft Windows 2008 (Ent.), now I want to configure WD Sentinel DX4000 Network Storage Server with Backup Exec, but unbale to configure with following error message.
I already provide all permissions to destination folder, but still facing above mentioned error.
Please provide me solution.
I was faced with the same "..does not have read and write permissons" error last week.
We are using a NAS and two shares on it \\ip.ad.dr.ess\Full and \\...\Incremental.
Jobs were failing trying to write to these shares after working for months.
The steps I took to resolve this were:
rdp onto BEX media server.
If ping ok, from command prompt:
"runas /user:YourDomain\YourBexServiceAccount cmd"
Enter pwd for your BexServiceAccount
Fires up command prompt running under the BEX service account credentials.
Gives drive letter on share, and confirms credentials work
"copy con atest.txt"
type some text then ctrl+z
If your credentials are correct, it should write the atest.txt file to the NAS share and confirm the account does in fact have valid permissions.
If this works, then from the BEX media server, go to Windows explorer and browse \\ip.ad.dr.ess\Full
Right click Backup, Security Tab, check YourDomain\YourBexServiceAccount is listed here.
If not, add it with full rights.
Do this on all shares on the NAS that BEX will use.
Go back to BEX app (v12 in my case)
Try adding the storage again.
In my case, I created a third "Stub" share folder on the NAS's web config page. I was then able to add this share as \\ip.ad.dr.ess\Stub to the Storage devices in BEX.
I took the the two \\\\ip.ad.dr.ess\Full and \\...\Incremental shares OFFLINE in storage and pointed the jobs at the Stub share.
I deleted them (the two problem shares) from storage in BEX
I then went into the two \\\\ip.ad.dr.ess\Full and \\...\Incremental shares via the windows explorer on the BEX media server.
I renamed the folder.cfg and changer.cfg files in each of these to .cfg.original
I re-added the two \\\\ip.ad.dr.ess\Full and \\...\Incremental shares
I re-inventory & Cataloged the two "New" shares.
I believe this recreates the folder.cfg and changer.cfg properly which I assume had become bad.
Jobs then ran correctly to the shares as before.
I have also found, in the month that I been playing with BEX, that when the NAS gets low on storage (<10% free) these cryptic errors manifest more frequently.
Hope this is of use to someone following the same path.