IDC Logo

Veeam #1 Worldwide in
Data Recovery & Protection in 2H'22


The specified network name is no longer available

KB ID: 1735
Product: Veeam Backup & Replication | 5.0 | 6.1 | 6.5 | 7.0 | 8.0 | 9.0 | 9.5 | 10 | 11
Published: 2013-02-22
Last Modified: 2022-04-22
Languages: IT | FR | ES
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.

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

error icon

Oops! Something went wrong.

Please try again later.


When accessing backup files on a CIFS (SMB) repository, Veeam Backup and 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 [\\\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.


These error messages are passed directly from Microsoft Windows. They indicate that some unknown problem led to a sudden failure of the connection between the repository gateway (acting as Server Message Block client) and the SMB server (typically a NAS appliance).

User-added image

There are many possible reasons the SMB connection might fail: 

  • Network issues are a 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 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 GPO security policies might limit the connection, for instance - Microsoft network client: Digitally sign communications. Make sure that source and target hosts can communicate using this policy. Otherwise, in case of any network failures, consider disabling this. More QoS policies can be enabled on SMB clients or targets, creating unreasonably low bandwidth.


Common Workarounds

  • If the repository share is located on a Windows server, try creating a Windows repository on that server 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.
  • Consider reconfiguring the NAS as iSCSI or an NFS mount on a separate Linux repository server, depending on what is supported by the NAS. This change may involve data loss. iSCSI usually offers the best performance.
  • 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.

Optimized Registry Settings

These registry values must be created on the SMB gateway, specified in the repository settings as the Gateway server. If the gateway is set to “automatic,” add these registry values to all Windows servers managed by Veeam Backup & Replication.

  • NetUseShareAccess
    For Veeam B&R or later, the following registry value allows Data Movers to open backup files by a resilient method similar to the Windows net use command.

    Key: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
    DWORD: NetUseShareAccess
    Value: 1

    Note: If credentials are required, specify 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”.
  • 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: HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\
    DWORD: SessTimeout
    Value: 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: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    DWORD: TcpMaxDataRetransmissions
    Value: 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 an ESXi host tend 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 submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.

Spelling error in text

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Thank you!

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

By submitting, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Verify your email to continue your product download
We've sent a verification code to:
  • Incorrect verification code. Please try again.
An email with a verification code was just sent to
Didn't receive the code? Click to resend in sec
Didn't receive the code? Click to resend
Thank you!

Thank you!

Your feedback has been received and will be reviewed.

error icon

Oops! Something went wrong.

Please try again later.