NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Unable to access remote path
I've been running a backup job between my NV+ and my Win8.1 PC without problem. It ran successfully as recently as yesterday.
Today, I started getting "Unable to access remote path" on all backup jobs to that PC. The "Test Connection" button yields "Error Connecting" (it used to work). This happens on all backup jobs to this specific PC. Backup jobs to other PCs appear to still be working (though I haven't tested them all).
I've changed nothing on the system that I know of. And I've validated that the account the backup job uses can still be logged into on the PC itself. And I've validated that the shares on that PC are still accessible from other PCs on the network.
What is the best way to diagnose the problem? I can ssh into the NAS, but have no idea what to look at or try.
Note: I'm running 4.1.13
Today, I started getting "Unable to access remote path" on all backup jobs to that PC. The "Test Connection" button yields "Error Connecting" (it used to work). This happens on all backup jobs to this specific PC. Backup jobs to other PCs appear to still be working (though I haven't tested them all).
I've changed nothing on the system that I know of. And I've validated that the account the backup job uses can still be logged into on the PC itself. And I've validated that the shares on that PC are still accessible from other PCs on the network.
What is the best way to diagnose the problem? I can ssh into the NAS, but have no idea what to look at or try.
Note: I'm running 4.1.13
2 Replies
Replies have been turned off for this discussion
- On a whim (or by desperation), I ssh-ed into my NAS and tried a simple ping. Ping is resolving to the wrong IP address. The correct IP is 192.168.1.70, but it's resolving to 192.168.1.102. If I replace the hostname in the backup form with the IP address, it works.
I has this same issue just a week or so ago (viewtopic.php?f=31&t=74353). I thought this was caused by me changing the router on my system temporarily, and the problem resolved itself without me doing anything after 24+ hours. But now it's happening again. ??
As per the advice on that other thread, I tried "arp -a" with the following results:
turks:/usr/bin# arp -a
StThomas (192.168.1.102) at <incomplete> on eth0
www.asusnetwork.net (192.168.1.1) at 08:60:6E:CB:77:C8 [ether] on eth0
? (192.168.1.108) at <incomplete> on eth0
? (192.168.1.70) at 30:F9:ED:43:8F:27 [ether] on eth0
Notes:
* "turks" is my NV+
* "StThomas" is my PC. It's actual IP address is 192.168.1.70 -- not 192.168.1.102
* I see both of these address listed in the arp -a output, with .102 showing as "StThomas", and .70 showing as "?"
* Hardware topology-wise, both the NAS and StThomas are connected directly to my router via Ethernet. The other systems, which are working fine, are connected via Wifi.
I've then issued "arp -d 192.168.1.102, and it completes without output.
Attempting another ping still resolves to 192.168.1.102.
For completeness, here's a copy/paste of the output from the following commands
* arp -a
* ping
* arp -d
* arp -a
* ping
turks:/usr/bin# arp -a
StThomas (192.168.1.102) at <incomplete> on eth0
www.asusnetwork.net (192.168.1.1) at 08:60:6E:CB:77:C8 [ether] on eth0
? (192.168.1.108) at <incomplete> on eth0
? (192.168.1.70) at 30:F9:ED:43:8F:27 [ether] on eth0
turks:/usr/bin# ping stthomas
PING stthomas (192.168.1.102) 56(84) bytes of data.
From turks (192.168.1.103) icmp_seq=1 Destination Host Unreachable
From turks (192.168.1.103) icmp_seq=2 Destination Host Unreachable
From turks (192.168.1.103) icmp_seq=3 Destination Host Unreachable
--- stthomas ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3012ms
, pipe 3
turks:/usr/bin# arp -d 192.168.1.102
turks:/usr/bin# arp -a
StThomas (192.168.1.102) at <incomplete> on eth0
www.asusnetwork.net (192.168.1.1) at 08:60:6E:CB:77:C8 [ether] on eth0
? (192.168.1.108) at <incomplete> on eth0
? (192.168.1.70) at 30:F9:ED:43:8F:27 [ether] on eth0
turks:/usr/bin# ping stthomas
PING stthomas (192.168.1.102) 56(84) bytes of data.
From turks (192.168.1.103) icmp_seq=1 Destination Host Unreachable
From turks (192.168.1.103) icmp_seq=2 Destination Host Unreachable
From turks (192.168.1.103) icmp_seq=3 Destination Host Unreachable
--- stthomas ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3012ms
, pipe 4
turks:/usr/bin# - I've discovered where the .102 address was coming from! Somehow, the wireless adapter on the PC (StThomas) got re-enabled -- perhaps when I upgraded to Win8.1 recently. This was associated with 192.168.1.102, while the Ethernet port was associated with 192.168.1.70. I've now disabled the wifi adapter, and the DHCP table on my router isn't showing that entry anymore.
However, the problem still persists, with backups failing, and ping resolving to the wrong address. And as per the log in my last post, "arp -d" doesn't appear to remove the routing information. I've tried "arp -d 192.168.1.102", "arp -d StThomas", and "arp -d STTHOMAS". But "arp -a" still shows the bad entry.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
