6.9.3 SMB Veeam backup, error "ReFs.SetFileIntegrity"

---

WingDog wrote:

how to downgrade SMB protocol level to SMB2 at 6.9.3 OS? 

---

You can install the SMB plus - that will let you downgrade the protocol level.

---

StephenB wrote:

---

WingDog wrote:

how to downgrade SMB protocol level to SMB2 at 6.9.3 OS? 

---

You can install the SMB plus - that will let you downgrade the protocol level.

---

It gave no result.

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.

---

mdgm-ntgr wrote:

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?

well, ok.

let it be Veeam's problem.

---

WingDog wrote:

---

mdgm-ntgr wrote:

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.

I got the same Problem in ReadyNas 214: Veeam and Readynas are up to date, Backups fail with ReFs.SetFileIntegrity-Error. I asked for Support at VEEAM but they werent able to fix it (registry entries as suggested in this thread https://forums.veeam.com/veeam-agent-for-windows-f33/invoke-failed-command-refs-setfileintegrity-t47004.html did fix the error for some, not for me)

BUT:

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).

I don't see how the RAID choice would affect this.

You might consider setting up a test share with default file permissions, and see it that works.

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.

That one seems to be Veeam - see this post: https://community.netgear.com/t5/Using-your-ReadyNAS/After-firmware-update-to-6-9-0-my-backup-software-can-t-work/m-p/1411924#M138284

They are supposed to have a fix for it.

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...

WingDog and DaPan

https://community.netgear.com/t5/Using-your-ReadyNAS/After-firmware-update-to-6-9-0-my-backup-software-can-t-work/td-p/1407628/page/3

The topic is a issue for Veeam angent for Windows, not Veeam backup & replication,

Did you add Linux server on Veeam backup & replication?

if you add Linux server, it will install veeam agent on NAS via SSH when adding server,

the veeam agent only can run on x86 NAS, can't run on ARM NAS.

so only X86 NAS can run backup on Veeam backup & replication.

I added a shared folder (CIFS/SMB) as the backup Repository, not Linux Server.

Ok, downgrading the Firmware did the trick. This is what i did:

- Restore Factory Defaults

- Skip the Wizard

- Download Firmware 6.8.1 for ARM here: https://kb.netgear.com/000048469/ReadyNAS-OS-6-Software-Version-6-8-1

- Manually Update Firmware via the Admin-Console, choose the downloaded file. An error message popped up but i guess it worked anyway.

- Log out

- Log in. A message popped up, that Firmware 6.8.1 will be installed after reboot. I klicked on reboot.

- The (old) firmware installed without any problem

- Created a share (same as before)

- Started a veeam-job an everything went fine. No errors.

I download the latest version of veeam backup & replication,

SMB backup is OK on RN214 (6.9.4 not release) and RN422 (6.9.3 and 6.9.4 not release)

Version is 9.5.0.1922, 

File Copy Job1: Backup a folder on D to a Share on RN214,

File Copy Job2: Backup a folder on D to a Share on RN422,

Please see below information.

it's fun enought.

it's good, very very good (an archivment for NTGR) that devices can handle regular SMB copy.

we are talking about backup job issue, but you are making smb copy test.

I have nothing more to say.

Sorry!

I installed a trial license, and create a share to do backup and reproduce the issue.

I will report to developter to check the issue.

---

WingDog wrote:
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.

---

Yes, they did, and one of their developers reported their findings here: https://community.netgear.com/t5/Using-your-ReadyNAS/After-firmware-update-to-6-9-0-my-backup-software-can-t-work/m-p/1411924#M138284

You've been pointed to that post before, but didn't like the answer (which is that it is a bug in Veeam's SMB implementation).  But they did investigate it.