Nfs-kernel-server won't start on boot :(

ridgek_lives · 12 July 2015 14:38

Greetings,

I have a USB HDD I’m trying to share from OSMC on a Raspberry Pi 1 but I can’t get the drive to be available to the network without having to run $ service nfs-kernel-server restart after rebooting. After restarting the service, everything works and I can access the drive from other devices at its nfs:// address.

On boot (before restarting nfs),

$ service nfs-kernel-server status

returns this:

osmc@osmc:~$ sudo service nfs-kernel-server status
● nfs-kernel-server.service - LSB: Kernel NFS server support
   Loaded: loaded (/etc/init.d/nfs-kernel-server)
   Active: active (exited) since Sun 2015-07-12 14:12:21 UTC; 1min 20s ago
  Process: 263 ExecStart=/etc/init.d/nfs-kernel-server start (code=exited, status=0/SUCCESS)

Jul 12 14:12:19 osmc nfs-kernel-server[263]: Exporting directories for NFS kernel daemon....
Jul 12 14:12:19 osmc nfs-kernel-server[263]: Starting NFS kernel daemon: nfsd
Jul 12 14:12:19 osmc nfs-kernel-server[263]: Not starting: portmapper is not running ... (warning).

I can’t seem to find any information on how I can check on portmapper, but since restarting the nfs-kernerl-server works after reboot, I assume something is happening out of order? I’ve tried the following on a clean install of Raspbian and it works with no issue on every reboot.

Here’s the steps I followed on a clean NOOBS installation of OSMC:

edit /etc/fstab to make the USB drive mount at boot

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /mnt/USBHDD    ext4      defaults,noatime    0    0

run

$ apt-get install nfs-kernel-server

edit /etc/exports

/mnt/USBHDD  192.168.1.0/24(rw,async,insecure,no_subtree_check)

run

$ exportfs -ra

reboot…aaand nothing!

I’d appreciate any help.

Edit: just tried sharing the /home directory, and that doesn’t work on reboot either.

ridgek_lives · 14 July 2015 00:06

I’ve found a temporary solution, but I’m not sure how acceptable I find it.

Add

sleep 30

to the first line of start() in /etc/init.d/nfs-kernel-server

DBMandrake · 14 July 2015 06:32

This is a known problem in upstream Debian Jessie that has been there for a long time. (Ever since they started switching to systemd) The issue is that rpcbind and nfs-kernel-server still use legacy init scripts, and the dependencies of the rpcbind service are in conflict with other services such that they cause a dependency loop that forces systemd to not start rpcbind. You will see the following in your log:

Jun 28 14:35:52 vero systemd[1]: Found ordering cycle on basic.target/start
Jun 28 14:35:52 vero systemd[1]: Found dependency on sysinit.target/start
Jun 28 14:35:52 vero systemd[1]: Found dependency on rpcbind.service/start
Jun 28 14:35:52 vero systemd[1]: Found dependency on network-online.target/start
Jun 28 14:35:52 vero systemd[1]: Found dependency on network.target/start
Jun 28 14:35:52 vero systemd[1]: Found dependency on connman.service/start
Jun 28 14:35:52 vero systemd[1]: Found dependency on dbus.service/start
Jun 28 14:35:52 vero systemd[1]: Found dependency on basic.target/start
Jun 28 14:35:52 vero systemd[1]: Breaking ordering cycle by deleting job rpcbind.service/start
Jun 28 14:35:52 vero systemd[1]: Job rpcbind.service/start deleted to break ordering cycle starting with basic.target/start

If you search google for:

Job rpcbind.service/start deleted to break ordering cycle starting with basic.target/start

You will find hundreds of matches on the issue outside of OSMC. We are investigating to see if there is something we can do to work around this but ultimately it is up to the Debian maintainers to fix this properly upstream, by providing proper systemd service units for rpcbind and nfs-kernel-server rather than continuing to rely on known buggy legacy init scripts.

Debian switched to using systemd by default in Jessie so this really should have been addressed by now but apparently not as many critical services still rely on legacy init scripts…

ridgek_lives · 14 July 2015 17:42

Thanks so much for this great answer!

I was searching forums and wikis all weekend and couldn’t find a comprehensive answer that seemed correct. I also noticed that some of the logs aren’t in the usual /var/logs but I’m not an experienced enough Linux user to have been able to find the proper logs or troubleshoot the issue, but with help from communities like this, I’m learning!

I guess I’ll stick with the sleep 30 edit for now. Do you foresee any issues with this?

Thanks again for your help!

DBMandrake · 14 July 2015 21:01

