Closed bolmsted closed 6 years ago
Libnfs uses the same method to discover the nfs servers as the rpcinfo tool does, if you run :
'rpcinfo -b 100005 2'
This is the standard way to discover RPC services on the local network. This uses rpcinfo to probe if the mount daemon is available. As it uses local broadcasts it can only discover RPC servers on the same network/vlan as kodi/libnfs.
Please try running that command and see if it can find your NFS server or not.
It is known that QTS4.3 FW recently broke broadcast RPC and thus neither the rpcinfo command nor libnfs can no longer discover a QTS4.3 NFS server. "Linux" rpcinfo was also broken a bit recently where the RPCBIND process on the NFS server would segfault when it received a broadcast RPC. That bug is fixed in later versions of RPCBIND.
People have reported to QNAP that they broke NFS discovery but I do not know if/when they will fix it. See: https://groups.google.com/forum/#!topic/libnfs/UAyNNu0Z27Q
Note that Kodi only supports NFSv3 as that is the only thing that the versions of libnfs that distros ship support.
Well I'm running off a Synology NAS.
When I try from LibreELEC I get this, but I can't exactly test this from the Kodi side I don't think. However, its not just the browsing but I think the actual NFS mount doesn't work once it is added as my content doesn't play as expected and hence why I tried to remove and try adding again because I had changed the IP address of my NAS (192.168.1.5 -> 192.168.30.5) so my Kodi library had all of the old references so I thought it was easier to just readd and then I ran into this issue
LibreELEC:~ # rpcinfo -h rpcinfo: invalid option -- 'h' Usage: rpcinfo [-m | -s] [host] rpcinfo -p [host] rpcinfo -T netid host prognum [versnum] rpcinfo -l host prognum versnum rpcinfo [-n portnum] -u | -t host prognum [versnum] rpcinfo -a serv_address -T netid prognum [version] rpcinfo -b prognum versnum rpcinfo -d [-T netid] prognum versnum LibreELEC:~ # LibreELEC:~ # rpcinfo -l 192.168.30.5 100005 2 program vers tp_family/name/class address service 100005 2 inet/udp/clts 192.168.30.5.3.124 mountd 100005 2 inet/tcp/cots_ord 192.168.30.5.3.124 mountd LibreELEC:~ # LibreELEC:~ # rpcinfo -b 100005 2 rpcinfo: broadcast failed: RPC: Unknown protocol LibreELEC:~ # LibreELEC:~ # rpcinfo -p 192.168.30.5 192.168.30.5: RPC: Unknown host 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.177 ms 64 bytes from 192.168.30.5: seq=1 ttl=64 time=0.150 ms 64 bytes from 192.168.30.5: seq=2 ttl=64 time=0.141 ms ^C --- 192.168.30.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.141/0.156/0.177 ms LibreELEC:~ # LibreELEC:~ # ssh admin@192.168.30.5 The authenticity of host '192.168.30.5 (192.168.30.5)' can't be established. ECDSA key fingerprint is SHA256:EMV6x20cq12jXMOPDyiUVCW2/lTgJqLGO4BFSF7NkUA. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.30.5' (ECDSA) to the list of known hosts. admin@192.168.30.5's password: Last login: Mon Nov 20 16:08:47 2017 from 192.168.88.15 admin@DiskStation:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 2.4G 955M 1.4G 42% / none 246M 4.0K 246M 1% /dev /tmp 250M 1.2M 249M 1% /tmp /run 250M 2.4M 248M 1% /run /dev/shm 250M 4.0K 250M 1% /dev/shm /dev/vg1000/lv 7.3T 6.3T 964G 87% /opt admin@DiskStation:~$
These NFS mounts appear to work within LibreELEC directly but the mounting and usage within Kodi seems to have stopped working. Is this due to VLAN on the Synology?
LibreELEC:~ # df -h Filesystem Size Used Available Use% Mounted on devtmpfs 894.6M 196.6M 698.0M 22% /dev /dev/sda1 511.0M 208.5M 302.4M 41% /flash /dev/sda2 14.1G 3.9G 10.1G 28% /storage /dev/loop0 196.8M 196.8M 0 100% / tmpfs 897.3M 0 897.3M 0% /dev/shm tmpfs 897.3M 6.2M 891.0M 1% /run tmpfs 897.3M 0 897.3M 0% /sys/fs/cgroup tmpfs 897.3M 272.0K 897.0M 0% /var tmpfs 897.3M 4.0K 897.3M 0% /tmp 192.168.30.5:/volume1/quasararchive 7.2T 6.3T 963.7G 87% /storage/quasararchive 192.168.30.5:/volume1/quasar 7.2T 6.3T 963.7G 87% /storage/quasar LibreELEC:~ #
not sure why the previous section got stikeout
On Wed, Nov 22, 2017 at 9:52 AM, bolmsted notifications@github.com wrote:
Well I'm running off a Synology NAS.
When I try from LibreELEC I get this, but I can't exactly test this from the Kodi side I don't think. However, its not just the browsing but I think the actual NFS mount doesn't work once it is added as my content doesn't play as expected and hence why I tried to remove and try adding again because I had changed the IP address of my NAS (192.168.1.5 -> 192.168.30.5) so my Kodi library had all of the old references so I thought it was easier to just readd and then I ran into this issue
LibreELEC:~ # rpcinfo -h rpcinfo: invalid option -- 'h' Usage: rpcinfo [-m | -s] [host] rpcinfo -p [host] rpcinfo -T netid host prognum [versnum] rpcinfo -l host prognum versnum rpcinfo [-n portnum] -u | -t host prognum [versnum] rpcinfo -a serv_address -T netid prognum [version] rpcinfo -b prognum versnum rpcinfo -d [-T netid] prognum versnum LibreELEC:~ # LibreELEC:~ # rpcinfo -l 192.168.30.5 100005 2 program vers tp_family/name/class address service 100005 2 inet/udp/clts 192.168.30.5.3.124 mountd 100005 2 inet/tcp/cots_ord 192.168.30.5.3.124 mountd LibreELEC:~ # LibreELEC:~ # rpcinfo -b 100005 2 rpcinfo: broadcast failed: RPC: Unknown protocol LibreELEC:~ # LibreELEC:~ # rpcinfo -p 192.168.30.5 192.168.30.5: RPC: Unknown host 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.177 ms 64 bytes from 192.168.30.5: seq=1 ttl=64 time=0.150 ms 64 bytes from 192.168.30.5: seq=2 ttl=64 time=0.141 ms ^C --- 192.168.30.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.141/0.156/0.177 ms LibreELEC:~ # LibreELEC:~ # ssh admin@192.168.30.5 The authenticity of host '192.168.30.5 (192.168.30.5)' can't be established. ECDSA key fingerprint is SHA256:EMV6x20cq12jXMOPDyiUVCW2/lTgJqLGO4BFSF7NkUA. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.30.5' (ECDSA) to the list of known hosts. admin@192.168.30.5's password: Last login: Mon Nov 20 16:08:47 2017 from 192.168.88.15 admin@DiskStation:$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 2.4G 955M 1.4G 42% / none 246M 4.0K 246M 1% /dev /tmp 250M 1.2M 249M 1% /tmp /run 250M 2.4M 248M 1% /run /dev/shm 250M 4.0K 250M 1% /dev/shm /dev/vg1000/lv 7.3T 6.3T 964G 87% /opt admin@DiskStation:$
These NFS mounts appear to work within LibreELEC directly but the mounting and usage within Kodi seems to have stopped working. Is this due to VLAN on the Synology?
Very possible. Is kodi and the Synology connected to the same subnet/vlan ? The discovery will only work if they are in the same subnet/vlan.
LibreELEC:~ # df -h Filesystem Size Used Available Use% Mounted on devtmpfs 894.6M 196.6M 698.0M 22% /dev /dev/sda1 511.0M 208.5M 302.4M 41% /flash /dev/sda2 14.1G 3.9G 10.1G 28% /storage /dev/loop0 196.8M 196.8M 0 100% / tmpfs 897.3M 0 897.3M 0% /dev/shm tmpfs 897.3M 6.2M 891.0M 1% /run tmpfs 897.3M 0 897.3M 0% /sys/fs/cgroup tmpfs 897.3M 272.0K 897.0M 0% /var tmpfs 897.3M 4.0K 897.3M 0% /tmp 192.168.30.5:/volume1/quasararchive 7.2T 6.3T 963.7G 87% /storage/quasararchive 192.168.30.5:/volume1/quasar 7.2T 6.3T 963.7G 87% /storage/quasar LibreELEC:~ #
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
So even if the discovery does not work, if the client/server are on different VLANS.
You should still be able to use that NFS server, you just have to specify its ip address manually.
Can you try this: 1, go to Add Video Source 2, click Browse 3, Do not select NFS. Instead pick "Add Network Location ..." 4, On Protocol, cycle until you select NFS 5, Set Server Address to the ip of the NAS
You should now be able to Browse it for its shares and hopefully connect.
On Wed, Nov 22, 2017 at 10:13 AM, ronnie sahlberg ronniesahlberg@gmail.com wrote:
On Wed, Nov 22, 2017 at 9:52 AM, bolmsted notifications@github.com wrote:
Well I'm running off a Synology NAS.
When I try from LibreELEC I get this, but I can't exactly test this from the Kodi side I don't think. However, its not just the browsing but I think the actual NFS mount doesn't work once it is added as my content doesn't play as expected and hence why I tried to remove and try adding again because I had changed the IP address of my NAS (192.168.1.5 -> 192.168.30.5) so my Kodi library had all of the old references so I thought it was easier to just readd and then I ran into this issue
LibreELEC:~ # rpcinfo -h rpcinfo: invalid option -- 'h' Usage: rpcinfo [-m | -s] [host] rpcinfo -p [host] rpcinfo -T netid host prognum [versnum] rpcinfo -l host prognum versnum rpcinfo [-n portnum] -u | -t host prognum [versnum] rpcinfo -a serv_address -T netid prognum [version] rpcinfo -b prognum versnum rpcinfo -d [-T netid] prognum versnum LibreELEC:~ # LibreELEC:~ # rpcinfo -l 192.168.30.5 100005 2 program vers tp_family/name/class address service 100005 2 inet/udp/clts 192.168.30.5.3.124 mountd 100005 2 inet/tcp/cots_ord 192.168.30.5.3.124 mountd LibreELEC:~ # LibreELEC:~ # rpcinfo -b 100005 2 rpcinfo: broadcast failed: RPC: Unknown protocol LibreELEC:~ # LibreELEC:~ # rpcinfo -p 192.168.30.5 192.168.30.5: RPC: Unknown host 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.177 ms 64 bytes from 192.168.30.5: seq=1 ttl=64 time=0.150 ms 64 bytes from 192.168.30.5: seq=2 ttl=64 time=0.141 ms ^C --- 192.168.30.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.141/0.156/0.177 ms LibreELEC:~ # LibreELEC:~ # ssh admin@192.168.30.5 The authenticity of host '192.168.30.5 (192.168.30.5)' can't be established. ECDSA key fingerprint is SHA256:EMV6x20cq12jXMOPDyiUVCW2/lTgJqLGO4BFSF7NkUA. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.30.5' (ECDSA) to the list of known hosts. admin@192.168.30.5's password: Last login: Mon Nov 20 16:08:47 2017 from 192.168.88.15 admin@DiskStation:$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 2.4G 955M 1.4G 42% / none 246M 4.0K 246M 1% /dev /tmp 250M 1.2M 249M 1% /tmp /run 250M 2.4M 248M 1% /run /dev/shm 250M 4.0K 250M 1% /dev/shm /dev/vg1000/lv 7.3T 6.3T 964G 87% /opt admin@DiskStation:$
These NFS mounts appear to work within LibreELEC directly but the mounting and usage within Kodi seems to have stopped working. Is this due to VLAN on the Synology?
Very possible. Is kodi and the Synology connected to the same subnet/vlan ? The discovery will only work if they are in the same subnet/vlan.
LibreELEC:~ # df -h Filesystem Size Used Available Use% Mounted on devtmpfs 894.6M 196.6M 698.0M 22% /dev /dev/sda1 511.0M 208.5M 302.4M 41% /flash /dev/sda2 14.1G 3.9G 10.1G 28% /storage /dev/loop0 196.8M 196.8M 0 100% / tmpfs 897.3M 0 897.3M 0% /dev/shm tmpfs 897.3M 6.2M 891.0M 1% /run tmpfs 897.3M 0 897.3M 0% /sys/fs/cgroup tmpfs 897.3M 272.0K 897.0M 0% /var tmpfs 897.3M 4.0K 897.3M 0% /tmp 192.168.30.5:/volume1/quasararchive 7.2T 6.3T 963.7G 87% /storage/quasararchive 192.168.30.5:/volume1/quasar 7.2T 6.3T 963.7G 87% /storage/quasar LibreELEC:~ #
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
Yes, Kodi (LibreELEC) and Synology NAS are on the same subnet (192.168.30.0/24). Previously they were on 192.168.1.0/24 before I setup VLANs.
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 (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] >
let me try your other suggestion for browsing.
so far your suggestion to do this in Kodi has done nothing as it just sits there for a long time spinning wheels, etc I was trying to clear the database at this point but I fell asleep waiting for it to complete unless there is a way I can do it from within the command line and then try adding sources. thought perhaps it might be corrupted or full of links with the old IP addresses in it.
Can you try this: 1, go to Add Video Source 2, click Browse 3, Do not select NFS. Instead pick "Add Network Location ..." 4, On Protocol, cycle until you select NFS 5, Set Server Address to the ip of the NAS
still cannot get past this point with Kodi. I'm able to mount the file systems manually in /etc/fstab within LibreELEC and I'm going to attempt to reference the files as part of the local file system instead.
Add network location just ends up with nfs:// when browsing. Adding remote location will put the mapping in but the drive seems like it is not getting there even though my exportfs on the Synology looks like this and I'm attempting from 192.168.30.29
(I'm experimenting with the whole insecure/insecure_locks and squashing options to no avail...)
root@DiskStation:/etc# cat exports /volume1/Movies 192.168.30.29(rw,async,no_wdelay,crossmnt,insecure_locks,all_squash,sec=sys,anonuid=1024,anongid=100) /volume1/downloads 192.168.30.29(rw,async,no_wdelay,crossmnt,insecure_locks,all_squash,sec=sys,anonuid=1024,anongid=100) /volume1/music 192.168.30.29(rw,async,no_wdelay,crossmnt,insecure_locks,all_squash,sec=sys,anonuid=1024,anongid=100) /volume1/Pictures 192.168.30.29(rw,async,no_wdelay,crossmnt,insecure_locks,all_squash,sec=sys,anonuid=1024,anongid=100) /volume1/quasar 192.168.30.29(rw,async,no_wdelay,crossmnt,insecure_locks,all_squash,sec=sys,anonuid=1024,anongid=100) /volume1/quasararchive 192.168.30.29(rw,async,no_wdelay,crossmnt,insecure_locks,all_squash,sec=sys,anonuid=1024,anongid=100) /volume1/TVShows 192.168.30.29(rw,async,no_wdelay,crossmnt,insecure_locks,all_squash,sec=sys,anonuid=1024,anongid=100) root@DiskStation:/etc#
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 3.9G 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/music 7.2T 6.3T 939.7G 87% /storage/music 192.168.30.5:/volume1/Pictures 7.2T 6.3T 939.7G 87% /storage/Pictures 192.168.30.5:/volume1/quasar 7.2T 6.3T 939.7G 87% /storage/quasar 192.168.30.5:/volume1/quasararchive 7.2T 6.3T 939.7G 87% /storage/quasararchive 192.168.30.5:/volume1/Movies 7.2T 6.3T 939.7G 87% /storage/Movies 192.168.30.5:/volume1/downloads 7.2T 6.3T 939.7G 87% /storage/downloads 192.168.30.5:/volume1/TVShows 7.2T 6.3T 939.7G 87% /storage/TVShows LibreELEC:~ #
Too bad Kodi can't map this anymore directly or very slow. If I use the browse feature it is brutally slow but will find "192.168.30.5" and then again taking a long time it will find my share and then mount them. So I think the permissions are there but for some reason I can't access properly or something.
I came across something related to giving "Everyone" or "Everybody" access to the share but can't find that option in "File Station", only defined users that I have on the system even under System local account it points to "File Station". However people are indicating this isn't the ideal situation even if it works and pointed at the squash option which I've already experimented with.
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.
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.
On Thu, Nov 23, 2017 at 6:13 PM, bolmsted notifications@github.com wrote:
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.
That is ok. I am glad it works now.
Maybe you should use a hostname instead of a raw ip address :-) That is actually something that should go to the kodi wiki. Not just for NFS but for network assets in general. It would make changing the ip address of the server much easier.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sahlberg/libnfs/issues/232#issuecomment-346552694, or mute the thread https://github.com/notifications/unsubscribe-auth/AAeNkNU-jkxKDhWB7u15do5OFvxhZQEDks5s5SkbgaJpZM4Qma0G .
I'm not sure if most router OSes support a DNS configuration like this that gets propagated to local clients. I could setup BIND I guess in a Ubuntu machine running in a VM but seems a bit overkill for this but I've been using IP for a long time and working except when I reIPed. I have all of the IPs in the DHCP server statically for the most part, so perhaps it could be linked as a DDNS update.
You can also just use the /etc/hosts file on the kodi client, when/where you can access it, so you can do this without DNS.
On Thu, Nov 23, 2017 at 6:52 PM, bolmsted notifications@github.com wrote:
I'm not sure if most router OSes support a DNS configuration like this that gets propagated to local clients. I could setup BIND I guess in a Ubuntu machine running in a VM but seems a bit overkill for this but I've been using IP for a long time and working except when I reIPed. I have all of the IPs in the DHCP server statically for the most part, so perhaps it could be linked as a DDNS update.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sahlberg/libnfs/issues/232#issuecomment-346559666, or mute the thread https://github.com/notifications/unsubscribe-auth/AAeNkE2evnZ57Vlwg7UHge84LVcNlAblks5s5TJKgaJpZM4Qma0G .
oh of course. :) I was just thinking to have it propagate internally without host file updates. I'll look into the DNS on the router setup first.
It was suggested in the kodi forums that I post here and ask what is required for NFS browsing to work in Kodi. Further to that why I can’t access the content even if it was mounted previously and working. They seem to think it isn’t avahi requirement but what about mdns as I see packets in tcpdump output but this could be anything generated from kodi
My thread on kodi forums is https://forum.kodi.tv/showthread.php?tid=324431&pid=2670779#pid2670779