I'm experiencing a weird problem and trying to identify the cause of the problem and not sure where it is happening. I recently put a Mikrotik RB750GR3 in place to replace my (2) consumer grade TP-Link WDR4300 router/access point and the TP-Link devices have been relegated to AP's for now until I can get to configuring the Unifi UAP-AC-PRO.
Anyway, I've split up my network to 4 VLANs (LAN, KIDS, IoT, Guest) and I can get devices to get IP addresses, browse the internet, etc but when I put my Kodi box on the IoT VLAN and my Synology NAS on the same VLAN I can ping, etc I can mount NFS directly within the LibreELEC OS no problem, but from Kodi I cannot seem to do "NFS Browsing" or it is really slow in getting info from the NAS share.
I'm not sure if this is related to avahi not being in the MikroTik and the Mikrotik doesn't have on by default and I've added the Multicast package but I'm not sure what I would need to configure for this as far as IGMP or PIM(?) is concerned besides default setup in Winbox. I'm trying to setup a VM running CentOS (rather than Ubuntu) on my computer to run an an avahi-daemon but struggling with getting the VM to get network connectivity at this point on a VLAN via the trunked port on the host side. Not sure if I'm wasting my time trying to setup a VM for avahi if this is not the source of the problem
viewtopic.php?f=19&t=105651&p=543352&hi ... hi#p543352
Should the NFS browsing just work without the avahi setup? Even if the mount point is setup (as it was prior to introducing the MIkrotik) it doesn't play any of the media attached to the drive as it just sits there spinning its wheels.
At this point my next step might be trying to mount these file systems on the Linux LibreELEC OS side and referring to the file systems through the local disk within Kodi and see if that works but I'm baffled as to why the NFS browsing isn't working. Is it timing out talking to the Mikrotik trying to query for available NFS servers? However I've put in accept all traffic inbound on the interfaces to the router changing from drop as part of troubleshooting. I would think it is just doing direct connectivity between the Kodi box and the NAS.
Re: NFS browsing issue
Avahi is only needed if you want NFS to be "announced" or at least "discoverable." If you simply mount the share in Kodi and use NFS natively it should behave normally over the network.
That said, Avahi can be used with a custom TLD (not .local) and DNS-SD, DNS Service Discovery, is not necessary reliant on link-local multicast but the DNS resolver built-into RouterOS is extremely limited and is not intelligent enough to understand these types of queries or any of the automatic registration of devices like printers. You'd have to manually install and configure Avahi on the NFS server (NAS) in a way that could accept queries from different VLANs (custom TLD and forwarding from RouterOS caching DNS). Alternatively, placing the NFS server and client on the same VLAN will allow discovery of services via link-local multicast. Both methods do not require the MikroTik multicast package. The first requires a more thought out approach to DNS resolution in your LAN that likely will require not using the MikroTik for caching and the other requires the server and client to be in the same layer 2 domain.
An additional solution does exist and it's a hack you see built into numerous enterprise products and it essentially amounts to selectively bridging service discovery link-local multicast messages (typically Bonjour) between two or more LANs. I consider this a protocol violating hack so I do not endorse it, I'm also not familiar with a way to do this in RouterOS although others have done it with a device like a Raspberry Pi sitting bridged to the necessary VLANs.
That said, Avahi can be used with a custom TLD (not .local) and DNS-SD, DNS Service Discovery, is not necessary reliant on link-local multicast but the DNS resolver built-into RouterOS is extremely limited and is not intelligent enough to understand these types of queries or any of the automatic registration of devices like printers. You'd have to manually install and configure Avahi on the NFS server (NAS) in a way that could accept queries from different VLANs (custom TLD and forwarding from RouterOS caching DNS). Alternatively, placing the NFS server and client on the same VLAN will allow discovery of services via link-local multicast. Both methods do not require the MikroTik multicast package. The first requires a more thought out approach to DNS resolution in your LAN that likely will require not using the MikroTik for caching and the other requires the server and client to be in the same layer 2 domain.
An additional solution does exist and it's a hack you see built into numerous enterprise products and it essentially amounts to selectively bridging service discovery link-local multicast messages (typically Bonjour) between two or more LANs. I consider this a protocol violating hack so I do not endorse it, I'm also not familiar with a way to do this in RouterOS although others have done it with a device like a Raspberry Pi sitting bridged to the necessary VLANs.
Re: NFS browsing issue
The client and NAS are on the same segment (192.168.30.0/24)
The NAS is running avahi apparently
Apparently since it has avahi-daemon perhaps I could enable the reflector functionality as it was suggested in another threads because the Mikrotik doesn't support this that it would help with this possibly
So you are suggesting that I have to setup my own local DNS servers via bind, etc and not point to the Mikrotik for caching (seems like a broken DNS resolver compared to OpenWRT basic DNS caching resolver)? What about external DNS servers but then nothing internally would work but I'm not using local DNS anyway at this point (but if I got to the point of doing this bind setup I guess I would)?
I don't necessarily need bonour/rendevous for apple type services even though I have a couple of Mac's but Kodi uses the protocol for zeroconf I believe.
Code: Select all
Synology NAS
root@DiskStation:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:11:32:1D:6D:7E
inet addr:192.168.88.5 Bcast:192.168.88.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:59951 errors:0 dropped:0 overruns:0 frame:0
TX packets:162522 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:35671602 (34.0 MiB) TX bytes:209461652 (199.7 MiB)
Interrupt:11
eth0.10 Link encap:Ethernet HWaddr 00:11:32:1D:6D:7E
inet addr:192.168.10.5 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fdfa:dbf3:b1c8:30::5/64 Scope:Global
inet6 addr: fdfa:dbf3:b1c8:30:211:32ff:fe1d:6d7e/64 Scope:Global
inet6 addr: fdc6:1407:6f68:30:211:32ff:fe1d:6d7e/64 Scope:Global
inet6 addr: fe80::211:32ff:fe1d:6d7e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:655 errors:0 dropped:0 overruns:0 frame:0
TX packets:1623 errors:0 dropped:7 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:96907 (94.6 KiB) TX bytes:355790 (347.4 KiB)
eth0.20 Link encap:Ethernet HWaddr 00:11:32:1D:6D:7E
inet addr:192.168.20.5 Bcast:192.168.20.255 Mask:255.255.255.0
inet6 addr: fe80::211:32ff:fe1d:6d7e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:252 errors:0 dropped:0 overruns:0 frame:0
TX packets:1351 errors:0 dropped:6 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:53792 (52.5 KiB) TX bytes:320743 (313.2 KiB)
eth0.30 Link encap:Ethernet HWaddr 00:11:32:1D:6D:7E
inet addr:192.168.30.5 Bcast:192.168.30.255 Mask:255.255.255.0
inet6 addr: fe80::211:32ff:fe1d:6d7e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:56907 errors:0 dropped:0 overruns:0 frame:0
TX packets:156727 errors:0 dropped:6 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:33666248 (32.1 MiB) TX bytes:208331480 (198.6 MiB)
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:16436 Metric:1
RX packets:1194 errors:0 dropped:0 overruns:0 frame:0
TX packets:1194 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:102167 (99.7 KiB) TX bytes:102167 (99.7 KiB)
root@DiskStation:# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.20
192.168.30.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.30
192.168.88.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0.10
0.0.0.0 192.168.88.1 0.0.0.0 UG 0 0 0 eth0
root@DiskStation:#
root@DiskStation:# ping 192.168.30.29
PING 192.168.30.29 (192.168.30.29) 56(84) bytes of data.
64 bytes from 192.168.30.29: icmp_seq=1 ttl=64 time=0.169 ms
64 bytes from 192.168.30.29: icmp_seq=2 ttl=64 time=0.187 ms
64 bytes from 192.168.30.29: icmp_seq=3 ttl=64 time=0.100 ms
64 bytes from 192.168.30.29: icmp_seq=4 ttl=64 time=0.129 ms
^C
--- 192.168.30.29 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.100/0.146/0.187/0.035 ms
root@DiskStation:#
Mac-mini:~ brian$ ssh root@192.168.30.29
root@192.168.30.29's password:
##############################################
LibreELEC
http://libreelec.tv
##############################################
LibreELEC (official) Version: 8.0.2
LibreELEC:~ #
LibreELEC:~ #
LibreELEC:~ # ifconfig
eth0 Link encap:Ethernet HWaddr C4:54:44:79:68:7B
inet addr:192.168.30.29 Bcast:192.168.30.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:168502168 errors:0 dropped:5297 overruns:0 frame:0
TX packets:77912041 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:218658227568 (203.6 GiB) TX bytes:25185439355 (23.4 GiB)
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:16364 errors:0 dropped:0 overruns:0 frame:0
TX packets:16364 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:6415781 (6.1 MiB) TX bytes:6415781 (6.1 MiB)
wlan0 Link encap:Ethernet HWaddr 54:27:1E:E5:54:91
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
LibreELEC:~ # netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.30.1 0.0.0.0 UG 0 0 0 eth0
64.140.114.21 192.168.30.1 255.255.255.255 UGH 0 0 0 eth0
64.140.114.22 192.168.30.1 255.255.255.255 UGH 0 0 0 eth0
64.140.114.23 192.168.30.1 255.255.255.255 UGH 0 0 0 eth0
192.168.30.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.30.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
LibreELEC:~ #
LibreELEC:~ # ping 192.168.30.5
PING 192.168.30.5 (192.168.30.5): 56 data bytes
64 bytes from 192.168.30.5: seq=0 ttl=64 time=0.150 ms
64 bytes from 192.168.30.5: seq=1 ttl=64 time=0.142 ms
64 bytes from 192.168.30.5: seq=2 ttl=64 time=0.187 ms
64 bytes from 192.168.30.5: seq=3 ttl=64 time=0.102 ms
^C
--- 192.168.30.5 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.102/0.145/0.187 ms
LibreELEC:~ #
LibreELEC:~ # ping 192.168.30.1
PING 192.168.30.1 (192.168.30.1): 56 data bytes
64 bytes from 192.168.30.1: seq=0 ttl=64 time=0.333 ms
64 bytes from 192.168.30.1: seq=1 ttl=64 time=0.206 ms
64 bytes from 192.168.30.1: seq=2 ttl=64 time=0.215 ms
^C
--- 192.168.30.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.206/0.251/0.333 ms
LibreELEC:~ #
[admin@MikroTik] > ping 192.168.30.5
SEQ HOST SIZE TTL TIME STATUS
0 192.168.30.5 56 64 0ms
1 192.168.30.5 56 64 0ms
2 192.168.30.5 56 64 0ms
3 192.168.30.5 56 64 0ms
sent=4 received=4 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms
[admin@MikroTik] > ping 192.168.30.29
SEQ HOST SIZE TTL TIME STATUS
0 192.168.30.29 56 64 0ms
1 192.168.30.29 56 64 0ms
2 192.168.30.29 56 64 0ms
sent=3 received=3 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms
[admin@MikroTik] >
Code: Select all
root@DiskStation:~# ps -ef | grep ava
root 28443 1 0 22:21 ? 00:00:00 avahi-daemon: running [DiskStation.local]
root 31364 30896 0 22:42 pts/15 00:00:00 grep --color=auto ava
root@DiskStation:~#
Apparently since it has avahi-daemon perhaps I could enable the reflector functionality as it was suggested in another threads because the Mikrotik doesn't support this that it would help with this possibly
Code: Select all
root@DiskStation:/etc/avahi# cat avahi-daemon.conf
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
# See avahi-daemon.conf(5) for more information on this configuration
# file!
[server]
loglevel=0
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
cache-entries-max=128
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000
aliases-conf=/var/tmp/nginx/avahi-aliases.conf
[wide-area]
enable-wide-area=yes
[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
#publish-hinfo=yes
#publish-workstation=yes
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no
[reflector]
#enable-reflector=no
#reflect-ipv=no
[rlimits]
#rlimit-as=
#rlimit-core=0
rlimit-data=4194304
#rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3
[synology]
resolve-raop=yes
resolve-airplay=yes
resolve-airport=yes
root@DiskStation:/etc/avahi#
I don't necessarily need bonour/rendevous for apple type services even though I have a couple of Mac's but Kodi uses the protocol for zeroconf I believe.
Re: NFS browsing issue
If they are on the same segment local discovery should be working without interference from MikroTik. I suppose it's possible that by placing your NAS in each VLAN like you have it may be confusing the autoconf deamon (Avahi).
When the NAS and client are the same VLAN the MikroTik won't or at least shouldn't be interfering with link-local multicast. It is possible the MikroTik module for multicast is interfering. Also, if you enabled IGMP snooping in 6.41rc's bridge you may want to shut that down as well just to make sure the new code isn't causing an issue with clients on the LAN subscribing to the link-local multicast stream.
So, being on the same VLAN nothing additional should be required. If anything I'd start by putting the NAS only the VLAN directly with client in question. From there I'd ensure you don't have any loops or poor pathing over the TP-Link units acting as APs.
When the NAS and client are the same VLAN the MikroTik won't or at least shouldn't be interfering with link-local multicast. It is possible the MikroTik module for multicast is interfering. Also, if you enabled IGMP snooping in 6.41rc's bridge you may want to shut that down as well just to make sure the new code isn't causing an issue with clients on the LAN subscribing to the link-local multicast stream.
So, being on the same VLAN nothing additional should be required. If anything I'd start by putting the NAS only the VLAN directly with client in question. From there I'd ensure you don't have any loops or poor pathing over the TP-Link units acting as APs.
Re: NFS browsing issue
OK I just updated the lib nfs issue log and Kodi forums on this but back tracking to here where I posted originally
https://forum.kodi.tv/showthread.php?tid=324431
https://github.com/sahlberg/libnfs/issues/232
OK status update.... I just tried mounting within LibreELEC and I was able to mount the file systems this way but then I ended up with duplicate entries in the Kodi list so if I selected the first one it would start timing out, etc I'm not sure if I tried the second link or not but then I got an idea (see below)
....because it as trying to reference an old link to my old IP address of my NAS I believe (my theory) (I changed my NAS IP from 192.168.1.5 to various IPs such as 192.168.88.5 (MGMT), 192.168,10.5 (LAN), 192.168.20.5 (KIDS), 192.168.30.5 (IoT) (and possibly 192.168.50.5 but I'm not mounting NAS on my Guest network at this point
)
So anyway a couple of days ago when I started to experience this issue after changing my network design at home; I had seen references to 192.168.1.5 in various files by checking via find ("find /storage -exec egrep 192.168.1.5 {} \;") and saw the old IP address of my NAS in a list of all my content. I thought about cleaning up the database so I had tried the "Clean" options in the menus in KODI but that doesn't remove the content or tell it to rescan for location changes I guess.
I just ended up going into the Kodi User Data and removing "MyVideos" and "MyMusic" DB and rebooting LibreELEC and then KODI showed no existing content, etc. I went and added the sources via nfs browsing and voila it worked instantly as it wasn't timing out on the old 192.168.1.5 IP for my NAS and was showing up as 192.168.30.5 (my Internet of Things (IoT) segment (for my TV/AV equipment like TV, Kodi box, Apple TV, HD HomeRun, AV Receiver, BluRay player, thermostat, etc - my attempt to separate from my home network stuff)
When I went to add it had already picked up my /storage/Movies, /storage/music so I had to rename Movies (2) after removing these sources manually and then subsequently going into LibreELEC and removing the OS side mount.
I guess now I have to look at undoing some of the experimental changes to the NAS mounts and turning off UPnP on the Miktrotik now that I have resolved this I guess as that shouldn't be needed for this purpose at least at this point due to this NAS mount. Mikrotik leaves UPnP off by default so not needed for this.
LibreELEC (official): 8.2.1 (Generic.x86_64)
LibreELEC:~ # df -h
Filesystem Size Used Available Use% Mounted on
devtmpfs 892.9M 202.8M 690.1M 23% /dev
/dev/sda1 511.0M 214.8M 296.2M 42% /flash
/dev/sda2 14.1G 4.0G 10.1G 28% /storage
/dev/loop0 202.9M 202.9M 0 100% /
tmpfs 895.5M 0 895.5M 0% /dev/shm
tmpfs 895.5M 6.7M 888.8M 1% /run
tmpfs 895.5M 0 895.5M 0% /sys/fs/cgroup
tmpfs 895.5M 2.0M 893.5M 0% /var
tmpfs 895.5M 4.0K 895.5M 0% /tmp
192.168.30.5:/volume1/quasararchive
7.2T 6.3T 934.3G 87% /storage/quasararchive
192.168.30.5:/volume1/music
7.2T 6.3T 934.3G 87% /storage/music
192.168.30.5:/volume1/TVShows
7.2T 6.3T 934.3G 87% /storage/TVShows
192.168.30.5:/volume1/quasar
7.2T 6.3T 934.3G 87% /storage/quasar
192.168.30.5:/volume1/Movies
7.2T 6.3T 934.3G 87% /storage/Movies
192.168.30.5:/volume1/Pictures
7.2T 6.3T 934.3G 87% /storage/Pictures
192.168.30.5:/volume1/downloads
7.2T 6.3T 934.3G 87% /storage/downloads
LibreELEC:~ # umount /storage/TVShows/
LibreELEC:~ # umount /storage/music/
LibreELEC:~ # umount /storage/Pictures/
LibreELEC:~ # umount /storage/downloads/
LibreELEC:~ # umount /storage/Movies/
LibreELEC:~ # cd /storage/.config/system.d/
LibreELEC:~/.config/system.d # ls -l
total 76
-rw-r--r-- 1 root root 28816 Feb 6 2017 README
-rw-rw-r-- 1 root root 1772 Nov 20 00:38 cifs.mount.sample
drwxr-xr-x 2 root root 4096 Nov 22 10:06 multi-user.target.wants
-rw-rw-r-- 1 root root 1729 Nov 20 00:38 nfs.mount.sample
-rw-rw-r-- 1 root root 1145 Nov 20 00:38 openvpn.service.sample
-rw-r--r-- 1 root root 1738 Nov 22 09:59 storage-Movies.mount
-rw-r--r-- 1 root root 1744 Nov 22 10:00 storage-Pictures.mount
-rw-r--r-- 1 root root 1741 Nov 22 10:00 storage-TVShows.mount
-rw-r--r-- 1 root root 1747 Nov 22 09:57 storage-downloads.mount
-rw-r--r-- 1 root root 1735 Nov 22 10:00 storage-music.mount
-rw-r--r-- 1 root root 1738 Nov 19 04:57 storage-quasar.mount
-rw-r--r-- 1 root root 1760 Nov 19 04:57 storage-quasararchive.mount
LibreELEC:~/.config/system.d # mkdir disabled
LibreELEC:~/.config/system.d # mv storage-downloads.mount storage-music.mount storage-TVShows.mount storage-Pictures.mount storage-Movies.mount disabled/
LibreELEC:~/.config/system.d # ls -l
total 60
-rw-r--r-- 1 root root 28816 Feb 6 2017 README
-rw-rw-r-- 1 root root 1772 Nov 20 00:38 cifs.mount.sample
drwxr-xr-x 2 root root 4096 Nov 23 02:38 disabled
drwxr-xr-x 2 root root 4096 Nov 22 10:06 multi-user.target.wants
-rw-rw-r-- 1 root root 1729 Nov 20 00:38 nfs.mount.sample
-rw-rw-r-- 1 root root 1145 Nov 20 00:38 openvpn.service.sample
-rw-r--r-- 1 root root 1738 Nov 19 04:57 storage-quasar.mount
-rw-r--r-- 1 root root 1760 Nov 19 04:57 storage-quasararchive.mount
LibreELEC:~/.config/system.d # reboot
At this point I tried playing content that has already been indexed and await the rest of it to be reindexed.
Thanks all for the input/help. Hope this helps someone else in the future if they end up changing their IP address of their NAS/server that acts as an NFS/SMB server. I guess I'll have to setup an internal DNS server to avoid this stuff (but I'd probably want to do NAS-IoT, NAS-LAN, etc to prevent going to the wrong interface though) but now that I know what the issue is I know what to avoid and I don't plan on re-IPing my network again.
https://forum.kodi.tv/showthread.php?tid=324431
https://github.com/sahlberg/libnfs/issues/232
OK status update.... I just tried mounting within LibreELEC and I was able to mount the file systems this way but then I ended up with duplicate entries in the Kodi list so if I selected the first one it would start timing out, etc I'm not sure if I tried the second link or not but then I got an idea (see below)
....because it as trying to reference an old link to my old IP address of my NAS I believe (my theory) (I changed my NAS IP from 192.168.1.5 to various IPs such as 192.168.88.5 (MGMT), 192.168,10.5 (LAN), 192.168.20.5 (KIDS), 192.168.30.5 (IoT) (and possibly 192.168.50.5 but I'm not mounting NAS on my Guest network at this point
)So anyway a couple of days ago when I started to experience this issue after changing my network design at home; I had seen references to 192.168.1.5 in various files by checking via find ("find /storage -exec egrep 192.168.1.5 {} \;") and saw the old IP address of my NAS in a list of all my content. I thought about cleaning up the database so I had tried the "Clean" options in the menus in KODI but that doesn't remove the content or tell it to rescan for location changes I guess.
I just ended up going into the Kodi User Data and removing "MyVideos" and "MyMusic" DB and rebooting LibreELEC and then KODI showed no existing content, etc. I went and added the sources via nfs browsing and voila it worked instantly as it wasn't timing out on the old 192.168.1.5 IP for my NAS and was showing up as 192.168.30.5 (my Internet of Things (IoT) segment (for my TV/AV equipment like TV, Kodi box, Apple TV, HD HomeRun, AV Receiver, BluRay player, thermostat, etc - my attempt to separate from my home network stuff)
When I went to add it had already picked up my /storage/Movies, /storage/music so I had to rename Movies (2) after removing these sources manually and then subsequently going into LibreELEC and removing the OS side mount.
I guess now I have to look at undoing some of the experimental changes to the NAS mounts and turning off UPnP on the Miktrotik now that I have resolved this I guess as that shouldn't be needed for this purpose at least at this point due to this NAS mount. Mikrotik leaves UPnP off by default so not needed for this.
LibreELEC (official): 8.2.1 (Generic.x86_64)
LibreELEC:~ # df -h
Filesystem Size Used Available Use% Mounted on
devtmpfs 892.9M 202.8M 690.1M 23% /dev
/dev/sda1 511.0M 214.8M 296.2M 42% /flash
/dev/sda2 14.1G 4.0G 10.1G 28% /storage
/dev/loop0 202.9M 202.9M 0 100% /
tmpfs 895.5M 0 895.5M 0% /dev/shm
tmpfs 895.5M 6.7M 888.8M 1% /run
tmpfs 895.5M 0 895.5M 0% /sys/fs/cgroup
tmpfs 895.5M 2.0M 893.5M 0% /var
tmpfs 895.5M 4.0K 895.5M 0% /tmp
192.168.30.5:/volume1/quasararchive
7.2T 6.3T 934.3G 87% /storage/quasararchive
192.168.30.5:/volume1/music
7.2T 6.3T 934.3G 87% /storage/music
192.168.30.5:/volume1/TVShows
7.2T 6.3T 934.3G 87% /storage/TVShows
192.168.30.5:/volume1/quasar
7.2T 6.3T 934.3G 87% /storage/quasar
192.168.30.5:/volume1/Movies
7.2T 6.3T 934.3G 87% /storage/Movies
192.168.30.5:/volume1/Pictures
7.2T 6.3T 934.3G 87% /storage/Pictures
192.168.30.5:/volume1/downloads
7.2T 6.3T 934.3G 87% /storage/downloads
LibreELEC:~ # umount /storage/TVShows/
LibreELEC:~ # umount /storage/music/
LibreELEC:~ # umount /storage/Pictures/
LibreELEC:~ # umount /storage/downloads/
LibreELEC:~ # umount /storage/Movies/
LibreELEC:~ # cd /storage/.config/system.d/
LibreELEC:~/.config/system.d # ls -l
total 76
-rw-r--r-- 1 root root 28816 Feb 6 2017 README
-rw-rw-r-- 1 root root 1772 Nov 20 00:38 cifs.mount.sample
drwxr-xr-x 2 root root 4096 Nov 22 10:06 multi-user.target.wants
-rw-rw-r-- 1 root root 1729 Nov 20 00:38 nfs.mount.sample
-rw-rw-r-- 1 root root 1145 Nov 20 00:38 openvpn.service.sample
-rw-r--r-- 1 root root 1738 Nov 22 09:59 storage-Movies.mount
-rw-r--r-- 1 root root 1744 Nov 22 10:00 storage-Pictures.mount
-rw-r--r-- 1 root root 1741 Nov 22 10:00 storage-TVShows.mount
-rw-r--r-- 1 root root 1747 Nov 22 09:57 storage-downloads.mount
-rw-r--r-- 1 root root 1735 Nov 22 10:00 storage-music.mount
-rw-r--r-- 1 root root 1738 Nov 19 04:57 storage-quasar.mount
-rw-r--r-- 1 root root 1760 Nov 19 04:57 storage-quasararchive.mount
LibreELEC:~/.config/system.d # mkdir disabled
LibreELEC:~/.config/system.d # mv storage-downloads.mount storage-music.mount storage-TVShows.mount storage-Pictures.mount storage-Movies.mount disabled/
LibreELEC:~/.config/system.d # ls -l
total 60
-rw-r--r-- 1 root root 28816 Feb 6 2017 README
-rw-rw-r-- 1 root root 1772 Nov 20 00:38 cifs.mount.sample
drwxr-xr-x 2 root root 4096 Nov 23 02:38 disabled
drwxr-xr-x 2 root root 4096 Nov 22 10:06 multi-user.target.wants
-rw-rw-r-- 1 root root 1729 Nov 20 00:38 nfs.mount.sample
-rw-rw-r-- 1 root root 1145 Nov 20 00:38 openvpn.service.sample
-rw-r--r-- 1 root root 1738 Nov 19 04:57 storage-quasar.mount
-rw-r--r-- 1 root root 1760 Nov 19 04:57 storage-quasararchive.mount
LibreELEC:~/.config/system.d # reboot
At this point I tried playing content that has already been indexed and await the rest of it to be reindexed.
Thanks all for the input/help. Hope this helps someone else in the future if they end up changing their IP address of their NAS/server that acts as an NFS/SMB server. I guess I'll have to setup an internal DNS server to avoid this stuff (but I'd probably want to do NAS-IoT, NAS-LAN, etc to prevent going to the wrong interface though) but now that I know what the issue is I know what to avoid and I don't plan on re-IPing my network again.
Re: NFS browsing issue
So long story it wasn't an NFS or Mikrotik issue but the database within KODI for all of the content on my NAS share referenced by the old IP address of the NAS before i split it up onto various VLAN segments.