SMB, FreeNAS and Veeam - Network Path Not Found

[junior466]

This may end up being a Veeam software discussion but since FreeNAS is being used I'd thought it be okay to post this here.

I am running a SMB repo for backing up two ESXi hosts through Veeam and noticed that sometimes I will get an error that hints at FreeNAS being the issue:

Code:

Error: The network path was not found. Failed to open storage for read/write access. Storage: [\\10.10.14.7\veeam\

The problem is the backup job will fail on the first and sometimes second try, but usually succeed on the third so it appears that FreeNAS is simply being slow to respond? Veeam is sitting on a Windows VM inside ESXi Host 1 with a direct connection to FreeNAS over 10gbe using DAC. Everything works fine otherwise. Here's iPerf from FreeNAS to the Windows VM hosting Veeam:

Code:

Client connecting to 10.10.14.128, TCP port 5001
TCP window size: 32.8 KByte (default)
------------------------------------------------------------
[  3] local 10.10.14.7 port 16382 connected with 10.10.14.128 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  10.2 GBytes  8.69 Gbits/sec

FreeNAS is version 11.1-U7 with 16GB of ram and two mirror vdevs for a pool.

Again, if the backup succeeds on the second try, doesn't it sound like SMB share is not responding on the first attempt? If so, what could be the reason?

If this is believed to be an issue with Veeam, I will gladly take this elsewhere.

Thank you.

 

[Yorick]

Check /var/db/system/cores and see whether smbd is coring on you when this happens. Long shot, and, that would fit the behavior.

 

[junior466]

Check /var/db/system/cores and see whether smbd is coring on you when this happens. Long shot, and, that would fit the behavior.

Currently there's no smbd.core. Only syslog-ng.core vmware-checkvm.core winbindd.core. Look for it when the backup job is running?

 

[Yorick]

You can ls -l and see whether any of those cores coincide with the time the backup job is running.

 

[junior466]

You can ls -l and see whether any of those cores coincide with the time the backup job is running.

None do.

Code:

-rw-------  1 root  wheel  12136448 Mar 21 12:20 syslog-ng.core
-rw-------  1 root  wheel   4894720 Dec 18 18:38 vmware-checkvm.core
-rw-------  1 root  wheel  52391936 Dec 17 02:37 winbindd.core