Description of problem: Kodi software scans the LAN (via portmapper I think), for any existing exported shares. It also accesses files with a URL like: "nfs://<server>/<share>" Mounting those shares (eg: mount -t nfs <server>/<share> <mountpoint>) then accessing the files via the mountpoint does work. This did work in previous kernel releases at least up to 4.9. It does not work for 4.10.13 or later. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1.export an nfs share on server. 2.install kodi, then try to browse nfs network (via kodi) 3.alternative: if possible, use URL like nfs://<server>/<share>/<file> Actual results: share directory not found Expected results: file on server share found Additional info: I have an old install of F24, with kernel 4.8, which works.
I'm a little unclear on the setup--are you running kodi and the nfs server on different machines? Is it just the NFS server that you upgraded? Would it be possible to find out how exactly it does the scanning? We're gradually deprecating NFSv2 and UDP, but I forget exactly where Fedora is in that process. I wonder if it depends on NFSv2 or UDP somehow. Possible ways to figure it out: look through Kodi code or documentation for references to NFS, or run wireshark while Kodi's scanning and watch what it's doing.
Sorry for the confusion. Typically kodi is running on an RPi (via osmc). That is running a debian spin. (4.4.27-9-osmc). The NFS server is on a Fedora (25) linux box. Running kodi on the same box as the server,though, gets the same results, as well as running it on Windoz 10 (I believe kodi uses libnfs built in, but probably an older version - see below). I upgraded both RPi and Linux within the last week. The scanning is via port 111 - portmapper -. Here is (byte) contents of the RPC, UDP "V2 CALLIT Call". This was captured by wireshark coming from osmc on an RPi. 5de237f50000000000000002000186a00000000200000005000000010000001c592837f5000000066c69626e66730000000003e8000003e8000000000000000000000000 Kodi should be available in repos for all flavors of linux. As for the source, that is on their web site kodi.org. As I said, libnfs is not a part of their source (I don't think it is even included in the source), it has to be built separately, then linked in. I will try to download the source and build it, hopefully with a newer version of libnfs (I am not sure how to build it for osmc, but will ask). And I don't have a Windoz box to build on. If NFS is being upgraded, and kodi is not taking that into account, that just might be the problem. Though, who fixes what will still be a question. thx, ken
Portmap isn't enough on its own, it probably does a portmap call then if it finds something it likes does some kind of MNT protocol call. If it's only getting as far as one portmap call then maybe it's not seeing support for the MNT or NFS version it wants? Anyway, it'd be useful to see the full exchange, if possible, so, something like: tcpdump -s0 -wtmp.pcap -i<network interface name here> then do whatever kicks off the scan, then attach a copy of tmp.pcap to this bug. (Consider taking a quick look at "wireshark tmp.pcap" first to make sure it didn't capture anything you consider confidential.) Is 4.4.27-9-osmc a kernel version? It might be interesting to know the Kodi or libnfs versions.
Created attachment 1282760 [details] capture as wireshark/tcpdump format for kodi portmap call
I think you are right: server doesn't recognize (or won't handle) this version of the portmap call. Oddly enough, I can mount a share on the RPi, and kodi will see files on that mount; doing it this way, kodi is relying on the os, since the path is a simple file:/// . Kodi only makes these three port map calls (as broadcasts). No other dialog between kodi and server. (see attachment) I think that osmc is based on kernel version 4.4.27-9, and is a debian spin. "OSMC" is the RPi version of kodi w/ the os; (fwiw: kodi is what used to be called xbmc - if that helps). But don't get to confused with this. Kodi nfs also does not work from windoz, nor from any other linux box.
Huh. Three identical calls each a second apart, no response: Portmap v2, CALLIT to program MOUNT v2 procedure NULL. Is it possible you changed any firewall settings? If it's not a firewall getting in the way then probably it's some change to nfs-utils, not the kernel. Do you know what version of nfs-utils you had in the working and non-working cases? Probably a bug for SteveD, anyway.
Created attachment 1282764 [details] kodi protmap and nfs dialog This is a capture of kodi accessing the nfs server via a mount on its system. This includes the 3 portmap calls, from a separate event in kodi, followed later by a dir listing from the server. Note that the two events are separate: the first three frames are me telling kodi to search for any nfs servers (portmap calls with no responses); the second (frames 4+) are me telling kodi to get a dir listing on a nfs mount (mounted via fstab). Hope that makes sense and help
Yeah, "Huh?" There is no firewall in the way. On the updated (not working) server: nfs-utils-2.1.1-5.rc2.fc25.x86_64. On a working F24 box: nfs-utils-1.3.4-1.rc3.fc24.i686 I have opened a bug with kodi for this. I believe that they are building kodi with an older version of libnfs, and something upgraded in the fc25 version that obsoleted something within kodi. Note again: accessing the nfs server via the built-in libnfs fails. Using nfs via the os does work (eg, I can mount a share and access it).
Just booted another old F25 linux box, and this may get confusing: boot with kernel 4.10.8-200, and nfs-utils-2.1.1-2.rc2.fc25.x86_64 works. boot with any kernel later than above, with any (older) version of nfs-utils, does NOT work. Ergo, I think, the problem may not be in nfs-utils, but somehow in a kernel mod. I really am just guessing here. I may try this: install F25 from original release; upgrade kernel version to 4.8.10-xxx, and see if nfs portmap scan works; if so, upgrade kernel by each release, and see when portmap fails. (Fortunately I have a local repo with most previous kernel and nfs-utils releases, and an unused box). That may take time for me, but if you have a setup to do something similar, I'd recommend that, just to get this resolved. For me, this is a critical issue, since it disables several apps I use. I did open a ticket with kodi, but have not heard back from them. thx everyone for the help.
Narrowed down the problem (I think): rpcbind crashes when it receives the portmap packet. This is from the systemctl log: May 30 17:23:30 Elmer systemd[1]: Starting RPC Bind... May 30 17:23:30 Elmer systemd[1]: Started RPC Bind. May 30 17:23:30 Elmer audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rpcbind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' May 30 17:23:30 Elmer kernel: audit: type=1130 audit(1496183010.130:1343): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rpcbind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' May 30 17:25:02 Elmer rpcbind[26808]: *** Error in `/usr/bin/rpcbind': free(): invalid pointer: 0x00007ffd4050e970 *** May 30 17:25:02 Elmer audit[26808]: ANOM_ABEND auid=4294967295 uid=32 gid=32 ses=4294967295 pid=26808 comm="rpcbind" exe="/usr/bin/rpcbind" sig=6 I started the rpcbind.service @17:23:30 (via systemctl start rpcbind.service). @17:25:02, I sent out the portmap CALLIT packet, where rpcbind proceeds to abort due to "invalid pointer". This also happens on another linux box (same os/version as server) on the lan. My older F24 box did not crash, although I get this continuously, every 5 seconds, in its journal: May 30 17:17:33 Taz kernel: NFS: state manager: check lease failed on NFSv4 server elmer with error 10021 (this may not be related to the real problem, tho). Hope this helps. ken
Created attachment 1283861 [details] gdb trace receiving CALLIT rpc This is a gdb backtrace (on another linux box on the network) of when my app (kodi) sends out the CALLIT portmap call. It is rpcbind that is causing the problem. It aborts trying to free up memory. The section in rpcbproc_call_it_com that does the jump to the "error:" label is line 713 in rpcb_svc.com.c: if (rbl->rpcb_map.r_vers != a.rmt_vers) { if (reply_type == RPCBPROC_INDIRECT) { rpcvers_t vers_low, vers_high; find_versions(a.rmt_prog, transp->xp_netid, &vers_low, &vers_high); svcerr_progvers(transp, vers_low, vers_high); } goto error; } I noticed that there were some patches applied to the previous version near this section of code. Maybe that caused this problem? This is getting a little bit over my head - not really knowing the code (that I got this far amazes me). Let me know what you think is going on. BTW: should this be changed from "nfs" to "rpcbind"? thx. ken
*** This bug has been marked as a duplicate of bug 1450765 ***