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…