[Anothers]

I have been running MythTV as my home PVR system for over 10 years.

I run my mythbackend on a Fedora 25 server with the firewall active as even on a closed network it's good security practice.

I have a number of mythfrontends but was attracted to using Kodi as the Kodi frontend seems more complete then mythfrontend on Android devices which the kids use (mainly Samsung 10.5" Tablets and their friends can then access the server easily when they're visiting if the have Tablets or Ipads with them).

I have spent a week faffing around with this and have come to the following thoughts.

NFS is not being properly implemented on the Kodi client.

The evidence I offer for this is as follows.

I have a specific machine (TestM) I use as a Dev/Test box that I use to tinker before making any changes to the live production server (ProdM).

I have setup NFS shares on TestM following the assorted guides dotted around and could not get the Kodi clients to connect to and then scan the way it was supposed to.

There doesn't seem to be a comprehensive discussion of firewall settings anywhere on this forum (the internal search won't work as NFS is too short for a forum search and using google to search throws up assorted threads but again none of them are comprehensive guides to what needs to be done).

Live PVR TV services are working on TestM from Android Tablet and Ubuntu desktop clients the way I would expect.

Anyhoo.....

Using the following NFS export settings on TestM a Fedora 25 server:-

/mnt/RAID/mythfiles/mediafiles 192.168.1.0/24(ro,wdelay,insecure,root_squash,all_squash,no_subtree_check)

With the TestM firewall turned on......

This will not scan or browse from either the Android Kodi client or the Ubuntu Client

With the TestM firewall turned off.....

This scans perfectly with both clients as it should

With the TestM firewall turned on and NFS and RPC-Bind services opened

No scanning from either client

I have then on the TestM firewall port settings also opened ports, 111 UDP and TCP, 2049 UDP and TCP.

Now as I stated above as I cannot find a comprehensive guide to what the firewall setting should be I cannot really take this further easily.

What conclusions I am taking from this is the Kodi client is not conforming to the ports required for NFS services as 'standard'. In my opinion opening NFS and RPC-BIND services on my TestM server firewall should allow Kodi to work unless I'm provided extra information regarding extra ports.

The fact that turning the firewall off allows it to work immediately without any other changes point to the firewall being the issue, however finding an accepted solution is a real challenge.

Can anyone help?

Could one of the Devs/Mods possibly develop a comprehensive Firewall Guide for Kodi and post it somewhere appropriate?

Thanks in advance.

[wsnipex]

your firewall settings assume standard (kernel level) NFS, which requires root.
Kodi does not require root and should never be run as root. Therefore a userland library(libnfs) is used, which uses random high ports. This is also the reason for the "insecure" flag on your exports.

[Anothers]

your firewall settings assume standard (kernel level) NFS, which requires root.
Kodi does not require root and should never be run as root. Therefore a userland library(libnfs) is used, which uses random high ports. This is also the reason for the "insecure" flag on your exports.

What?

Kodi isn't running as root as it's running on different physical machines then the TestM server, specifically an Android Tablet and a Ubuntu desktop as outlined in the OP.

[wsnipex]

Therefore a userland library(libnfs) is used, which uses random high ports. This is also the reason for the "insecure" flag on your exports.

if that was unclear for you: an application running without root cannot use standard NFS ports.

[Anothers]

Therefore a userland library(libnfs) is used, which uses random high ports. This is also the reason for the "insecure" flag on your exports.

if that was unclear for you: an application running without root cannot use standard NFS ports.

Please quote your source to support this statement.

[nickr]

There is some comment here https://github.com/sahlberg/libnfs

[wsnipex]

Therefore a userland library(libnfs) is used, which uses random high ports. This is also the reason for the "insecure" flag on your exports.

if that was unclear for you: an application running without root cannot use standard NFS ports.

Please quote your source to support this statement.

this is how unix and therefore linux works. Do your own homework please.

[lua2]

Still an issue, so I'll go ahead and share my homework

Kodi uses LIBNFS to access nfs shares. The library defaults to nfs3, but can also be set to call nfs4 (see the README of the github link above). This way you could set up shares under version 4 and be fine accesing them with a single port open. didn't do it though and can't confirm it works.

If you stick with nfs3, you can also bind RPCBind to a static port on the nfs server, instead of letting MOUNT-D assign random ones. This is done in /etc/default/nfs-kernel-server by changing RPCMOUNTDOPTS="--manage-gids"
 to RPCMOUNTDOPTS="--port <your port of choice>". More detail on that at https://blog.kevinckurtz.com/nfs-on-rasp...-from-kodi. Worked for me with Kodi 18.5 and a nfs share on debian 10.

[Preacher]

if that was unclear for you: an application running without root cannot use standard NFS ports.

Please quote your source to support this statement. 

this is how unix and therefore linux works. Do your own homework please. 

Just to clarify: it's not possible to bind to ports below 255 with unprivileged access, so you can't run a non-root NFS server... or rather, you can't run any service that opens a port < 255

However, you don't need privileged access to connect to a port below 255 - the outgoing connection will be on a number >1024 (usually).

I'm unclear from the original problems specification what the networking looks like... but could it help to run a TCPDUMP on the NFS server to see what incoming connections are being made? 

Also: "The fact that turning the firewall off allows it to work immediately without any other changes point to the firewall being the issue, however finding an accepted solution is a real challenge." - s the FW actually blocking any outgoing connections at all?