what's about other NASes, not NTRG? or Veeam selectively does not like NTGR?
In the previous case, Veeam didn't handle the FSCTL_DUPLICATE_EXTENTS_TO_FILE attribute in SMB correctly. As stated in the post I linked "This great new feature allows Windows to directly ask the NAS to clone a portion of an existing file, instantaneously and without consuming any extra space." Netgear didn't need to provide a way to disable the feature, because Veeam fixed it quickly.
This new issue of course might have a different cause, but it seems plausible that it is a simple regression (that Veean didn't roll the hotfix into their release cycle). Have you contacted them?
The problem would be at Veeam's end like with the earlier issue one would think, or as StephenB mentioned it could be a regression.
We're using samba, the open source project for Linux that provides a SMB service/client.
all other Linux-based NAS using samba, because there is no any other way to present SMB share.
I have Qnap, Synology, Dlink and even Thecus - all of them works with Veeam.
Even old RND with 4.x OS works, and RND 6.x.x prior to 6.9.x works. RND 6.9.3 with shares created at older FW like 6.8.x works, but native 6.9.3 created shares don't.
The problem would be at Veeam's end like with the earlier issue one would think, or as StephenB mentioned it could be a regression.
We're using samba, the open source project for Linux that provides a SMB service/client.
all other Linux-based NAS using samba, because there is no any other way to present SMB share.
I have Qnap, Synology, Dlink and even Thecus - all of them works with Veeam.
Even old RND with 4.x OS works, and RND 6.x.x prior to 6.9.x works. RND 6.9.3 with shares created at older FW like 6.8.x works, but native 6.9.3 created shares don't.
but problem with 6.9.3 is Veeam's end problem.
where is logic?
Did you actually read the original post? Netgear added a new capability (SMB attribute), which takes advantage of the CoW feature in the BTRFS file system. Veeam's software mistakenly assumed that particular attribute implied support for a second attribute, even though that second attribute wasn't signaled. So they tried to use that second attribute, and of course it failed.
In that particular case, it was clearly Veeam's error (for which they provided a hot fix), but it would only show up with an SMB server that only advertised the first attribute (and not the second one). That was uncommon (and perhaps unique to OS-6). Although unusual, it wasn't a ReadyNAS bug, because it was allowed in the SMB specifications.
You are assuming that because the problem only happens with the OS-6 Samba Server, that it must be an OS-6 bug. But the original case shows the flaw in that reasoning. After all, this problem also only happens with the Veeam - other clients work fine. So your same logic could point to Veeam instead (and in the case above, it was their problem). And there's a third possibility - which is that the cause is a combination of bugs in both devices.
Something like this usually requires both folks (Veeam and Netgear) to engage - which is a problem in your case since you apparently aren't entitled to contact Veeam support.
Backups are working on Readynas3138 (same Firmware 6.9.3) without any problem.
The only difference between those two is the Raid-System. Readynas3138(backup working) is Raid10, ReadyNas 214 (Backups failing) is default X-Raid. And the HDDs.
Before i reformat the NAS just for testing, has anybody run into the same problem or has another solution. The only solution so far for some users was to downgrade the Firmware, and i'm not sure if i could downgrade ReadyNas 214 (it shipped with 6.9.2).
Model: RN21400|ReadyNAS 214 Series 4-Bay (Diskless)
Hey thanks for the tip, unfortunately it didn't work:
I created a test share with default permissions and added the shared folder to a new job. I'm sorry, I still get the same error. Before it cancels the job, veeam creates a new vbk-File of ~30MB.
Alright, i guess ill take the risk to revert back to 6.8.1...i've already contacted VEEAM Support - we tried anthing and now they also suggest to downgrade the firmware...
After two months of friendly chit-chat I do have only one question to NTRG: Does yours QA team did something to investigate this issue? Maybe test lab or at-the-field research? Contacted Veeam? They have excellent QA team. Now you have two customers (ex as for me) faced this issue and still nothing.
