NFS Issue with New Router

I have been using haneWIN NFS Server on my Windows 7 PC for 2 years now, to stream videos to my 4 raspberry pi’s running OSMC (raspBMC prior to OSMC). The Pi’s all use wireless to connect to the network with static IPs. My Win 7 PC also has a static IP. My TP-Link Archer C9 router died last week, so I ordered a replacement TP-Link Archer C1900. I applied the exact same configuration to the router as before, however my Pi’s “hang” when attempting to connect to the NFS share. UPnP is enabled. Subnet is the same. Connectivity to the network verified and functional.

I have attempted removing the share from the saved locations on the Pi’s and re-adding, but “a connection to the server cannot be established.” I ended up setting SMB back up to get around the issue and continue streaming (children not being able to watch their videos makes for a bad time). SMB works fine, I just dislike the additional overhead on the network and it has to buffer frequently whereas NFS buffered at the beginning and would never pause while streaming after that.

I updated 2 of the Pi’s running older versions of OSMC with no change. My other 2 were up to date. No changes were made to my “server.” Below is an excerpt from grab-logs -C -A on one of my Pi’s while attempting to browse for NFS shares.
15:44:27.449 T:3026026496 NOTICE: WakeOnAccess [192.168.1.7] trigged by accessing : nfs://192.168.1.7/e/my videos/
15:44:27.576 T:3026026496 NOTICE: WakeOnAccess success exit, server already running
15:44:30.501 T:3026026496 ERROR: GetDirectory - Error getting nfs://192.168.1.7/e/my videos/
15:44:30.517 T:3026026496 ERROR: CGUIMediaWindow::GetDirectory(nfs://192.168.1.7/e/my videos/) failed

I also found this in the logs:
15:51:16.340 T:2797859824 NOTICE: WakeOnAccess [192.168.1.7] trigged by accessing : nfs://192.168.1.7/e/my videos/
15:51:16.560 T:2797859824 NOTICE: WakeOnAccess success exit, server already running
15:53:04.955 T:3026223104 NOTICE: Samba is idle. Closing the remaining connections
15:55:40.745 T:2797859824 ERROR: NFS: Failed to mount nfs share: (nfs_service failed)
15:55:40.746 T:2797859824 WARNING: Process directory ‘nfs://192.168.1.7/e/my videos/’ does not exist - skipping scan.

Again, nothing changed host or Pi side accept for the router, until I started troubleshooting. Even then, the host has remained untouched.

A special thanks to @try_OSMC for chiming in on twitter randomly, offering advice and recommending I post here.

So let’s start with some basic network stuff can you ping the PC ping 192.168.1.7?
Also provide ifconfig from OSMC and ipconfig /all from the PC

Also could it be a coincidence that you might besides the router change so received a new Windows update?

Would also be worth posting the output of sudo showmount -e 192.168.1.7 run on OSMC too. That will show if there are NFS shares visible outside of kodi. Can you also confirm if you are mounting the NFS shares using kodi or in /etc/fstab?

@fzinken Windows updates are disabled on the box. I’ve confirmed none forced through.

@yknivag I’ve only made NFS attempts via kodi.

osmc@office-pi:~$ ping 192.168.1.7
PING 192.168.1.7 (192.168.1.7): 56 data bytes
64 bytes from 192.168.1.7: seq=0 ttl=128 time=117.986 ms
64 bytes from 192.168.1.7: seq=1 ttl=128 time=1.524 ms
64 bytes from 192.168.1.7: seq=2 ttl=128 time=1.527 ms
64 bytes from 192.168.1.7: seq=3 ttl=128 time=1.435 ms
64 bytes from 192.168.1.7: seq=4 ttl=128 time=1.465 ms
^C
— 192.168.1.7 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.435/24.787/117.986 ms
osmc@office-pi:~$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:8936 errors:0 dropped:0 overruns:0 frame:0
TX packets:8936 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:2928370 (2.7 MiB) TX bytes:2928370 (2.7 MiB)

wlan0 Link encap:Ethernet HWaddr XXXXXXXXX
inet addr:192.168.1.113 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:1693853 errors:0 dropped:676 overruns:0 frame:0
TX packets:278262 errors:0 dropped:2 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:657593204 (627.1 MiB) TX bytes:63829304 (60.8 MiB)

osmc@office-pi:~$ sudo showmount -e 192.168.1.7
Export list for 192.168.1.7:
/c/ftp 192.168.1.1,192.168.1.10,-range
/c/tools 192.168.1.4,-readonly
/e/my videos -public
/e/my music -public

ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : Server
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Broadcom NetXtreme 57xx Gigabit
r
Physical Address. . . . . . . . . : xx-xx-xx-xx-xx
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.1.7(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled

This suggests that the Pi can see the shares (4 of them).

To test whether this is OSMC or kodi, you could try adding one to /etc/fstab

To do so run:

sudo mkdir /mnt/test
sudo nano /etc/fstab
Add the following line to the end:
192.168.1.7:/e/my\ videos /mnt/temp/ nfs _netdev,ro,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp 0 0
Ctrl+O then Ctrl+X to exit.
Then sudo mount /mnt/temp`

See if you can see the contents of the share in /mnt/temp

1 Like

This is where my linux skills lack…I corrected a few items, but I know I’m missing something simple here.
osmc@office-pi:/mnt$ sudo mount /mnt/test
mount: can’t find /mnt/test in /etc/fstab
osmc@office-pi:/mnt$ cat /etc/fstab
/dev/mmcblk0p1 /boot vfat defaults,noatime 0 0
/dev/mmcblk0p2 / ext4 defaults,noatime 0 0
192.168.1.7:/e/my videos /mnt/temp/ nfs_netdev,ro,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp 0 0
osmc@office-pi:/mnt$ pwd
/mnt
osmc@office-pi:/mnt$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Dec 19 11:12 .
drwxr-xr-x 23 root root 4096 Dec 16 15:06 …
drwxr-xr-x 2 root root 4096 Dec 19 11:12 temp
osmc@office-pi:/mnt$

It’s not really a Linux issue. There’s been a a bit of a mix-up in the name of your test mount point. You created a mount point called /mnt/test but the /etc/fstab entry is for /mnt/temp. Either create a new mount point or correct /etc/fstab.

As to the original problem, I have a feeling that this might be a UPnP-related issue. To confirm my hunch, you’d need to connect the Pi to the router by ethernet cable, disable WiFi, and see if the problem disappears.

Ok, ironed out the ID10T errors in my cli:

osmc@office-pi:/mnt$ cat /etc/fstab
/dev/mmcblk0p1 /boot vfat defaults,noatime 0 0
/dev/mmcblk0p2 / ext4 defaults,noatime 0 0
192.168.1.7:/e/my videos /mnt/temp/ nfs_netdev,ro,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp 0 0
osmc@office-pi:/mnt$ sudo mount /mnt/temp
mount: can’t find /mnt/temp in /etc/fstab
osmc@office-pi:/mnt$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Dec 19 11:12 .
drwxr-xr-x 23 root root 4096 Dec 16 15:06 …
drwxr-xr-x 2 root root 4096 Dec 19 11:12 temp
osmc@office-pi:/mnt$

You need to change the fstab entry to:

192.168.1.7:/e/my\040videos /mnt/temp/ nfs_netdev,ro,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp 0 0

ie change the space to \040.

I’m not sure about some of the options but leave them for now.

1 Like

@dillthedog good call. Different error now. I suspect this is UPnP blocking the mount.

osmc@office-pi:/mnt$ sudo mount /mnt/temp
mount: special device 192.168.1.7:/e/my videos does not exist
osmc@office-pi:/mnt$ cat /etc/fstab
/dev/mmcblk0p1 /boot vfat defaults,noatime 0 0
/dev/mmcblk0p2 / ext4 defaults,noatime 0 0
192.168.1.7:/e/my\040videos /mnt/temp/ nfs_netdev,ro,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp 0 0
osmc@office-pi:/mnt$

Well, my theory is that UPnP isn’t working correctly on your router.

You know how to test if my hunch is correct.

1 Like

Yep. Will run a cable and check then report back. Thanks for your help on this.

Any reason you force udp?

1 Like

Is this syntax correct? With that there is no file system type?!
Shouldn’t this be

192.168.1.7:/e/my\040videos /mnt/temp/ nfs _netdev,ro,intr,noatime,rsize=32768,wsize=32768,nolock,async,proto=udp 0 0

so there is a space between the type nfs and option _netdev.
Hope to not start any confusion with this this.

1 Like

The whole line is a bit broken. It was suggested back in post #5 but I wanted to concentrate on the UPnP issue before fixing the NFS line.

1 Like

Sorry that was my fault in the instructions I gave. Indeed if you make sure they are all /mnt/test or /mnt/temp then it should work.

It just needs a space between nfs and _netdev - it requires extra options to be workable long term but it exists purely to verify that the Windows NFS server and OSMC client can talk to each other.

1 Like

Yeah, I wasn’t sure as to which options were truly needed within the fstab entry. I added the space between NFS and _netdev, plus removed the force on UDP, as I have firewall rules for TCP/UDP regarding NFS (this was working before without forcing to one protocol versus the other). Looks like it mounted up now?

osmc@office-pi:/mnt/temp$ cat /etc/fstab
/dev/mmcblk0p1 /boot vfat defaults,noatime 0 0
/dev/mmcblk0p2 / ext4 defaults,noatime 0 0
192.168.1.7:/e/my\040videos /mnt/temp/ nfs _netdev,ro,intr,noatime,rsize=32768,wsize=32768,nolock,async 0 0
osmc@office-pi:/mnt/temp$ df -H
Filesystem Size Used Avail Use% Mounted on
devtmpfs 180M 0 180M 0% /dev
tmpfs 185M 4.7M 181M 3% /run
/dev/mmcblk0p2 3.6G 2.6G 792M 77% /
tmpfs 185M 0 185M 0% /dev/shm
tmpfs 5.3M 0 5.3M 0% /run/lock
tmpfs 185M 0 185M 0% /sys/fs/cgroup
/dev/mmcblk0p1 251M 34M 218M 14% /boot
tmpfs 37M 0 37M 0% /run/user/1000
192.168.1.7:/e/my videos 3.1T 1.8T 1.3T 57% /mnt/temp

So, what does this say about trying to mount/browse via kodi?

It would have been nice if you had mentioned this before… Try turning the rules off and see if that helps. If it does then take a good look at your rules.

1 Like

@bmillham I had the firewall turned off in initial testing, with no change. This entire config was working as is, prior to replacing the router only. No other changes were made when it broke, until troubleshooting.