cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot create Backup-To-Disk device on NAS due to authentication problem

geva
Level 3
Hi all:

I've got a beautiful little D-Link NAS with built in RAID, and I'm trying to get BackupExec (12) to back up to it.

When I try to create the B2D device, I can see the NAS, it's shares, and browse into it to select the UNC path.  I have also setup a user in BE that is the username and password to access this share.  When I click finish however, it gives me an error saying that it could not create the device.  Further investigation (the Event Log) logs an error CreateFile() CreatFolder().

I found the B2DTest tool online, and used that to try to test the NAS for problems/compatibility.  This tool asks for username to use to connect to the UNC path, however when you do not provide it with a context like a domain name or computer name, it seems to use .\ instead.  So, if you entered domain\username, the tool uses that to try to connect.  If you enter only say admin, it tries to authenticate using .\admin.

I've checked with basic drive mapping, and it seems to me that this .\ context is what is causing the Backup To Disk creation to fail.  When I NET USE with just the username, no problem, it just works.  However if I try to attach to the .\username, it fails, stating that the context is unknown.

Does anyone have any experience with this or have any expertise to provide?

Cheers,

Greg
1 ACCEPTED SOLUTION

Accepted Solutions

geva
Level 3
Hi Ken & sazz,

I had created account on the NAS with the same username and password as is being used by the BESA.

The NAS is definitely NOT on the domain.  I have since put it on the workgroup of the same name as the domain however.

After a lot of testing and fiddling around, the problem seems to come from the D-Link NAS.  As the BESA is an admin account, I set a strong password for it.  Although the D-Link NAS accepts the same password when creating the user (there is no MAXSIZE in the password field, and no error returned), it seems that there is a maximum length for passwords used.  This was causing the passwords for the domain BESA account and the NAS user to be different.

Shortening the passwords on both accounts solved the problem and I am now able to setup a B2D.  I will pursue D-Link regarding the maximum password length problem and then try getting BE setup again.

Cheers,

Greg

View solution in original post

3 REPLIES 3

Ken_Putnam
Level 6
If the NAS is not a member "server" of the Domain, you need to create a local user-id with the same name and password as the Domain BESA  (BackupExec Service Account)

in any case, the account that BackupExec uses to connect to the NAS must have full rights.

sksujeet
Level 6
Partner Accredited Certified
Try the below steps if your D link is in Domain:

1>Make sure you create the same account in the D link under which your backup exec services started.
2>Make sure you have a system logon account configured in the backup exec

If your D link is not in domain

1>Then in the backup exec create the local account for the  D link by going to network - logon account
2>Add this account in the local admin group

geva
Level 3
Hi Ken & sazz,

I had created account on the NAS with the same username and password as is being used by the BESA.

The NAS is definitely NOT on the domain.  I have since put it on the workgroup of the same name as the domain however.

After a lot of testing and fiddling around, the problem seems to come from the D-Link NAS.  As the BESA is an admin account, I set a strong password for it.  Although the D-Link NAS accepts the same password when creating the user (there is no MAXSIZE in the password field, and no error returned), it seems that there is a maximum length for passwords used.  This was causing the passwords for the domain BESA account and the NAS user to be different.

Shortening the passwords on both accounts solved the problem and I am now able to setup a B2D.  I will pursue D-Link regarding the maximum password length problem and then try getting BE setup again.

Cheers,

Greg