NAS backup job gets wrong numbers from NAS, Files view works

[DanielJ]

I have an interesting/frustrating case going on with support (ticket 07619437). It involves a Huawei OceanStor 2200 V3 NAS which a customer wants us to back up (as a simple SMB share). When starting the backup job, it soon fails with complaints about "license exceeded" or that there was an "unhandled exception during licensing process". This is VBR's reaction to the insane file size numbers it gets from the NAS, which can be several exabytes for a file that in reality is 12 GB. I have used Wireshark to verify what happens, and so far we know this:

- The customer has never had a problem with using the NAS.
- SMB v2 is used in all the communication we have done with the NAS.
- When I connect to the share we are trying to back up using Explorer from the VBR server, it works fine and I can copy files from it. SMB responses are normal.
- When I connect to the share using VBR's Files view, it also works fine and I can copy files from it. SMB responses are normal.
- When I try to back up the share with a NAS backup job, the SMB responses contain crazy numbers and the job fails.

So it would seem that VBR does something different to connect to the share when doing it from a job, compared to when doing it from the Files view, or compared to how Explorer connects to the share. We haven't got any farther than that. Support has given me the ObjStgUtils utility, first to enumerate the share with EnumShare and generate a log file. No log file is created however we try, even though the share gets enumerated correctly without anything strange happening. Then I was to dump the share with DumpShare, but the utility just fails with "invalid unordered_map<K, T> key" even though writing the command exactly as instructed. Now we are down to the level of "maybe you forgot to write a space between the parameters". No, I didn't.

Is there anything that can be done to move this forward? I think it could be interesting for R&D to take a look at. There are Wireshark logs attached to the ticket.

[DanielJ]

Let me add an interesting tidbit: the wrongly reported file size for one of the files is exactly 2^24 - 1 TB. But maybe that doesn't mean anything else than that some field used by the NAS is 24 bits and can't contain a larger number.

[DanielJ]

I'm sorry to say that this, in the end, went nowhere even with attention from R&D (and lots, lots, lots of logs sent). Something makes the NAS return bad metadata. Always when VBR runs a job, sometimes when using the Files view, but never when running robocopy or using the NAS normally. It's hard to avoid the conclusion that there is something that VBR could do differently that would make it possible to back up this NAS. But instead I am left with having to ask the customer to open a ticket with the vendor of a NAS they so far have had no problems with. They will likely just choose some other backup solution.