Bug? NFS server needs two starts

[CNK]

The intended text of this post is in the attachment. After 1/2hr trying to post it and not being able to pin down what part triggers "500 error" pages from the forum (not the code snippets, as it turns out), it's this or nothing.

Here's the first paragraph because it seems to be safe on its own:

I recently set up an NFS server on my TC Pure64 v. 12.0 system, and had a lot of trouble with NFS mounts failing (timing out). I eventually discovered that I needed to run the init script at /usr/local/etc/init.d/nfs-server twice, after which connections would work correctly.

[Paul_123]

Are you sure your network device is up and configured before starting?

[CNK]

Are you sure your network device is up and configured before starting?

Yes. I'm running all the commands via a Telnet connection from the other computer where I'm also attempting to mount the NFS shares.

[Rich]

Hi CNK
nfs-utils.tcz  is unchanged since 2016/04/10. However,  rpcbind.tcz  and  libtirpc.tcz  were both updated on 2021/01/18
for TC12 x86_64. The  nfs-server  script depends on  rpcbind  and  rpc.nfsd  depends on  libtirpc. You could try
copying those 2 extensions from the  TC11 x86_64  repository to see if that fixes the issue.

[CNK]

Hi CNK
nfs-utils.tcz  is unchanged since 2016/04/10. However,  rpcbind.tcz  and  libtirpc.tcz  were both updated on 2021/01/18
for TC12 x86_64. The  nfs-server  script depends on  rpcbind  and  rpc.nfsd  depends on  libtirpc. You could try
copying those 2 extensions from the  TC11 x86_64  repository to see if that fixes the issue.

I tried that (after first confirming that the existing extension md5sums match those in http://www.tinycorelinux.net/12.x/x86_64/tcz/ because the system was upgraded from TC 11), but the behaviour is identical. After running "sudo /usr/local/etc/init.d/nfs-server start", attempts to mount an NFS share from the client hang indefinately until "sudo /usr/local/sbin/rpc.nfsd 8" is run manually for a second time.

Previously installed TC 12 extenstions:

Code: [Select]

b2a2ec52e84d108aabdb93cbe63a5bb8  rpcbind.tcz
ce107a698262b5ebd53c4f132df913e0  libtirpc.tcz

Tested TC 11 extensions:

Code: [Select]

b80f7a43077edffa15855f41fb61fa36  rpcbind.tcz
9c202f05f5550c1b69559ccbe6caf35a  libtirpc.tcz

Also, I did confirm that the TC 12 extensions weren't loaded before I switched them and tested the ones from TC 11.

[Rich]

Hi CNK

... The "could not open connection" errors are apparantly just because I'm not set up for IPv6, and shouldn't stop IPv4 connections from working. I'm guessing the "AF_INET6" error from rpc.nfsd is also IPv6 related. ...

Just to be certain that is true, try installing  ipv6-netfilter-5.10.3-tinycore64.tcz  and see if anything changes.

[CNK]

Hi CNK

... The "could not open connection" errors are apparantly just because I'm not set up for IPv6, and shouldn't stop IPv4 connections from working. I'm guessing the "AF_INET6" error from rpc.nfsd is also IPv6 related. ...

Just to be certain that is true, try installing  ipv6-netfilter-5.10.3-tinycore64.tcz  and see if anything changes.

Ah you're right, after loading ipv6-netfilter-5.10.3-tinycore64 (I didn't realise that was all it took to enable IPv6 to be honest) the init.d script runs without the earlier errors:

Script path removed because it was triggering 500 error pages.

Code: [Select]

$ sudo nfs-server start
nodev nfsd
nfs-server utilities are started.

And NFS mounts work straight away.

I see that silly me missed this line in the nfs-utils extension's description:

nfs-server requires the filesystem-KERNEL and ipv6-KERNEL extensions

Though saying ipv6-KERNEL instead of ipv6-netfilter-KERNEL is a bit misleading. Equally filesystem-KERNEL should say filesystems-KERNEL.

It's annoying that it needs IPv6 when I'm only using IPv4 on my LAN, and looking at the nfsd man page there doesn't seem to be any option to specify IPv4-only. I'll probably just keep using my modified script for now, but thanks for clearing this up.