• State Verified Answer
  • Replies 5 replies
  • Subscribers 18 subscribers
  • Views 4736 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 3 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]

  • 0 over 3 years ago

    Good day, Christophe.

    Are you performing backups with virtual appliances or directly with the vRanger server, and their versions?
    To back up remote servers, I recommend two things: have a repository residing in that site and a virtual appliance to process the backup over there and avoid transferring the data through your VPN.
    The vRanger server still needs to communicate with your Host and Repository, plus the virtual appliance. vRanger will be in charge of the management (job configuration, schedules, retention policies), while the virtual appliance will process the VMs' data and transfer it to the repository directly. So it is important that the virtual appliance can also reach the repository.
    If these settings are already configured, please try stopping the firewall in your server with the repository to test. Also, try logging into the virtual appliance and perform network tests to confirm if it can reach the repository.
    The list of port requirements can be found here. 
    https://support.quest.com/technical-documents/vranger/7.8/installationupgrade-guide/13#TOPIC-1272063

    Kind regards.
     

  • +1 over 3 years ago in reply to Miguel.Cespedes

    Hello Miguel

    I have all the firewalls turned off on the remote site.
    All ports are open between the two sites. No port filtering
    Impossible to install a virtual appliance on the remote site because I have no Vmware server compatible with Vranger on this site. I have a Vmware ESXi 5.5 on the remote site. But I don't plan to backup the servers on it. Only the physical servers will be backed up (5 of them)

  • 0 over 3 years ago in reply to christophe laporte

    Hello Christophe,

    Thank you very much for the feedback.

    Correct, if the servers to be protected are physical machines, we will not use virtual appliances, the agents will send the information directly to the repository.
    In this case, I can recommend opening a ticket with support in order to have an engineer connect in a remote session with you.

    https://support.quest.com/contact-support

    Kind regards.

  • 0 over 2 years 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.