Good spot. This is explained in this article: NFS mounting incorrect NFS export | Support | SUSE
An fsid is usually not necessary, since NFS will normally use the UUID of the remote filesystem. Since /mnt/raid5/Video is simply a subdirectory of the same filesystem as /mnt/raid5, I’m guessing that @Takei manages to get away with this error.
From what I recall, what will happen is that linux will export /mnt/raid5/Video first (because it is the deepest) and then fail to export /mnt/raid5, because it sees fsid=1 and thinks its the same mountpoint as an already exported filesystem. I recall going through some hell with exporting bind mounts and some fuse mounts until I figured out I needed to explicitly set the fsid for everything (because things like UUID (the default id) wasn’t unique when exporting sub-mounts)
The OP may want to also take a gander at exports(5): NFS server export table - Linux man page
if the Video directory is something mounted under raid5, may need to add crossmnt (or nohide) option (to let client auto-mount the child directory)
The server shows both /mnt/raid5 and /mnt/raid5/Video as being exported (post #4):
My own recommendation would be to remove the /mnt/raid5/Video line from /etc/exports and also remove all references to fsid=1. If /mnt/raid5 is shared, it should still be possible to mount /mnt/raid5/Video at /mnt/Video.
The shares are for two different computers. The Vero has no need to access any more than what’s in /mnt/raid5/Video so it seemed wise to limit the access (yes it is my home network, but it feels good).
Both shares work fine on both computers. Should I still add crossmnt?
The only thing not working is to use nfsv4 client on the vero. If I restart the vero I need to diasable ufw on the server, once the connection is established and the export mounted I can enable ufw and leave it on, even if I reboot the server it works of the Vero is left on. The other computer mounts /mnt/raid5 just fine with only port 2049 open on the server.
Perhaps you know a neat trick to force nfsv4 client on the vero? I have tried a few things like specifying nfsv4 in fstab to no avail. But it’s no biggie, I can disable/enable ufw the few times the vero reboots, I rather do that than open all ports to the vero (same reason, feels good)
Anyway I will delete both mentions of fsid=1 
I’m not sure I’d call it a trick, but have you tried changing nfs to nfs4 in your /etc/fstab? Reboot and then run the command mount. That will show you which version it’s using.
Here’s an explanation of crossmnt. How to explain NFS crossmnt argument? - Stack Overflow
you could also try the nfsvers mount option:
nfsvers= n
The NFS protocol version number used to contact the server’s NFS service. If the server does not support the requested version, the mount request fails. If this option is not specified, the client negotiates a suitable version with the server, trying version 4 first, version 3 second, and version 2 last.
I already tried that, and rebooted. It remains on nfsv3
I tried nfsvers=4 as well as vers=4 but both gave an error upon mount, unknown mount option or something like that.
A big update with a newer kernel is around the corner, maybe I’ll get more lucky with that.
Sorry, I hadn’t realised that this was specifically a Vero4K problem. (You only mentioned this fact in post #35.) I can also reproduce the problem on the 3.14 kernel, though can’t figure out what’s going wrong.
I can confirm that NFSv4 works correctly on the new 4.9 kernel, so it’s probably not worth trying to find out why 3.14 isn’t working correctly.
I’ve amended the title of the thread to reflect that it’s a V4K/+ issue.
if you ssh into your fileserver, and run:
rpcinfo -p localhost
or, ssh into the vero, and run
rpcinfo -p 192.168.1.101
what does the output look like? (that will tell us what version(s) of nfs your server is actually supporting, probably should start with that)
I can confirm that mine doesn’t get NFSv4 with kernel 3.14 but 4.9 does.
Here’s my server:
sudo cat /proc/fs/nfsd/versions
-2 +3 +4 +4.1 +4.2
While it might be just coincidence that it doesn’t work for me, I see that you seem to have a Vero4K/+. Have you tried it yourself on the 3.14 kernel?
Mind you, thou I am very grateful for your commitment and suggestions, my problem and reason for creating this thread was solved by enabling ‘wait for network’. I did click the ‘Solution’ button. When the two of you entered the thread afterwards with suggestions and energy I took a chance and asked about the firewall ports and nfs version. I am sorry If I led you on a wild goose chase of sorts, I am truly grateful for you commitment to help
My switch to an Edgerouter X configured as a switch, replacing an Asus ac51u doing the same duty, probably introduced some delay which hindered osmc from automounting the nfs share. As I believed the ER X would be way better than the old and cheap ac51u it never crossed my mind something like this would happen. This is my theory since I did the switch the day before the problem occured.
(For background: My vero is connected by ethernet to the router and the server to the switch. When I upgraded my fiber connection I realized the Asus ac51u was capped at 100Mbps over ethernet. So I got an Edgerouter, a lot of stuff like a ubiquity swtich is out of stock currently over here but I assume the ER X does the same job just as good and it was not much more expensive. Furter down the road I plan to replace the router as well with ubiquity gear)
This turned out to be quite a lenghty post, but I hope it cleared up something. I think we can lay the thread to rest and you can put your energy on helping others. Thank you very much for your input.
Whenever something breaks and I’ve recently modified something else, I look at the recent changes to find the problem first.
Would be helpful to see the /etc/exports on the NFS-server
and the fstab line from the clients.
Also, as fzinken asks, the showmount -e would prove that the nfs-server is up and working.
I’m inclined to lean towards a bad switch port or router port that hasn’t failed completely because ssh is working.
What is the nfs-server running? lsb_release -a should provide the details to a sufficient level. I’ve seen issues with 1 client, but not all of them due to systemd network/nfs-server component dependency issues. 95% of the time, those issues don’t happen, but when they do, it can be bad. I usually manually shutdown the 4 NFS-server things, then bring those back up manually - in the correct order - and then restart the NFS-client processes. Then everything is fine. Last time this happened to me was around October and not with OSMC. It was an Ubuntu NFS server and Ubuntu NFS client with the issue. Hope this isn’t the issue here. Systemd dependency problems can be ugly to resolve. They seem easy, but systemd dependency terms are more complex than POSIX permissions+ACLs.
If networking isn’t up or somehow comes up, but fails, then the Requires= would be better, since nfs would be taken down when networking fails automatically.
The manpage for systemd.mount has a section about NFS and the manpage for systemd.unit attempts to explain After, Before, Wants, Requires, and other dependency options used by all systemd unit files. If it isn’t clear - each line in the fstab gets converted into a separate unit file by system automatically. It almost always works, but almost isn’t the same as always.
I installed the ER X about mid day, and in the evening media from the server worked fine on the vero so I didn’t think that would be the problem when it did not work the next morning.