• State Verified Answer
  • Replies 5 replies
  • Subscribers 18 subscribers
  • Views 3887 views
  • Users 0 members are here
Options
Related

Erreur : 2034 - FATAL cifs_cant_use_detail CIFS cannot connect to share \\192.168.2.4\.... (Le chemin réseau n’a pas été trouvé.) [at cifs_mount:139]

christophe laporte
over 2 years ago

Hello

Vranger can't connect to the CIFS, that I created. I took back the doc, add the LAN authentication in NTLM2 on the server, put the destination directory in NTLM2 for the authentication, I browse the directory.

The destination disk is local on a windows 2019 server (I have the same problem with Freenas and CIFS)
I created a directory which is shared with total control for all the world
I access from another machine to this directory \192.168.2.4\...
The server is in workgroup
I use a host file for name resolution.

It must back up remote servers of a domain. IPSEC VPN connection site to site.

The task runs and takes less than 1mn *

Error: 2034 - FATAL cifs_cant_use_detail CIFS cannot connect to share \192.168.2.4\... (The network path was not found.) [at cifs_mount:139]

Parents
  • 0 over 1 year ago in reply to miranda mira2807

    Hello Miranda.
    Usually the vRanger server itself has access to the repository, which is validated when the backup task starts, but then one of the components involved in the backup might not be able to reach the repository or is losing connection. For example if you use an agent for physical servers, they must be able to access the repository, the same happens with Hyper-V hosts since they send the processed backup directly to the repository. Or if you have VMware virtual appliances (the Linux proxies), they also need to connect with the repository. 
    Some more specific scenarios could also be appearing, for example let's say that you protect a remote site, you need to have a repository over there because if you transfer the processed backups through the WAN, they might lose connectivity. I have also seen repositories directly connected to the vRanger server by iSCSI, the name resolution sometimes replies with the second NIC's IP instead of the primary's NIC's, causing some backups to fail and others to complete successfully.   

Reply
  • 0 over 1 year ago in reply to miranda mira2807

    Hello Miranda.
    Usually the vRanger server itself has access to the repository, which is validated when the backup task starts, but then one of the components involved in the backup might not be able to reach the repository or is losing connection. For example if you use an agent for physical servers, they must be able to access the repository, the same happens with Hyper-V hosts since they send the processed backup directly to the repository. Or if you have VMware virtual appliances (the Linux proxies), they also need to connect with the repository. 
    Some more specific scenarios could also be appearing, for example let's say that you protect a remote site, you need to have a repository over there because if you transfer the processed backups through the WAN, they might lose connectivity. I have also seen repositories directly connected to the vRanger server by iSCSI, the name resolution sometimes replies with the second NIC's IP instead of the primary's NIC's, causing some backups to fail and others to complete successfully.   

Children
No Data