I want to connect a remote Raspberry Pi to my local home NAS in order to use it as a backup location for the Pi.
I exported the share on my NAS and when I try to mount it on the Raspberry I get the errors:
trying 10.241.38.54 prog 100003 vers 3 prot TCP port 2049
│ mount.nfs: portmap query failed: RPC: Remote system error - Connection refused
Connection timed out
│ mount.nfs: timeout set for Tue Oct 24 21:47:42 2023
│ mount.nfs: trying text-based options 'port=2049,vers=4.2,addr=10.241.38.54,clientaddr=10.241.195.144'
│ mount.nfs: trying text-based options 'port=2049,addr=10.241.38.54'
│ mount.nfs: prog 100003, trying vers=3, prot=6
It’s interesting that ping works both ways and when setting up the network drive on the Raspberry Pi, it automatically recognizes the exported share and gives it as an option to select like this:
Can you connect to it via port 2049 on a common LAN? If not, it’s probably not a ZeroTier problem.
Another thing to consider is that some file sharing services are sensitive to latency, you might want to see if there are any ways to make NFS more tolerant of latency (and latency variation).
In my experience latency never causes an issue with file sharing access over ZeroTier unless my two clients are unable to form a direct connection and instead relay.
You can see if you’re relaying by checking the results of zerotier-cli peers.
Could that NAT documentation be amended to explain what matters? It’s all very well knowing “Independent Mapping, Independent Filter, preserves ports, no hairpin” but so what? Some notes on that page explaining what will and won’t work, would be useful.