Kodi 17 - NFS Browsing issue

[Dirk Laurenz]

Hello @all,

i have a nice issue with NFS browsing. I have 4 NFS Servers. When i start adding an additional path in Kodi and i klick an nfs, nornmally all servers are enumerated. But currently only 3 of 4 are enumerated.The one which is missing, is with all source nfs shares.... Kodi can access all files, scan and so on, but it does not show it when enumerating the servers

the one which is missing is a qnap with qts 4.3, the others are a qnap with qts 4.2 and to raspberry pi.... (with shared files for kodi).

This happens on both - windows (store app and native app) and rapsberry pi (osmc)

showmount -e from any linux client shows all shares....

don't know where to start debugging....

NFS Version is 2/3 v4 is not enabled...

Exports are identically - so from my point of view - how does browsing for nfs shares work...


Working one:
"/share/MD0_DATA/Public" *(rw,async,no_subtree_check,insecure,no_root_squash)

Not working one:
"/share/MD0_DATA/Public" *(rw,async,no_subtree_check,insecure,no_root_squash)

both hosts are on the same subnet (192.168.2.70 and .72)

the thing is, as i installed kodi - it worked - and what is interesstings it, that it's the same from windows kodi and linux kodi....
more over, access nfs is fine....there's one difference in the servers, the one which does not work has a newer qnap OS (4.3) the one which works has 4.2

[ronnie sahlberg]

So the only difference is basically the version of qts?

Libnfs uses the same method to discover the nfs servers as the rpcinfo
tool does, if you run :

'rpcinfo -b 100005 2'

Thy running that command and see if that gives the same result, i.e.
it only finds 3 out of the 4 servers.


The way this process works is basically to send a UDP broadcast for
each local network interface.
This broadcast is sent to UDP port 111 and it contains a
PORTMAPPER-CALLIT command to search
for program 100005 (the mount daemon) and protocol version 2.
The idea is then that IF there is a mount daemon on the host that
supports MOUNT protocol version 2, it will then send
a reply back to libnfs/rpcinfo and in libnfs we just keep track of
who responded to us.
That is how we discover where/which nfs servers are present.

Unless something is really buggy, libnfs should use the same process
as the command above.


Two things that could go wrong on qts 4.3 could be :
1, Maybe it only supports the portmapper using TCP and not UDP ? The
server discovery part is the only time libnfs will use UDP
so if qts4.3 no longer supports portmapper on UDP port 111, then both
libnfs and the rpcinfo command will fail.

You can check if this is the case by running rpcinfo without any
arguments on the qts4.3 host.
It should contain a few lines looking something like this :
100000 2 udp 0.0.0.0.0.111 portmapper superuser

100000 means 'portmapper', 0.0.0.0 means that it listens on every
interface and .111 means port 111.

Do the same on the qts4.2 boxens and make sure they look similar.


On both of them there should also be lines that mention that the mount
service is available.
This lines should look something like
100005 2 udp 0.0.0.0.<something>.<something> ....

Make sure this is similar between qts4.3 and qts4.2. We need the
mount program version 2 to be available for UDP on the server.
Note that since the mount protocol does not use a hardcoded UDP port,
<something>.<something> will be different numbers
between all the servers.

> --
> You received this message because you are subscribed to the Google Groups
> "libnfs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to libnfs+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[ronnie sahlberg]

Dirk,

Can you check if possibly this is what you could be affected by :

https://bugzilla.redhat.com/show_bug.cgi?id=1455708

On recent kernel/nfs-utils, portmapper segfault on the
PORTMAPPER/CALLIT command that
libnfs use to discover local nfs servers.

[Dirk Laurenz]

Hi,

i run rpcinfo as you requested and the qts 4.3 box is missing...

hier ist he output from qts 4.2:

rpcinfo - command not found - and also on the 4.3 box

could netstat help? That command exists on qts..

