Since you have confirmed NAS file access permission and encryption password is correct , I would suggest checking if the backup files are not corrupted or healthy first. You can use the Veeam Backup Extract Utility to verify the backup file integrity:

https://helpcenter.veeam.com/docs/backup/vsphere/extract_utility.html?ver=120

Additionally, ensure that the backup file you're trying to import was taken in a version lower than or equal to the current Veeam version you're using. Importing backup files from a higher version into a lower version isn't supported and could be causing the issue

Hi @armitage318,

I’m sorry to give conflicting advice to what @Mohamed Ali mentioned, but I would not use Validator/Extract utility here. The error stack is too vague at the moment, and it’s best you open a Support case and let Veeam Support review: https://veeam.com/kb1771

e25.09.2024 09:46:51.335] <14> Error          --tr:Failed to detect version of the storage e\\nas-xxx.domain.com\Veeam\serverD2020-10-04T082748_CB05.vbk].

This is just a “first-blush” review, but it sounds to me like Veeam still doesn’t get access to the file for some reason. Storage Version is part of the backup file metadata in the VBK/VIB file, and this is telling that we just were not able to read it. If it were damaged, I would expect a different error like “storage version N not supported” where N is either 0 or some weird larger number like 2134324 (just an example).

Since it looks like an SMB share, SMB can get very weird with the credentials -- ensure you’re using hostname\username if your share requires credentials, do not use .\username -- .\ passes the local machine as the workgroup/domain, it does not tell the server you’re logging into to use a local account.

If that doesn’t work, a Support case is best way to go.

Hi, thank you all for your answer.

I forgot to mention: if I copy the vbk locally on the Veeam server itself, restore works perfectly fine.

So I assume there is definitely something related to samba permissions/credentials.

Unfortunaltey I cannot open a ticket since I am using free edition

Hi Mohamed, yes I confirm that the backup I am trying to restore was taken with an older version of Veeam.

Thank you!

Free cases can be opened, but they’re on “best-effort” basis. But you can try and see if Support team has time to process it.

Based on your isolation test, I assume it’s the SMB permissions also, they can get really tricky. Did you check the username format btw? .\username is a real bugbear due to misconceptions about what .\ does being spread for so many years.

If you want to try to tackle it on your own, you need to check the agent.hsomething].log. To find the right log, use the following below. You’re looking for the session identifier here:

(db9320fe)

Example on how to find it below:

NOTE: In v12, the agent Session identifiers are now the first 8 characters instead of first 4. Same process applies, just the Agent Session Identifier in parentheses ( and ) is 8 characters.

c06.12.2020 23:29:12] <12> Info     Skipping deleted file blocks: source 'a666', message '21218983936:16777216'
606.12.2020 23:29:12] <63> Info                   �AP] (91ee) output: --asyncNtf:--fsaware_skip:21218983936:16777216
a06.12.2020 23:29:12] <31> Info                   AP] (a666) output: <VCPCommandResult result="false" exception="Read pointer for pre-read buffer (&apos;3326083072&apos exceeds the upper boundary of buffer (&apos;0&apos. --tr:Failed to extract next data block from pre-read buffer. Block ID: &apos;793&apos;. Standard block size: &apos;4194304&apos;. --tr:Next asynchronous read request cannot be processed. --tr:Asynchronous data reader has failed. --tr:Failed to process conveyored task. Failed to upload disk. --tr:Disk upload failed. Agent failed to process method {​​​DataTransfer.SyncDisk}​​​." />
s06.12.2020 23:29:12] <49> Info                   gAP] (a666) output: > �06.12.2020 23:29:12] <110> Error    Read pointer for pre-read buffer ('3326083072') exceeds the upper boundary of buffer ('0'). (Veeam.Backup.Common.CCppComponentException)

Part in yellow is the first four characters of a specific agent session ID. If you search this in the task log, you'll find where we start the agent session and the agent id:

i06.12.2020 23:29:04] <110> Info         ProxyAgent] Starting client agent session, id 'a666221e-1676-4264-92b3-88372ac87d2b', host 'some host', agent id '5c7705c0-ff59-43e0-8200-7926ca743e37', IPs 'some-ip:someport', PID '8756'

The one in green is your agent ID, and you'll search for it in the agent logs for the job on the host that is mentioned.

Hi, I found an alternative solution: I just noticed that if I try to import backup from File->File shares, the operation completes without errors

Previously I used Import backup → browse computer → point to \\hostname\share or \\192.168….\share (both not working)

Thank you!