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

    • OMV 3.x
    • Resolved
    • [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.

      The post was edited 1 time, last by iF*73: Edited to include solution. ().

    • 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.
    • iF*73 wrote:

      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.

      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

      The post was edited 1 time, 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. :/
    • iF*73 wrote:

      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


      iF*73 wrote:

      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.

      iF*73 wrote:

      /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
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • 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.

      subzero79 wrote:

      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?
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • 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. ?(
    • iF*73 wrote:

      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
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • 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.

      Source Code

      1. ● nfs-kernel-server.service - LSB: Kernel NFS server support
      2. Loaded: loaded (/etc/init.d/nfs-kernel-server)
      3. Active: active (running) since Tue 2018-03-06 08:59:35 GMT; 44s ago
      4. Process: 30899 ExecStart=/etc/init.d/nfs-kernel-server start (code=exited, status=0/SUCCESS)
      5. CGroup: /system.slice/nfs-kernel-server.service
      6. └─30923 /usr/sbin/rpc.mountd --manage-gids
      7. Mar 06 08:59:35 nas-pi nfs-kernel-server[30899]: Exporting directories for N....
      8. Mar 06 08:59:35 nas-pi rpc.mountd[30923]: Version 1.2.8 starting
      9. Mar 06 08:59:35 nas-pi nfs-kernel-server[30899]: Starting NFS kernel daemon:....
      10. Mar 06 08:59:35 nas-pi systemd[1]: Started LSB: Kernel NFS server support.
      11. Hint: Some lines were ellipsized, use -l to show in full.
      Display All
      modinfo nfsd

      Source Code

      1. filename: /lib/modules/4.9.59-v7+/kernel/fs/nfsd/nfsd.ko
      2. license: GPL
      3. author: Olaf Kirch <okir@monad.swb.de>
      4. alias: fs-nfsd
      5. srcversion: E3336793B982D90DC0192EF
      6. depends:
      7. intree: Y
      8. vermagic: 4.9.59-v7+ SMP mod_unload modversions ARMv7 p2v8
      9. parm: cltrack_prog:Path to the nfsdcltrack upcall program (string)
      10. parm: cltrack_legacy_disable:Disable legacy recoverydir conversion. Default: false (bool)
      11. parm: nfs4_disable_idmapping:Turn off server's NFSv4 idmapping when using 'sec=sys' (bool)
      Display All

      uname -r

      Source Code

      1. 4.9.59-v7+

      iptables -vnL

      Source Code

      1. Chain INPUT (policy ACCEPT 1631 packets, 346K bytes)
      2. pkts bytes target prot opt in out source destination
      3. Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
      4. pkts bytes target prot opt in out source destination
      5. Chain OUTPUT (policy ACCEPT 3510 packets, 4448K bytes)
      6. 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

      Source Code

      1. /export/test 192.168.1.125/24(rw,wdelay,insecure,root_squash,fsid=1,sec=sys,rw,root_squash,no_all_squash)
      2. /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.
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server