-----Ursprüngliche Nachricht-----
Von: lib...@googlegroups.com [mailto:lib...@googlegroups.com] Im Auftrag von ronnie sahlberg
Gesendet: Freitag, 2. Juni 2017 17:08
An: lib...@googlegroups.com
Betreff: Re: Kodi 17 - NFS Browsing issue

You received this message because you are subscribed to a topic in the Google Groups "libnfs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libnfs/UAyNNu0Z27Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to libnfs+un...@googlegroups.com.

[ronnie sahlberg]

On Sun, Jun 4, 2017 at 10:11 AM, Dirk Laurenz <di...@laurenz.ws> wrote:
> Hi,
>
> i run rpcinfo as you requested and the qts 4.3 box is missing...

So when you run rpcinfo -b 100005 2 it does not show qts 4.3 ?
Then it is clear that there is something wrong with it and you should
contact the qts folks.

>
> hier ist he output from qts 4.2:
>
> rpcinfo - command not found - and also on the 4.3 box

You can fetch this information remotely using rpcinfo.
So, from one machine where you do have rpcinfo, run
rpcinfo <ip-address-of-the-qts-box>

and you should get the list of services and protocols that the box provides.

[Dirk Laurenz]

That's the qts 4.3:

root@router01:~# rpcinfo nas01
program version netid address service owner
100000 4 tcp 0.0.0.0.0.111 portmapper superuser
100000 3 tcp 0.0.0.0.0.111 portmapper superuser
100000 2 tcp 0.0.0.0.0.111 portmapper superuser
100000 4 udp 0.0.0.0.0.111 portmapper superuser
100000 3 udp 0.0.0.0.0.111 portmapper superuser

100000 2 udp 0.0.0.0.0.111 portmapper superuser

100000 4 local /var/run/rpcbind.sock portmapper superuser
100000 3 local /var/run/rpcbind.sock portmapper superuser
100011 1 udp 0.0.0.0.117.50 rquotad superuser
100011 2 udp 0.0.0.0.117.50 rquotad superuser
100011 1 tcp 0.0.0.0.117.50 rquotad superuser
100011 2 tcp 0.0.0.0.117.50 rquotad superuser
100005 1 udp 0.0.0.0.117.48 mountd superuser
100005 1 tcp 0.0.0.0.117.48 mountd superuser
100005 2 udp 0.0.0.0.117.48 mountd superuser
100005 2 tcp 0.0.0.0.117.48 mountd superuser
100005 3 udp 0.0.0.0.117.48 mountd superuser
100005 3 tcp 0.0.0.0.117.48 mountd superuser
100003 2 tcp 0.0.0.0.8.1 nfs superuser
100003 3 tcp 0.0.0.0.8.1 nfs superuser
100227 2 tcp 0.0.0.0.8.1 - superuser
100227 3 tcp 0.0.0.0.8.1 - superuser
100003 2 udp 0.0.0.0.8.1 nfs superuser
100003 3 udp 0.0.0.0.8.1 nfs superuser
100227 2 udp 0.0.0.0.8.1 - superuser
100227 3 udp 0.0.0.0.8.1 - superuser
100021 1 udp 0.0.0.0.151.42 nlockmgr superuser
100021 3 udp 0.0.0.0.151.42 nlockmgr superuser
100021 4 udp 0.0.0.0.151.42 nlockmgr superuser
100021 1 tcp 0.0.0.0.130.30 nlockmgr superuser
100021 3 tcp 0.0.0.0.130.30 nlockmgr superuser
100021 4 tcp 0.0.0.0.130.30 nlockmgr superuser
100024 1 udp 0.0.0.0.117.49 status superuser
100024 1 tcp 0.0.0.0.117.49 status superuser


And that's qts 4.2

root@router01:~# rpcinfo nas02
program version netid address service owner
100000 4 tcp 0.0.0.0.0.111 portmapper superuser
100000 3 tcp 0.0.0.0.0.111 portmapper superuser
100000 2 tcp 0.0.0.0.0.111 portmapper superuser
100000 4 udp 0.0.0.0.0.111 portmapper superuser
100000 3 udp 0.0.0.0.0.111 portmapper superuser

