Using SMB share as Backup Repository doesn't work anymore

[Stibo]

Hi folks,

as per my last topic we tried to configure VBO365 to backup the data to a SMB share. It worked yesterday with one test, today we're getting this error:

VEEAM BACKUP FOR MICROSOFT OFFICE 365
Failed to write to the specified folder: \\123.123.123.123\vbo_mail_01.
Validation failed.

'Get free space' works, as well as mapping the share as a network drive using the service account.

The target is a NetApp Filer providing a SMB share (version 3.0 - filer is Active Directory joined). What we've tried so far:

- Added the account to the local administrator group on the server running VBO365
- Added the service account to be used for connecting to the backup proxy (the server running VBO365)
- Set the Log On User for the VBo365 Service to said account (Computer Management - Services - Properties ...)
- Granted permissions on the share on the filer for the service account

When viewing the logs this is what we get:

27.02.2020 10:52:35 26 (6124) Error: Access to the path '\\123.123.123.123\vbo_mail_01\ar.tmp' is denied.
27.02.2020 10:52:35 26 (6124) Type: System.UnauthorizedAccessException
27.02.2020 10:52:35 26 (6124) Stack:
27.02.2020 10:52:35 26 (6124) at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
at Veeam.Archiver.Proxy.Engine.Validation.RepositoryPathValidator.TestAccess(String path, String tempFileName)

Any idea on what we do wrong? My next stept is to configure a second backup proxy and testing our procedure with this one.

[Polina]

Hi Stibo,

VBO computer account (not the service account) must have access to the share. Here's a KB which might be helpful for you https://www.veeam.com/kb2971

[Stibo]

Hello Polina,

thanks for sharing, I'll have a look into this. In the meantime we helped ourselves with the workaround to add "Everyone" as access permissions on the filer; so it was an access rights issue.
One more question if you don't mind: is there a calculator for calculating the necessary amount of backup proxys and backup accounts?

[Polina]

The key sizing and design considerations are presented in our best practices guide: https://vbo.veeambp.com/guide/design/sizing/

A single backup proxy generally can handle up to 4K users OR 16K objects (i.e. mailboxes, archives, sites, OneDrives). Another important consideration is the number of repository databases (.adb files) to keep on a proxy - with the default settings it's safe to stay within the 250 databases per proxy.

When adding auxiliary backup accounts, we suggest starting with 8 (per proxy that handles SPO/ODFB backup jobs) and add additional in batches of 8 if needed.

[kontakt@roc-k-it.com]

I learned that the respective NAS has to support SMB3: I activated SMB3 successfully via smb3enable on my QNAP-NAS.

Which permissions do I have to set on the respective folder on tha NAS? If I give full permission to guest (which I do not like in production) I can define a respective backup repository in Veeam Backup for Microsoft Office 365. Which specific user do I have do give which permission?

Many thanks again - Michael

[Mike Resseler]

Hi Michael,

To be able to use an SMB3 share, you need to give full rights to the computer account (your VBO services should run as localsystem)

Brgds,
Mike

[kontakt@roc-k-it.com]

Thanks! Has the NAS to be in a/the domain? Whatif I use a NAS in a non-Acrive-Drietory environmen?

Michael

[HannesK]

Hello,
the requirements are described in the user guide:

https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=40
https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=40

Best regards,
Hannes

[kontakt@roc-k-it.com]

Thanks again!

My problem seems to be with QNAP access permissions: I have to give full access rights to a Windows computer account (localsystem - see above) in a non-Active Directory environment. Until now it "only" works with fill permissions for guests (thus I am sure it is a problem with access permissions).

I'll try to clarify with QNAP support.

Michael

[HannesK]

Hello,
I don't believe that QNAP support can help with it. The requirement is:

A shared folder must be on a computer or device located within the same or a trusted domain.

Best regards,
Hannes

[kontakt@roc-k-it.com]

Thanks! That's what I "fear" - Then I have to live with full permissions for guests.

Michael

[CoRpO]

I've just found a nicer solution to this problem !

TR;DR :

Code: Select all

psexec -s cmdkey /add:DEVICE /user:DEVICE\USER /pass:PASSWORD

where USER is a local user on your NAS

Long version :
Veeam Proxy runs as system account, and then accesses the shares with this account.

• Veeams solution is to add the computer account to a group in your AD and then give permissions to this group on your nas to the backup share hosting the repository. Problem, you can't use that if you have no AD or if your veeam backup server is outside of your AD (best practice to protect yourself in case of AD compromission
• Other solution is to create a user on your device which matches a local user on your backup server and then change the veeam backup proxy service to run as that user. You may have to use mklink to point a local directory of your server to the share of your NAS, to avoid the error "SMB 3.0 required" (which in fact is an access denied error). Problem, the backup proxy is unable to use your paid licence and then it will only backup shared mailboxes as they are not consuming a licence

The solution is to save your NAS USER's credentials (using cmdkey) under the system account (using psexec) of your backup server. And then you can use whatever share you want using whatever user you want ! I tried everything else, nothing works.

Code: Select all

psexec -s cmdkey /add:DEVICE /user:DEVICE\USER /pass:PASSWORD

is the answer. Don't forget to include your NAS name before the login, to be sure to access the right directory on your device