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.
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:
ip ro
showmount -e 192.168.17.14
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
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.
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.