Not starting NFS kernel daemon: no support in current kernel on 3.0.94 RPI3

    • OMV 3.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Not starting NFS kernel daemon: no support in current kernel on 3.0.94 RPI3

      I am running OVM Erasmus 3.0.94 on an RPI3. The original image was downloaded from OMV_3_0_88_RaspberryPi_2_3_4.9.41 and then apt-get update/upgrade to the latest. The included kernel does not appear to have NFS support. I am seeing the following warning in the system logs...

      Dec 18 14:45:50 omv nfs-kernel-server[13703]: Not starting NFS kernel daemon: no support in current kernel. ... (warning).

      Do I need a different kernel to get NFS support? Or can I enable this by installing some kernel module packages?

      TIA.
    • a hwang wrote:

      The original image was downloaded from OMV_3_0_88_RaspberryPi_2_3_4.9.41 and then apt-get update/upgrade to the latest.
      Which is an indication that you somehow interfered with 'first boot' procedure. Quoting the readme at the download page:

      Source Code

      1. Write the .img.xz image in a single step using Etcher https://etcher.io
      2. to SD card. On first boot the installation will be finished. REMAIN PATIENT
      3. PLEASE since this can take up to 30 minutes with a slow SD card and slow
      4. internet connection (needs internet access to update all packages to latest
      5. version). After one automatic reboot green activity led stops blinking and
      6. then your Raspberry Pi is ready!
      Just start again from scratch, connect the RPi to Ethernet/Internet, boot the image and remain patient. Everything will work afterwards and you will be already on OMV 3.0.94 and kernel 4.9.59 (if you have a lower kernel version again something went wrong!).

      If you're really experienced you could also try to fix your installation (a lot of instructions that usually run on 1st boot have not been executed -- here's the list but I would really recommend to simply start over again and this time follow the readme)

      The post was edited 1 time, last by tkaiser ().

    • a hwang wrote:

      I'll start from scratch and see how it goes
      That's definitely the best idea though this 'finish installation on 1st boot' attempt is designed to cope with situations like network interruptions. /etc/init.d/firstrun should be started with every reboot until installation succeeds. But we had more than one report indicating the opposite so the save way is really to start over and be patient on first boot :)

      In case you run into further problems please activate SSH access, login to your RPi and provide 'sudo armbianmonitor -u' output...
    • I started from scratch and just let it boot up all night. I could not figure out where the green light in "green activity led stops blinking" is supposed to be. So to be safe, I just let booted it up from fresh and left it for the night.

      That seems to have done the trick. NFS is now working for me. Thanks for the help.
    • a hwang wrote:

      That seems to have done the trick. NFS is now working for me
      Well, what happened is that the necessary packages from raspberrypi.org have been installed (see these three commands that were executed, the important packages are firmware-brcm80211, raspberrypi-bootloader, raspberrypi-kernel and libraspberrypi-bin). When you tried first this had been interupted and that's why the kernel missed the modules. Now everything is ok and most importantly once RPi folks provide kernel updates (with eg. security fixes) you get them without any hassles.
    • tkaiser wrote:

      a hwang wrote:

      The original image was downloaded from OMV_3_0_88_RaspberryPi_2_3_4.9.41 and then apt-get update/upgrade to the latest.
      Which is an indication that you somehow interfered with 'first boot' procedure. Quoting the readme at the download page:

      Source Code

      1. Write the .img.xz image in a single step using Etcher https://etcher.io
      2. to SD card. On first boot the installation will be finished. REMAIN PATIENT
      3. PLEASE since this can take up to 30 minutes with a slow SD card and slow
      4. internet connection (needs internet access to update all packages to latest
      5. version). After one automatic reboot green activity led stops blinking and
      6. then your Raspberry Pi is ready!
      Just start again from scratch, connect the RPi to Ethernet/Internet, boot the image and remain patient. Everything will work afterwards and you will be already on OMV 3.0.94 and kernel 4.9.59 (if you have a lower kernel version again something went wrong!).

      If you're really experienced you could also try to fix your installation (a lot of instructions that usually run on 1st boot have not been executed -- here's the list but I would really recommend to simply start over again and this time follow the readme)
      Thanx a lot for this info it helped me to figure out why my nfs kernel wasn't working!
      Now that i got it running i still can't mount it on my devices... This is what i get:

      /etc/init.d/nfs-kernel-server status -l
      nfs-kernel-server.service - LSB: Kernel NFS server support
      Loaded: loaded (/etc/init.d/nfs-kernel-server)
      Active: active (running) since Tue 2017-12-19 23:27:20 CET; 21min ago
      CGroup: /system.slice/nfs-kernel-server.service
      └─5480 /usr/sbin/rpc.mountd --manage-gids

      Dec 19 23:27:20 raspberrypi systemd[1]: Started LSB: Kernel NFS server support.
      Dec 19 23:28:01 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for / (/): not exported
      Dec 19 23:28:03 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for /export/Film (/export/Film): illegal port 56699
      Dec 19 23:28:04 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for /export/Film (/export/Film): illegal port 56708
      Dec 19 23:28:05 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for /export/Film (/export/Film): illegal port 56716
      Dec 19 23:34:30 raspberrypi rpc.mountd[5480]: authenticated mount request from 192.168.1.139:947 for /export (/export)
      Dec 19 23:34:33 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for /exports (/): not exported
      Dec 19 23:34:33 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for /exports (/): not exported
      Dec 19 23:34:37 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for / (/): not exported
      Dec 19 23:34:37 raspberrypi rpc.mountd[5480]: refused mount request from 192.168.1.139 for / (/): not exported


      What am i missing?!
    • anatema wrote:

      Does that effect the NFS?
      Probably. NFS is probably the most sensitive service to the filesystem and really should use a native linux filesystem.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      anatema wrote:

      Does that effect the NFS?
      Probably. NFS is probably the most sensitive service to the filesystem and really should use a native linux filesystem.
      Thanx for the reply! Do you think its worth to format my drive since i already got content on it, about 2tb on a 8tb drive? Main reason I want to use NFS to stream video to Kodi and I read that its faster than smb.
      And since my movies basically are 4k (about 50gb) I need a fast protocol for that. I tried UPNP but the bad thing is that Kodi cant "scrape" the content for UPNP..
      And yeah SMB lags a bit I'm wondering if there will be a "big" difference with NFS? :)
    • anatema wrote:

      Do you think its worth to format my drive
      I always think you should use a Linux native filesystem with OMV.

      anatema wrote:

      Main reason I want to use NFS to stream video to Kodi and I read that its faster than smb.
      And since my movies basically are 4k (about 50gb) I need a fast protocol for that. I tried UPNP but the bad thing is that Kodi cant "scrape" the content for UPNP..
      And yeah SMB lags a bit I'm wondering if there will be a "big" difference with NFS?
      While nfs has less overhead than smb and upnp, none of these are your problem. Your problem is that you are using an RPi. Not only does it have slow networking but the usb bus that the drive is reading from is sharing bandwidth the network adapter.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • anatema wrote:

      I would like to add that my drive is Hfs+ (non journaled) since I'm a mac user. Does that effect the NFS? Works great on all the other protocols though?
      No it DOES NOT work great, you're just introducing a hell lot of problems you will only realize later. You're only fine when you're a mac user that behaves like a UNIX sysadmin and only use plain ASCII for file and directory names and never use filesystem metadata (which is impossible BTW at lesat on a Mac).

      Linux' HFS+ implementation is not up to the job (only knows a subset of what Apple did the last decade) and you introduce problems with
      • file and folder name encoding (Unicode precomposed vs decomposed -- if you use NFS between your OMV host and your Macs that most probably the only combination where this doesn't matter since NFS doesn't give a sh*t about filename encodings and so you would still use decomposed. As soon as you use SMB or AFP you get an encoding mess)
      • metadata: stuff like Finder metadata or so called Resource forks. they are stored in many different ways and once they're stored incompatible you can not access them any more
      HFS+ is always wrong using in Linux (use a native POSIX filesystem) and you should never use a disk both locally on your Mac and later on an OMV box with contents shared over the network since this will lead to the aforementioned problems. Same is true when switching between AFP and SMB or even using them at the same time with the same set of data.

      You won't believe me so just a quick link to outline the challenges. You will for sure realize sometimes in the future that you have problems accessing certain files or their metadata and then I hope you remember this post and get what went wrong.