Hi @netw0rkn1nja -

Welcome to the Community Hub! I don’t have experience personally on the subject, but I would think you could use a local admin account from the domain server you’re restoring to and it would work, or at the very least a domain admin account of the domain the server you’re restoring to is a part of? Does either of these acct types not work? 

If I could specify the account used that would likely solve the problem… unfortunately, when I open my files backup and go through the restore process there is no account selection. It’s seemingly using the same account I launched the console with (in this case one of the workgroup accounts). 

Do you mean a simple File Level Restore?
Because FLR has the option “Copy to” and you should be able to use network path like this:

 

If DNS don’t work you can always use IP.
Or use a network map drive and restore to there?

 

yeh, you can choose an account, but if you map a network drive inside the server you are open the File Level Restore you can select an account to log in to the network drive.
Maybe this can help.

So, are you getting the Backup Browser window open at least? I’m trying to think about Windows here...but I do know with Linux I, at times, get prompted for credentials of the Linux server I want to restore files to, as stated from the Guide. In reviewing the Backup Browser restoring Windows files, in item #5, it does state you are prompted for credentials under the Copy Files or Folders to Console or Shared Folder section.

You’re not getting prompted though?

@wesmrt - the mounting of the share and attempting the restore from “Backup Browser” did not work. Error message states “Restore root object does not exist.” 

@coolsport00 - I do get the Backup Browser window to open. I can even navigate throughout the share should I want to copy it to a different location within the share. But when I go to copy the data using Copy To or the Restore option I get an error “Unable to restore \\?\UNC\servername\share\foldername\filename.txt: access is denied”. Not once does it prompt me. 

@netw0rkn1nja - because you’re restoring to domain from a workgroup, I think the option you choose is Copy To. Can you put in the server IP in the path of the destination you’re attempting to restore to, for ex.?
\\192.168.2.123\share\folder-location

If this works, you may need to add the destination server in your local hosts file.

@coolsport00 it’s not a DNS issue.. Within the console I can open Files and brows the folder structure of my SMB shares. Then when in Backup Browser I can again browse through the folder structure but when it comes time to Copy To the error are as stated above (Same errors when choosing the open to Restore\Keep files). The only time I have any success is when writing to a directory my workgroup account has access to. 

The only other possible solution I can think of would be to try using/adding the “administrator” (local on both sides) and hope the services would default to their COMPUTER\administrator account. This would require some symmetry with passwords though so not exactly a fan of this possible approach. 

Hmmm..ok.

I was going to suggest the local account approach as well, but then the DNS idea popped in my head. 

Also, the Backup Browser is separate. You can browse the directory structure there because it’s the backup you’ve chosen mounted to the local computer you’re running the Veeam Console from. It isn’t browsing the network. You’re browsing the backup file 

I'm out of ideas, other than what I've already shared. I recommend getting ahold of Support to see if they can resolve it for you. 

As I suggested in the other thread - copy the file locally to the Veeam server then try copying it over to the domain server.  This should work as well.

This looks like a permission issue, but I am not sure what the accounts you are using to backup / restore.

What type of backups are you using?

If the backup is a regular VM backup, restore it back to the host. It doesn’t need to access a network share at all.

If it’s a file backup to object or tape, you will need proper permissions for the backup and restore.

I have my Veeam proxies and repost totally isolated, and am not domain joined as well like yourself.

For regular VM backups, Create a service account and give it the appropriate permissions on the file server.  When doing a File Level Restore from Veeam for FILESERVER1, you just restore it back to FILESERVER1. There is no need to restore to a share. 

For a restore to a share or DFS, you still need the appropriate permissions from the account logged into the Veeam server.  Logging in as a local account wont have work as it’s not domain joined.

Map a drive on the proxy to the share and choose Connect using different credentials. Use a domain joined service account that has access to that share/folder, and restore it like this. 

When you restore, select the proxy as the location, and then use the mapped drive to restore the files to. 

Another option if your security team allows it would be something like PSexec to create a persistent mapping to a DFS root folder on your proxy server.  When you do file level backups, the hierarchical folder structure remains, and you would just restore back to the same DFS location keeping everything the same. For NASBackup and File to Tape jobs this is amazing after a file share or server get migrated.

Here is how to use PSexec to map a persistent share.

Download sysinternals tools from http://technet.microsoft.com/en-us/sysinternals/bb897553
 

Create an elevated shell by running cmd.exe as Administrator

Within that shell, call

psexec -i -s net use s: \\server\share /persistent:yes

Browsing the folders and writing to them are different. Perhaps you have Read Only permissions to allow backups but no deletions? Overwriting needs the ability to modify and potentially delete files/folders. I forget off the top of my head.  Check other things like inheritance and if there are locked files. Something is stopping you, but I don’t believe this is a Veeam issue. 

@Scott the backup type is File Backup from a non-traditional share (in the sense that it’s not hosted on a Windows Server but off our EMC Unity). Prior to moving Veeam infrastructure components off the domain we used the same privileged accounts across Veeam and the share, resulting in successful restores to the original file share. 

The Copy To option works for if we’re restoring a small number of files but in the event of a larger incident (say total file share rebuild) this could pose a problem. I’ll try the mapped drive suggestion again and triple check the account I’m mounting the share with but previously it gave an error “Restore room object doesn’t exist..” or something along those lines.

We’d likely only encounter an “issue” when there was a large sum of data to be restored. Obviously the more we have to move the files around from server to server the longer the process and less chance of meeting our RTO. Other than that it’s merely an inconvenience at the moment. 

Thanks for the feedback.

That makes sense. The mapped drive method has been working for me, and it’s nice when you can restore to the right location. Using DFS, when we replace a server lets call it FS1, with FS2 I don’t want to have 2 locations showing for the same folder. 

I have all windows infrastructure currently though so our permissions will be different. 

Either way, I’m sure you’ll figure it out. Being off the production domain is a step forward in the right direction. 

Hi @netw0rkn1nja ,

As @Scott said permissions are the issue. You must investigate on share read/write inheritance.

Hi @netw0rkn1nja : the setup is correct putting the Veeam in a workgroup - out of your production environment. This is recommended in smaller to medium environments, only in the large environments a seperate management domain is recommended when a lot of people must have access to the management environment.

As other people already mentioned : permissions wil probably be the issue.

Also checked the firewalls between? I don’t know if there is VLAN segmentation being active.

Hi,

had the situation.

Added just the domain (w/o a host) and a username / password to the

Credential Manager (Windows section) within the control panel of the “sending” aka restoring management veeam.

replacing file(s), create copy from a FLR directly worked.

Cheers

Great to hear you were able to figure out a solution.