[SOLVED] NFS share not visible to Kodi (or anything else)

  • Hi all,


    My NFS share is not visible to any other device on the network and it's driving me mad trying to troubleshoot what might be wrong. I feel that there's something obvious that I'm missing but cannot see the wood for the trees, so to speak. I'm new(ish) to OMV, am a mid-level Linux user but am new to NFS.


    I'm running OMV 3.0.98 on a Raspberry Pi 3, with an external USB hard drive and sharing folders successfully with SMB. I have just installed Kodi on a Pi 2 to use as a media server that I want to connect to the OMV/Pi3 NAS drive (where all the media files reside). I want to use NFS rather than SMB because of its (apparently) lower CPU overhead.


    In the OMV GUI, I've created a shared folder (/media), enabled NFS and added the shared folder, initially with the default shared options of (rw,secure) and with read/write privileges. When editing the share in the NFS configuration panel, under the Shared folder box appears the following text: The location of the files to share. The share will be accessible at /export/


    I'm therefore expecting that the share will be visible on 192.168.1.125/24 and have used this in the Kodi interface to find the shared files. It finds nothing. I've tried various versions of a potential URL such as 192.168.1.125/24/export/ and 192.168.1.125/export/ but the share remains invisible on the network to any of my devices.


    After some online searching, I was advised to add a Kodi user to OMV and to change the share's options to subtree_check,insecure,all_squash,anonuid=1002,anongid=100 where anonuid is the guid of the Kodi user.


    This has made no difference to the visibility of the share. :(


    I am now going around in circles and making no meaningful progress in solving this problem. I'll be very grateful for some guidance on this. Again, I feel that there is something obvious that I am missing.


    Thanks.



    [Edit: SOLVED]


    TL;dr Kodi on Arch Linux does not support NFS by default. Install libnfs on the arch linux box to fix this. When configuring the NFS share in OMV, make sure you enter the client IP address not the server IP address! Share options rw,subtree_check,insecure seem to work well for most users.

  • Thanks! That would be the obvious thing that has eluded me :)


    Alas, I still cannot connect and get the following error message when I try to add 192.168.1.125/export/movies as a new network location within the Kodi GUI:
    Unable to connect. The connection to the network couldn't be established. This could be due to the network not being connected. Would you like to add it anyway?


    I have checked on the server (Pi3 running OMV) that the /export/movies directory exists, and it does (and contains multiple video files) so files are in the expected place. The NFS share has been created and yet I cannot connect to it.


    What other diagnostics can I try? I cannot believe this is really as difficult as I am finding it to be.


    Thanks again for your help.


  • Changing "secure" in extra options to "insecure" did it for me. I am able to connect to the share from Kodi on everything from a CU-Boxi, Pi3, PC, Android, etc....



    OMV 4.x
    Supermicro X9DRH-7F
    2X-XEON E5-2660V2
    32GB PC3-10600R ECC REG
    Supermicro SATA DOM 64GB
    Areca ARC-1883IX-24
    24X - WD WD80EFZX
    NORCO RPC-4224 4U
    Eaton 5PX 1500

    Edited once, last by mikebetz42 ().

  • Thanks mikebetz42 and subzero79 for your suggestions. Neither of them have worked. :( I am now wondering whether the NFS share is even visible on the network and/or whether OMV is behaving correctly for me.


    I have only ever used the OMV GUI to set up the NFS share and assumed that the necessary files, folders and permissions would be created as a consequence of this. Not so. For example, /export had not been created and only appeared after I issued exportfs -a from the CLI of the server.


    I have made multiple NFS share configuration changes in the OMV GUI as I've tried to find the right combination of options to make the share visible to the Kodi client. The server's current output from exportfs -v is


    root@pi-nas:/export# exportfs -v


    /export/movies 192.168.1.125/24(rw,wdelay,insecure,root_squash,fsid=1,sec=sys,rw,root_squash,no_all_squash)


    /export 192.168.1.125/24(ro,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,ro,root_squash,no_all_squash)



    I do not know why I seem to have two shares when the OMV GUI indicates that I only have one, and why are there so many options specified when I only have subtree_check,insecure specified in the GUI.


    If there wasn't confusing enough, I checked on the server to see if the nfs service was even running. No it was not! This probably explains why the Kodi client could never connect.


    root@pi-nas:/export# service nfs status


    ● nfs.service


    Loaded: not-found (Reason: No such file or directory)


    Active: inactive (dead)



    What should I try next to get OMV to share via NFS correctly? If there a way of resetting or deleting all NFS settings and starting from scratch? I'm open to all suggestions.


    BTW OMV is currently sharing two folders with SMB without problems. Can you run NFS and SMB concurrently?


    Thanks again, and sorry for this rather confusing post. It reflects my thinking at the moment. :/

  • I do not know why I seem to have two shares when the OMV GUI indicates that I only have one, and why are there so many options specified when I only have subtree_check,insecure specified in the GUI.

    One is the share one is the pseudo rootfs, please read the wiki.
    Those options are the ones reported by exportfs -v, the settings are in /etc/export, fsid is added to every nfs share by omv configuration backend



    service nfs status

    Is nfs-kernel-server unit, there is a dashboard also in the web panel that indicates the service status. Please do not shoot in the air. By all your comments seems like you've ever used NFS.

    /export/movies 192.168.1.125/24(

    Why are you using network security? you should leave that out for testing now.


    Also just check the service is running in the dashboard or with systemctl status nfs-kernel-server. If this is a rpi and you did not wait enough time for the first boot with internet (30 minutes) then i can see why are you having problems, specially with NFS

  • Thanks for your reply. You are right that I have never used NFS before and am only doing so in response to general advice about using NFS in preference to SMB in underpowered CPU devices like the RPi.


    The OMV web panel (Services) indicates that NFS is enabled and running but I cannot connect to the server from any client, Kodi or otherwise. This is my ongoing problem for which I am seeking a solution.


    If this is a rpi and you did not wait enough time for the first boot with internet (30 minutes) then i can see why are you having problems, specially with NFS

    I do not understand the significance of this comment. Could you please elaborate?


    If you set aside my obvious ignorance of the detail of NFS, what can I do to make this connection? I seem to be having more trouble with this than is necessary or is usual.


    Thanks again.

  • Rpi images perform several tasks at first boot. One of them is installing a kernel that comes more with more modules than the default armbian, including nfsd.
    Is the readme of where you download the images.


    In you r case seems to be working, at least the dashboard shows running. Last test remove the network security in the share and try again.
    If that didn’t work, then reflash the image and let the server run alone for at least 30 minutes with internet, then login and reconfigure again.


    What is the kodi client os? Libreelec openelec?

  • Thanks.


    Kodi client OS is Arch Linux 4.14.22.


    It makes sense to reflash and start again. Configuration is quite straightforward when you've had so much practice with the GUI :)


    I will be sure to wait at least 30 minutes to let the server run and complete its tasks before making any further configuration changes.

  • showmount -e 192.168.x.x generates error clnt_create: RPC: program not registered. I had struck that error previously when I was trying to see if the NFS shares were visible from a client. I chose not to go down another rabbit hole and instead I have spent the last few hours reflashing and reconfiguring OMV in an attempt to get NFS shares working. I have failed. The behaviour I see is exactly the same as previously: the Kodi client cannot see any of the NFS shares. However, SMB is working fine.


    Despondent and defeated, I thought that DLNA might be an alternative way of sharing OMV content with Kodi, and one that should "just work" if the hype around UPnP is to be believed.


    (I know this is off topic, but please bear with me)


    I installed the minidlna plugin, set up the shares and connected two clients to the server: Kodi on the Arch Linux box and an Android app (Localcast) that can talk to UPnP servers.


    Both clients can see the server but can see no content. The only folders visible are generic ones that contain no files. (Browse Folders, Music, Pictures, Video.)


    This leads me to believe that there is something more fundamentally wrong in my OMV. Permissions maybe? I'm too close to it all right now to troubleshoot, but nothing obvious is sticking out at me. My setup is not complex. minidlna system user has read/write access to the media folders. Everything else looks fine, but the clients cannot see any media content. ?(

  • showmount -e 192.168.x.x generates error clnt_create: RPC: program not registered. I had st

    That error.....means there is no NFS kernel server running. Check this in omv terminal


    systemctl status nfs-kernel-server
    exportfs -v
    modinfo nfsd
    uname -r
    iptables -vnL



    post the output here

  • systemctl status nfs-kernel-server Note that I had just re-enabled NFS prior to running this, having previously disabled it while investigating DLNA options. That explains the 44s active time.

    modinfo nfsd


    uname -r

    Code
    4.9.59-v7+


    iptables -vnL

    Code
    Chain INPUT (policy ACCEPT 1631 packets, 346K bytes)
    pkts bytes target prot opt in out source destination
    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    Chain OUTPUT (policy ACCEPT 3510 packets, 4448K bytes)
    pkts bytes target prot opt in out source destination
  • Sorry, my mistake. When I ran the command initially, it returned no values. This is because I had turned NFS sharing off. Current output shown below, based on a single NFS share 'test'.


    exportfs -v

    Code
    /export/test 192.168.1.125/24(rw,wdelay,insecure,root_squash,fsid=1,sec=sys,rw,root_squash,no_all_squash)
    /export 192.168.1.125/24(ro,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,ro,root_squash,no_all_squash)

    I have tried with and without /24 at the end of the IP string and the result is the same.

  • Sorry I have no answers for your problem. You can try booting another live distro to perform nfs operations in that machine to discard server problems and possibly narrrow it to the client.


    A test you can do in nfs server (Omv)



    mount -t nfs 127.0.0.1:/export/test /mnt



    Go to /mnt to check contents match the test folder.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!