NFS not working in 9.97.1 Generic build

1st Official Post

    I wanted to try the new builds for the hope of HDR support on my 7gen NUC. I have tried the latest community edition for NUC's , and the latest official release. I moved from a working 9.2.x build that has been solid. I performed a clean install and Kodi will not mount my NFS shares. I have gone through and verified the settings of my NFS shares running on a Synology NAS. I went back to 9.2.6 and the shares mount without issue.

    When adding a source, Kodi can browse and discover the NFS share volumes but hangs when attempting to open them.

    Error in logs:

    Code
    DEBUG <general>: NFS: Context for 192.168.1.116/volume1/movies not open - get a new context.
ERROR <general>: NFS: Failed to mount nfs share: /volume1/movies (mount_cb: command timed out)
ERROR <general>: GetDirectory - Error getting nfs://192.168.1.116/volume1/movies/
ERROR <general>: CGUIDialogFileBrowser::GetDirectory(nfs://192.168.1.116/volume1/movies/) failed

    Full debug output:

    http://ix.io/3voK

    I see in the build notes, there are improvements to NFS. Any ideas what could be causing this?

    • Official Post

    I run LE 9.97.1 on a Raspberry Pi and Generic PC, and both are still working with my NFS sources: not Synology though, but Ubuntu Server.

    Synology is having a big DSM 7.0 rollout at the moment, did you already update your NAS?

    Thought I would look at the process as it traverses the network to see what is different. Im not a Wireshark expert but maybe someone can point out the differences and potential issues. The captures are at the NUC with a Plunder Bug with a filter showing all traffic to and from the IP of the NUC. In both instances I am adding a source to the file manager with browse -> NFS -> select IP of Synology share -> Select "movies" share path.

    9.2.6

    9.97.1

    One thing that stands out to me but don't know what it means. The initial calls are the same V2 NULL Call and Reply on Portmap protocol, the connection is reset, then there is a V3 NULL Call and Reply. Working 9.2.6 call is. with NFS protocol, not working 9.97.1 is with MOUNT protocol.

    Any ideas?

    Quote from duck7000

    On my libreelec generic Nfs is not working through the gui either, if i edit the sources.xml file manually it works flawlessly

    Just my thoughts

    I have tried this but get an error that it can not connect with the same entries as my first post.

    Edited once, last by bloodypiker: Wrong selection in 9.97.1 code (August 13, 2021 at 2:44 AM).

    Quote from Klojum

    Is that with a Syno NAS using DSM 7.0 ?

    No with Ubuntu server 20.04 so it may not be relevant here.

    Through the gui i can't even browse the network, gives error not available or something.

    I thought it may be related to this issue.

    I don't know if this is at all relevant to the thread or helpful in anyway, but... I have 9.97.1 generic on my Intel NUC and have had no problems with NFS whatsoever. It's a very basic installation with no add-ons. I have added a couple of NFS shares hosted on my QNAP NAS as sources via the Kodi GUI. (Using the QNAP's IP address.) This has worked flawlessly up until yesterday when I suddenly lost Internet connectivity. With Internet gone, Kodi could no longer connect to the QNAP shares. Other computers on my local network had no problems connecting to the QNAP shares. I logged in to the NUC/LibreELEC via SSH and tried mounting the QNAP shares manually from the command line and that worked without any problems. It was only accessing the shares via Kodi's GUI (Videos -> Files -> <share>) that failed. When Internet connectivity was restored, it was again possible to browse the shares via the GUI. I have no idea why loss of Internet connectivity would affect accessing NFS shares on a LAN using IPs and only via the GUI, but there you are. Unfortunately I didn't have time to create any debug logs before Internet connectivity was restored and I really don't want to experiment with disconnecting my WAN.

    Quote from AdmFubar

    I'm thinking it is a dns/dhcp issue. is your nas dynamic or static addressed? and are you using just the gateway as your sole router on your network?

    The NAS has a static IP address and is located on the same subnet as the NUC with LibreELEC. Both are connected via cable to the same switch which is plugged into one of my router's LAN ports. I used the static IP address for the NAS when I mapped the shares via Kodi's GUI. I can't see any valid reason for either DNS or DHCP being involved here and mounting the shares manually from the LibreELEC command line (while Internet was still down) worked fine. That being said, I suppose it could still be a DNS issue if browsing to a share via Kodi's GUI triggers a DNS lookup for some reason. Why it would need to do that to connect to a local share (using IP, not name) I don't know. I have the same shares mapped on a number of other systems in the house and they all worked perfectly fine. It was only trying to access the shares via the Kodi GUI that failed.

    Did you type the pathways into kodi, cut and paste, or update the config file directly?

    I'm thinking a spelling error in the path. the l's(L) and 1's (one) look a lot alike.

    copied the the error output from your first post into a text editor.. the 1's seem to be correct... next this to check is an errant space at the end of the nfs path.


    another thought just occurred to me, it needs dns because it needs to phone home... :O

    I need to check this out.

    Edited once, last by AdmFubar (September 2, 2021 at 8:38 PM).

    I see you are referring to the OP's first post here. Perhaps you were doing that in your previous post as well? I just assumed that you were replying to my (the latest) post... :)

    Anyway, I can subscribe to the "phone home" theory. It would be interesting to capture and analyze the traffic, i.e. see what happens when you browse to a NFS share (mapped with IP) via Kodi's GUI... Unfortunately, I'm not in a position to do that right now. Obviously my router couldn't forward any DNS queries when it had lost its Internet connection, so if a DNS lookup was made it would explain why Kodi couldn't connect to the share. There's still no valid reason for making a DNS lookup just to connect to a local share via its IP address, but who knows...