100000 2 udp 0.0.0.0.0.111 portmapper superuser

100000 4 local /var/run/rpcbind.sock portmapper superuser
100000 3 local /var/run/rpcbind.sock portmapper superuser
100011 1 udp 0.0.0.0.117.50 rquotad superuser
100011 2 udp 0.0.0.0.117.50 rquotad superuser
100011 1 tcp 0.0.0.0.117.50 rquotad superuser
100011 2 tcp 0.0.0.0.117.50 rquotad superuser
100005 1 udp 0.0.0.0.117.48 mountd superuser
100005 1 tcp 0.0.0.0.117.48 mountd superuser
100005 2 udp 0.0.0.0.117.48 mountd superuser
100005 2 tcp 0.0.0.0.117.48 mountd superuser
100005 3 udp 0.0.0.0.117.48 mountd superuser
100005 3 tcp 0.0.0.0.117.48 mountd superuser
100003 2 tcp 0.0.0.0.8.1 nfs superuser
100003 3 tcp 0.0.0.0.8.1 nfs superuser
100227 2 tcp 0.0.0.0.8.1 - superuser
100227 3 tcp 0.0.0.0.8.1 - superuser
100003 2 udp 0.0.0.0.8.1 nfs superuser
100003 3 udp 0.0.0.0.8.1 nfs superuser
100227 2 udp 0.0.0.0.8.1 - superuser
100227 3 udp 0.0.0.0.8.1 - superuser
100021 1 udp 0.0.0.0.146.23 nlockmgr superuser
100021 3 udp 0.0.0.0.146.23 nlockmgr superuser
100021 4 udp 0.0.0.0.146.23 nlockmgr superuser
100021 1 tcp 0.0.0.0.200.49 nlockmgr superuser
100021 3 tcp 0.0.0.0.200.49 nlockmgr superuser
100021 4 tcp 0.0.0.0.200.49 nlockmgr superuser
100024 1 udp 0.0.0.0.117.49 status superuser
100024 1 tcp 0.0.0.0.117.49 status superuser

-----Ursprüngliche Nachricht-----
Von: lib...@googlegroups.com [mailto:lib...@googlegroups.com] Im Auftrag von ronnie sahlberg

Gesendet: Sonntag, 4. Juni 2017 19:20

[Dirk Laurenz]

I opend a call at qnap - let's see how they react

-----Ursprüngliche Nachricht-----
Von: lib...@googlegroups.com [mailto:lib...@googlegroups.com] Im Auftrag von ronnie sahlberg

Gesendet: Sonntag, 4. Juni 2017 19:20

[ric...@gmail.com]

Hi Dirk, Ronnie

'Just wanted to pitch in with my 2c.

I have a QNAP TS-251A which is behaving just like Dirk's: "rpcbind -b" commands aren't returning anything, for any service.

Other devices in the network with active portmappers do reply and show up in the "rpcbind -b" output.

I've been able to confirm that the UPD broadcast packets are getting to the QNAP's network interface, but now have no firm idea why the thing isn't replying back.

I have a suspicion that this might have to do with a feature called "Virtual Switch" that QNAP rolled out with its 4.3 FW.

Let me know if you have any further insight or ideas.

Cheers,

Ricardo

[Dirk Laurenz]

Hi,

 

the last firmware fixed this….QNAP is browsable again from kodi

[Ricardo Carvalhosa]

I second this: it was fixed a couple of Qnap beta FWs versions ago (last month).

Cheers

On Jan 6, 2018 14:18, "Dirk Laurenz" <di...@laurenz.ws> wrote:

Hi,

 

the last firmware fixed this….QNAP is browsable again from kodi

To unsubscribe from this group and all its topics, send an email to libnfs+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "libnfs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/libnfs/UAyNNu0Z27Q/unsubscribe.

To unsubscribe from this group and all its topics, send an email to libnfs+unsubscribe@googlegroups.com.