Vero4K+ can't access NFS shares after 2024.10-1 oct update

Since I applied the latest update (2024.10-1 october) all of my nfs share are unaccessable.
Log:
https://paste.osmc.tv/elodoreyud

2024-12-03 09:34:13.595 T:3012    error <general>: NFS: Failed to mount nfs share: / (mount_cb: command timed out)
2024-12-03 09:34:13.597 T:3012  warning <general>: Process directory 'nfs://192.168.17.14/volumeUSB1/usbshare/tv series - usb/Severance/' does not exist - skipping scan.

My NFS shares properly set up on my Synology NAS. It was working before the update. Please advise.

My NAS is on 192.168.17.14, the vero is in 192.168.1.218 IP address. All access granted to the shared folders.

And what is between that two subnets?

to my understanding /24 means that from 0-255 can be reached in 196.168.17.xxx as the subnetmask should be 255.255.255.0 and not between 196.168.17 and 196.168.0 or 196.168.1

In a ‘/24’ mask, the first 24 bits are designated for the network part. This leaves the remaining bits for host devices like computers, printers, or other networking equipment. Therefore, in a “/24” subnet mask (which can also be written as 255.255.255.0), the ‘255’ in the first three octets indicates that these address parts are reserved strictly for identifying the network segment, while the last part (0) is where the devices on that network vary.

There is a standard notation called CIDR where if you put /24 at the end it means every IP address starts by the same three numbers. So if you put 192.168.120.0/24 that means that access is allowed from every IP address from 192.168.120.0 to 192.168.120.255 so only those within the allowed range is allowed into the system.

That’s not the problem as he has another share for 192.168.1.0/24

i overlooked that other share, i focussed on 168.17.x and 168.1.x
sorry

Yeah exactly. 192.168.17.xxx is my other network so all the devices on that IP range can acess the NAS as Vero could before the october update. So that’s why I’m clueless.

Well we all will remain clueless until you answer the simple question “what is between that two subnets” it must be a router/firewall! Have you checked that?

For next steps login into the Vero via SSH and provide output of:

  1. ip ro
  2. showmount -e 192.168.17.14
  3. ping 192.168.17.14

Also you have the wireless interface active I suggest you disable that when you use wired connection.

osmc@esoxOsmc:~$ ip ro
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.228
192.168.1.1 dev eth0 scope link

osmc@esoxOsmc:~$ showmount -e 192.168.17.14
Export list for 192.168.17.14:
/volume1/video       192.168.1.0/24,192.168.17.0/24,192.168.0.237
/volumeUSB1/usbshare 192.168.1.0/24,192.168.17.0/24,192.168.0.184,192.168.0.237


osmc@esoxOsmc:~$ ping 192.168.17.14
PING 192.168.17.14 (192.168.17.14): 56 data bytes
64 bytes from 192.168.17.14: seq=0 ttl=63 time=1.558 ms
64 bytes from 192.168.17.14: seq=1 ttl=63 time=2.157 ms
64 bytes from 192.168.17.14: seq=2 ttl=63 time=2.303 ms
64 bytes from 192.168.17.14: seq=3 ttl=63 time=1.563 ms
64 bytes from 192.168.17.14: seq=4 ttl=63 time=2.266 ms


It looks ok to me, isn’t it?
Ahh ok, Let me switch the wifi off on vero4k
…
No luck, still not able to connect to the nfs shares :frowning:

This doesn’t fit your earlier message

yeah I misstyped earlier, but 192.168.1.0/24 (NFS permission) covers both addresses anyway…

True but when it comes to the router/firewall it might make a difference

If the problem remains after disabling wifi I personally would recommend to move to autofs instead of using Kodi to mount as it is easier to troubleshoot.

Yes, but as I said it was a working solution for couple of years now, but it seems it is not working since the 2024.10-1 installed.

You mean run the autofs on vero’s linux in putty? Is there any vero document available? I don’t have any experience of configuring autofs.

See Mounting network shares with autofs (alternative to fstab) - General - OSMC

Well we could continue to dig into Kodi to find the problem but it might be easier to do this with kernel mounts which might be easier to dig into.

@sam_nazarko just have posted the link to the respective instructions.

Also to check since how long (in days) to you face this issue.

Thank you guys.
Last night I checked this issue form the other side (NAS).
I have a DS116 running DSM 7.1.1.xxx version on it (latest). As I said before, any other devices could access this network storage without a problem as vero could access it before.

(What I also realized earlier is the nfs mounted directories are loading really slowly, but after the update it was just stopped working.)

So I decided checking new version of DSM for the NAS, and there was a 7.2.2 version which was not offered by automatic update process, so I manually downloaded it and patched my NAS with it.

After several restart of the NAS my vero4k+ instantly accessed all the mounts again.

I did not change any configuration at all on my nas, neither on the vero.

THanks everyone’s investigation on it, I think we can delete the whole thread, because it could misslead someone, because of the thread title because the issue was not caused by the vero update but the NAS itself.

3 Likes

Let’s leave the thread up – someone may experience the same problem with their Synology.

2 Likes