There’s no /var/log/messages or /var/log/syslog on a systemd system, logs are all stored in an indexed database rather than plain text files, so to access the logs you use the journalctl command, for example:

sudo journalctl

journalctl has a lot of optional command line options for filtering the logs for particular information.

If sleep 30 works for you now (5 or 10 seconds is probably enough) then I can’t see any problem with using that for now.

Katze · 4 August 2015 17:30

This is working for me.

Snippit from /etc/init.d/nfs-kernel-server

# See how we were called.
case "$1" in
  start)
        sleep 10
        export_files="/etc/exports"

mandelsoft · 15 July 2017 17:52

I just added the correct dependencies by a drop-in file for the nfs-kernel-server service
/etc/systemd/system/nfs-kernel-server.service.d/10-dep.conf:

[Unit]
Requires=rpcbind.service
After=rpcbind.service

Now reboot works fine

Kyblik · 28 November 2017 14:33

Two years later and the bug is still there? I just run into it when switching from samba to nfs shares
The suggested workaround with sleep did not work for me:

however adding

service nfs-kernel-server restart

to /etc/rc.local did the trick for me

note: Maybe the problem in my case is (yet again) in my network setup - I have RasPi(s) connected via WiFi only and I’ve came across similar issues in past with Transmission daemon - simply because the network was not up yet in the time of service startup…

dillthedog · 28 November 2017 18:55

Did you try the fix proposed in post #7? (The poster forgot to mention that you first need to create the directory /etc/systemd/system/nfs-kernel-server.service.d.)

Kyblik · 28 November 2017 20:24

I wanted to, but when I did not find the folder I wasn’t sure if things have not changed since 2015 and hence went with solution via restart in rc.local. I’ll give it a try…

Nickkosan · 30 November 2017 20:35

I tried the one mentioned in #7 and it didn’t help. Still can’t be booted from nfs. The rc.local trick mentioned by Kyblik works just fine! Thx!

dillthedog · 30 November 2017 20:36

Thanks for the feedback.

grahamh · 30 November 2017 20:47

Looks like this is sorted in stretch. nfs-server has been brought into systemd.

ridgek_lives · 1 December 2017 02:41

That’s good to know! I eventually dismantled the server in the original question, but have been resorting to using Samba since then. Thanks to all who have contributed to this thread.

Kyblik · 13 January 2018 12:11

Well for me it’s even worse now… workaround with rc.local does not work anymore because disks are not mounted under /media/ yet, so the outcome is>

nfs-server.service - NFS server and services
  Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
  Active: failed (Result: exit-code) since Sat 2018-01-13 12:43:12 CET; 6min ago
  Process: 358 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=1/FAILURE)

Jan 13 12:43:12 osmc-obyvak exportfs[358]:   NOTE: this default has changed since nfs-utils version 1.0.x
Jan 13 12:43:12 osmc-obyvak exportfs[358]: exportfs: No host name given with /home/osmc (ro), suggest *(ro) to avoid warning
Jan 13 12:43:12 osmc-obyvak exportfs[358]: exportfs: /etc/exports [2]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/hom
Jan 13 12:43:12 osmc-obyvak exportfs[358]:   Assuming default behaviour ('no_subtree_check').
Jan 13 12:43:12 osmc-obyvak exportfs[358]:   NOTE: this default has changed since nfs-utils version 1.0.x
Jan 13 12:43:12 osmc-obyvak exportfs[358]: exportfs: Failed to stat /media/data: No such file or directory
Jan 13 12:43:12 osmc-obyvak systemd[1]: nfs-server.service: Control process exited, code=exited status=1
Jan 13 12:43:12 osmc-obyvak systemd[1]: Failed to start NFS server and services.
Jan 13 12:43:12 osmc-obyvak systemd[1]: nfs-server.service: Unit entered failed state.
Jan 13 12:43:12 osmc-obyvak systemd[1]: nfs-server.service: Failed with result 'exit-code'.

Now I need to find another hack how to start it properly and automatically, because once fully booted sudo service nfs-kernel-server restart starts it as expected

dillthedog · 13 January 2018 12:13

Please check out this thread. Help automount at boot NFS share external HDD

Perhaps it’ll help.

Kyblik · 13 January 2018 15:51

Helped. Thanks.

rich_wicks · 17 April 2018 22:00

Mandelsoft’s answer is correct.

This is April 17, 2018 as I write this, I’m using Linux Mate on the PI.

I’ve tested both the 30 second delay (hack) which works with variations in the sleep time, but the creation of /etc/systemd/system/nfs-kernel-server.service.d/10-dep.conf works reliably between reboots.