I installed NFS-Server about two years ago. I used it a great deal for a while, but haven’t had much need for it in the last year or so. Today, I had need of it, and found that is was no longer working.
When I checked the logs, it looks like, on bootup, the server is immediately starting, but then stopping:
If I start it manually via “sudo systemctl status nfs-mountd.service” it starts up just fine.
I really loath systemd [I use Devuan/SysV on all my Linux machines], so I’m WAY outta practice on how to go about debugging this…
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
enable debug logging at settings->system->logging
reboot the OSMC device twice(!)
reproduce the issue
upload the log set (all configs and logs!) either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
OK, my guess is that I did the original install pre-LEIA.
So I did an apt-get remove nfs-kernel-server
rebooted
…then did an apt-get update && apt-get install nfs-kernel-server
rebooted
…now I’m seeing a different error about the mount-point that I have mapped in my /etc/exports:
exportfs: Failed to stat /media/SDDATA/downloads: No such file or directory
sudo systemctl status nfs-server.service
* 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 Sun 2022-10-09 13:28:38 EDT; 48s ago
Process: 2417 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=1/FAILURE)
Process: 2418 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS)
Process: 2419 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS)
Oct 09 13:28:38 osmc systemd[1]: Starting NFS server and services...
Oct 09 13:28:38 osmc exportfs[2417]: exportfs: Failed to stat /media/SDDATA/downloads: No such file or directory
Oct 09 13:28:38 osmc systemd[1]: nfs-server.service: Control process exited, code=exited, status=1/FAILURE
Oct 09 13:28:38 osmc systemd[1]: nfs-server.service: Failed with result 'exit-code'.
Oct 09 13:28:38 osmc systemd[1]: Stopped NFS server and services.
So my guess is that the NFS service is running prior to the mount of my SD card being completed.
To correct the problem I just added a small delay prior to the nfs-server.service starting the exportfs application
/lib/systemd/system/nfs-server.service
[Unit]
Description=NFS server and services
DefaultDependencies=no
Requires=network.target proc-fs-nfsd.mount
Requires=nfs-mountd.service
Wants=rpcbind.socket
Wants=nfs-idmapd.service
After=local-fs.target
After=network.target proc-fs-nfsd.mount rpcbind.socket nfs-mountd.service
After=nfs-idmapd.service rpc-statd.service
Before=rpc-statd-notify.service
# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service gssproxy.service rpc-svcgssd.service
# start/stop server before/after client
Before=remote-fs-pre.target
Wants=nfs-config.service
After=nfs-config.service
[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
Type=oneshot
RemainAfterExit=yes
#Add delay so that udisks-glue has time to mount the SD drive where my nfs mount is shared from
ExecStartPre=sleep 30
ExecStartPre=/usr/sbin/exportfs -r
ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
ExecStop=/usr/sbin/rpc.nfsd 0
ExecStopPost=/usr/sbin/exportfs -au
ExecStopPost=/usr/sbin/exportfs -f
ExecReload=/usr/sbin/exportfs -r
[Install]
WantedBy=multi-user.target
Not sure, but that really doesn’t have anything to do with it. After adding a delay prior to running the exportfs it starts fine and shared the drive via NFS. This issue is that the systemd job for nfs-server is firing off before the SD drive is mounted.
Apologies I’d forgotten you mentioned it works after the delay, but people had mentioned issues with exfat.
Have you considered setting a permanent mount for the sd card, in fstab? Should resolve any issues caused by any possible delays with the udisks-glue.service.
To be honest, now I’ve screwed up really good. I modified the udisks-glue.service changing the type to oneshot, and now it’s hanging during the bootup. DOH!
I tired the old recovery mode, pressing CTL or space during bookup, but neither did anything.
Is there a way that I can mount the vero as a USB drive on my PC so that I can modify that file back?
@fzinken all the .service files are posted in this thread, and all have some form of after/requires networking, but networking isn’t the issue. The issue is that the service that osmc uses for automounting media: udisks-glue.service which launches an executable that continues to run (i.e. looking for when new media devices (USB, etc) are added), so even if I add After=udisks-glue.service to the nfs-server.service, systemd doesn’t actually have a way of knowing that the drives (in my case the SD card) is mounted.
I have a couple of ideas for a possible code change to address this, but first I have to get my box bootable again.
My understanding is that udisk-glue is for automounting external drives, probably a stupid question but have you tried starting the vero4k, with the SD card and external drives removed? Its a longs hot, but it may allow osmc to start as normal; so you can revert the change to the file.
@Tom_Doyle we’re crossing over into two separate issues now.
NFS = Solved (added a sleep 30 prior to calling nfs_server process).
Boot hang = In attempting to figure out a better long-term solution, I edited the udisks-glue.service, and changed type=simple, to type=oneshot. But since the executable that udisks-glue.service calls doesn’t just mount the drives and quit (it continues to run in the background so that if a new USB drive is plugged in, it is automounted), this has caused my vero4k to hang because systemd is waiting on that executable to exit. This is a whole different issue, that I’ll work with sam or joakim to resolve.