Yeah, it should be sufficient to simply flip the executable bit to get rc.nfsd to run at boot.

Yes, you should be picky when choosing an NFS server, those are kind of supposed to be running 24/7 as NFS clients might get stuck when an NFS server is down. Automount (rc.autofs) instead of fstab might in some cases help for shaky NFS servers only needed at rare occasions.

regards Henrik

I hope my house is low tech enough that I don't have to worry about NFS servers getting stuck. The ONE reason that the RazPi is on 24/7 is that the switch is inaccessible. It's not worth the hassle turning it off, or the personal risk turning it on. Otherwise, things are just on as wanted.

Well, after a few days of service, it transpires that the nfs server of interest is on the RazPi, which is on 24/7 and is a few steps behind on the configuration curve. So I'll update that to use rc.inet2.

I have another pair of mains network adapters coming (€15/pair) which should speed up the bottleneck on my network. It didn't matter when the network was just passing internet, but it kind of matters now.

EDIT: Haha, I wasn't as far behind as I thought. It transpires my RazPi had the rc.inet2 script "misconfigured" to be executable all along .

Do you mean that your dual boot Windows/Slackware machine were unable to mount the NFS exports from your Raspberry Pi because the Raspberry Pi had been rebooted and did not start the NFS server in its startup scripts?

regards Henrik

No. The RazPi has the current section of my Video archive, My archives & backups are linked with another box, which was seemed to be offline after visting the "Dark Side" of Windows 11. The RazPi had 0755 on rc.inet2 so that nfs just behaved when I rebooted it. So everything of interest is available to my laptop with the least disk space. That's good, because it's been pressed into service as the TV has recently expired.