- Veeam Support Knowledge Base
- The specified network name is no longer available
The specified network name is no longer available
Cheers for trusting us with the spot in your mailbox!
Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Challenge
When accessing backup files on a CIFS (SMB) repository, Veeam Backup & Replication reports either of the following errors:
The specified network name is no longer available. (code 59, 0x8007003B)
An unexpected network error occurred. (code 64, 0x80070040)
Veeam Backup & Replication uses SMB connections for backup repositories, guest processing, and when first adding a Windows server to the Backup Infrastructure. This KB only addresses error messages that occur in the context of a backup file path, such as:
The specified network name is no longer available. Failed to read data from the file [\\10.0.0.81\backups\SQL VM New\SQL VM New2015-09-23T200441.vbk].
Note: If the failure is occurring in a tape job and no UNC path is specified in the error message, please contact Veeam Support.
Cause
Consider the following:
- Network issues are the most common cause, constituting a potentially unlimited variety of hardware failures or network hardware configuration problems; such issues may or may not involve packet loss.
- Simple firewalls may block a connection consistently, while advanced firewalls might destroy an existing connection seemingly at random or under particular conditions.
- Either the client or server might close the connection due to one of a number of timeouts or retry limits either at the SMB protocol layer or the underlying TCP layer; such limitations are often encountered due to network congestion or excessive load on the storage.
- The NAS may stop responding entirely due to hardware or software issues; it may, in some cases, be misconfigured. Appliances using post-process deduplication may stop responding if the process starts prematurely.
- In specific circumstances, various Group Policy Object (GPO) security policies might limit the connection. For example, the Microsoft network client policy: "Digitally sign communications" should be ensured that both source and target hosts can communicate using this policy. If not, consider disabling this policy in the event of any network failures.
- Moreover, enabling more Quality of Service (QoS) policies on SMB clients or targets can create unreasonably low bandwidth.
Solution
Common Workarounds
- If the SMB share is located on a Windows machine, try creating a Windows repository using that machine instead of a CIFS (SMB) repository.
- Reboot both the SMB client machine (repository gateway) and the SMB server (NAS).
- If other storage is available, try writing the backup to the other storage to verify the problem and as a temporary workaround.
- If a NAS provides the SMB share, consider configuring NFS and connecting to the storage as an NFS repository.
- Writing backup files to SMB shares over a slow or unreliable network, such as a WAN connection, is not recommended. Deploy a gateway server with a fast (Ethernet 100Mbps+) connection to the share.
- To rule out interference from a firewall, temporarily disable any software firewalls (including certain antivirus products) on the SMB client or server and any hardware firewalls between them. Some firewalls having intrusion protection or deep packet inspection may interfere with connections due to errant detections of data blocks that match heuristic policies within the backup data stream.
Optimized Registry Settings
These registry values must be created on the SMB gateway, specified in the repository settings as the Gateway server. For short-term testing, it is advisable to manually assign a single machine as the gateway and make modifications to that machine. When the gateway is set to “automatic,” these registry values would have to be added to all Windows machines managed by Veeam Backup & Replication, as any of them could be selected to act as the gateway.
Veeam Backup & Replication Registry Value
NetUseShareAccess
The following registry value controls whether the Veeam Data Movers will access backup files using a method similar to the Windows net use command.
Key Location: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
Value Name: NetUseShareAccess
Value Type: DWORD (32-Bit) Value
Value Data: 1 (1 = enable net use / 0 (default) = disable net use)
Note: When NetUseShareAcces is enabled, if credentials are required to connect the SMB share, they must be specified as Domain\User or Host\User in the repository settings. .\User credentials are not supported with NetUseShareAccess.
For example, specify “NAS-01\Admin” instead of “.\Admin”.
Windows OS-Level Registry Values
SessTimeout
This increases the amount of time the Windows SMB client will wait for a response from an SMB server before it aborts the connection. The default timeout is one minute.
Note: Reboot Required
Key Location: HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\
Value Name: SessTimeout
Value Type: DWORD (32-Bit) Value
Value Data: 600
Note:This is a value in seconds. Try a value of 600 decimal (10 minutes).
TcpMaxDataRetransmissions
This increases the number of times the Windows TCP implementation will retransmit a data segment before it aborts the connection.
Note: Reboot Required
Key Location: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
Value Name: TcpMaxDataRetransmissions
Value Type: DWORD (32-Bit) Value
Value Data(Dec): 10 (Default: 5)
Additional Troubleshooting
- Open the repository settings and enable Limit combined data rate. If you can measure the existing data rate, start with a limit between 50% and 70% of that value to verify that reducing throughput prevents the error. If the network is still congested after limiting the repository data rate, and the source of the congestion is due to other Veeam processes, enable throttling for the relevant connections.
- Change the gateway server in the repository settings to test whether particular routes to the share perform better than others. For example, if connections from any Windows server on a particular ESXi host tends to fail, but connections from a physical Windows machine do not fail, the root cause probably involves that ESXi host or its network connection.
- If the SMB connection consistently fails after 10 hours, it may be due to the expiration of a Kerberos service ticket. The most reliable workaround is to create non-domain credentials on the NAS, then specify those credentials in the repository settings. For more information and other possible workarounds, see this SAMBA mailing list discussion and the Authentication Expiration Timer heading in this MSDN blog post.
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
Spelling error in text
Thank you!
Your feedback has been received and will be reviewed.
Oops! Something went wrong.
Please try again later.
You have selected too large block!
Please try select less.
KB Feedback/Suggestion
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Thank you!
Your feedback has been received and will be reviewed.