NetApp NAS Filer SMB/CIFS File Backup Error on Non-Share SMB Repository

[KV14]

The posting below will discuss a bug I found when using a NetApp NAS Filer SMB/CIFS file backup to a non-shared SMB repository. I have submitted a case (Case# 04965857) to report the bug, but I wanted to post something on the forums if anyone else runs into a similar issue.

Software Build: 11.0.0.837

The Problem
A Veeam SMB repository with a UNC path navigating to a folder using a non-shared folder (ex: \\servername\e$\Veeam) with NetApp NAS Filer backup job will unexpectedly fail. No error message says the problem occurred because of a communication issue with the repository. The error logs will report an error code 59. Sometimes it will throw only “Error Code 59”, and sometimes it will say an “An unexpected network error occurred.Failed to get file attributes by handle. Error code: 59”. This error message is always tied back to the NetApp snapshot source SMB path and not the repository path.

The Workaround
To eliminate the SMB repository being a possible issue, I created a second disk on my Veeam VM off the NetApp to use as a backup repository. Once I switched the jobs repository from the SMB to the local host disks, the NetApp SMB/CIFS share backed up completely fine. Next, I created a shared folder on the same disks as the “non-share” folder repository and tested a Nas Filer backup. The test folder being shared allowed the entire backup to be complete without any error. Also, I experimented with setting up a Windows NFS server share on the same repository disk that failed with the non-shared UNC path to validate that it had no errors and successfully backed up. The problem looks to be directly related to a non-shared SMB path as a repository. Replacing the non-shared SMB repository with one of the other options listed above will resolve the issue.

Note1: This issue occurred when adding the backup job through the NAS Filers option or SMB path to the NetApp.

Note2: Non-shared SMB repositories have been what I have been using for years to backup all my VMware and Windows Failover Clustering virtual machines. I have never experienced any issues using this repository path on these backups. All Windows SMB sourced share folders backup without any problems to the non-shared SMB repository. For whatever reason, some code in the “File Backup” section of Veeam has an issue with this type of SMB path repository while backing up NetApp SMB/CIFS shares. This same non-shared SMB repository has no problems backing up NetApp NFS volumes.

Note3: While digging through the logs related to this issue, I came across a few logs that found "Unhandled exceptions". These unhandled expectation messages could be associated with the non-shared UNC repository.

[jess.fuquay]

Thank you Kyleer!

[Andreas Neufert]

Hi Kyleer,

thanks for reporting this.
Can you please clarify some things for me.

Is
\\servername\e$\Veeam
used as backup target for VMware and our NAS backup?
Only NAS backup has the issue that you have reported when this share is used as SMB Repository?

Do you use the latest patch as well? veeam-backup-replication-f2/current-version-t9456.html

[KV14]

Andreas,

The answer is yes to all three of your questions.

\\servername\e$\Veeam is the same backup target I used for VMware, NetApp NFS backups, and Windows File server clustering backups. All three of those worked fine with the "\\servername\e$\Veeam" SMB repository. Backing up an SMB share directly off a server (ex: Microsoft OneDrive) works fine with the "\\servername\e$\Veeam" SMB repository. From what I can tell, the issue seems isolated to at least the NetApp on SMB file backups.

[KV14]

Andreas,

One more thing on my previous comment "Backing up an SMB share directly off a server (ex: Microsoft OneDrive) works fine with the "\\servername\e$\Veeam" SMB repository". This works 90% of the time. I looked into my alerts, and the job failed a few times over the weekend with similar error output. The issue may be both NetApp and regular SMB file backups to a repository with "\\servername\e$\Veeam". My backup of my "OneDrive" is not that large, so it may not be enough files to trigger the issue every time.

[Andreas Neufert]

I would say it is unusual that there is any difference between a e$ share and and any regular share. In the end it is the same export. Maybe there is a specific rights/ACL issue but I think the issue is on something else.

The error 59 is a bit of a generic windows issue that we get reported by the gateway servers windows SMB client.
See here: https://www.veeam.com/kb1735

You opened the support case with eval support, can you please open a new ticket with the correct license support identifier? Or PN me it.

[KV14]

Andreas,

I will PM you.

[Dima P.]

Hi Kyleer,

\\servername\e$\Veeam is the same backup target I used for VMware, NetApp NFS backups, and Windows File server clustering backups.

Mind me asking is there any reason why you used admin share as a target? Thank you!

[Dima P.]

Kyleer,

I've asked support team to re-open your case. Please share full set of debug logs and we can pass those to QA team for the investigation. Thank you in advance!

[Dima P.]

Hello Kyleer,

We understand that the issue is now fixed on your end, so will close the support case and continue the investigation on the QA side. Thanks for your help!