This worked perfectly, however as soon as I upgraded my Vero 4k to the December build in early January the mount immediately stopped working (the folder just appearing to be empty). I tried reinstalling the build by USB and running through setting up the fstab mount again as I had previously but nothing worked.
Finally I reinstalling the October build, and went through the exact same steps again, which led to the mount working perfectly again.
Is this a known issue with the December build? Or is there a new fstab line I should use in place of “192.168.1.2:/c/media/Films /mnt/film nfs x-systemd.automount,noauto,user,rw 0 0”?
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.
Thanks for your understanding. We hope that we can help you get up and running again shortly.
Thanks guys, I’ll work through sending upload logs later today.
FYI. It does definitely seems to be related to the December update.
As I have two Vero 4k’s both of which the fstab mounts broke immediately after updating. And I now have one Vero 4k on the October OSMC build (on which the fstab mounts work perfectly), and one of the December OSMC build on which they don’t - I’ve doubled check both have exactly the same line in fstab (192.168.1.2:/c/media/Films /mnt/film nfs x-systemd.automount,noauto,user,rw 0 0”).
The mount /mnt/film command returns a “no such file or directory message” on the Vero 4k with the December OSMC build (whereas the Vero 4k with the October build returns "mount… is busy or already mounted).
Have you tried rebooting the NAS (or where the files are hosted)? Also, check permissions on /mnt/film. fstab NFS mounting definitely works as I have 5 mounts on my NAS mounted on a Vero 4K and 2 Rpi2s without issues.
Indeed, but many of us have updated and our nfs mounts have survived. We just need to find out what it is about your setup that’s different. So far, you haven’t posted any logs which would give some more information about your vero system and perhaps you can give us more details about the server. From the path it looks like some sort of windows setup.
Makes sense, and thanks for your really quick and comprehensive support as always. It does seem more than a coincidence to me though that the fstab mounts broke immediately after both Vero 4k’s after they updated to the December build and is now working on the one I’ve reverted back to October build (with that being the only difference I can see).
I’ve reset the NAS (it’s a readynas) a couple of times, and checked permissions - and I’m pretty certain it’s not an issue with the NAS as one Vero’s fstab mount is working fine and I’m having no issues accessing the NFS share from any other device.
Can you confirm that your NAS / device hasn’t received updates in the interim?
Can you post your full fstab?
Can you post the output of mount -av.
Can you let us know how Vero 4K connects to the network (WiFi or Wired) and if this has changed recently?
grab-logs -A -C
nano /boot/uploadlog.txt
paste-log /boot/uploadlog.txt
Can you let me know what else I should be doing - sorry I’m not that familiar with Unix - I’m mainly got and love Vero for it just working (but then had to use fstab due to make 4k files play without stuttering)
Jan 31 17:31:54 lounge systemd[1]: mnt-films.automount: Got automount request for /mnt/films, triggered by 733 (JobWorker)
Jan 31 17:31:54 lounge systemd[1]: Mounting /mnt/films...
Jan 31 17:31:54 lounge kernel: NFS: nfs4_discover_server_trunking unhandled error -22. Exiting with error EIO
Jan 31 17:31:54 lounge systemd[1]: mnt-films.mount: Mount process exited, code=exited status=32
Jan 31 17:31:54 lounge systemd[1]: Failed to mount /mnt/films.
Something strange seems to be going on with your NAS. What happens if you try changing your fstab line to look like this:
That fixed it! Adding “vers=3”, my NAS IP is unchanged.
I guess the October build didn’t require the “vers=3” parameter, and the December one does. As my second Vero 4k that I put back onto October build has no fstab mount issues with the line as was without vers=3 (but I’m glad I can upgrade it to the latest build now)
Yep, will do that later. Can @sam_nazarko confirm that something about the NFS implementation has changed? And is it useful to just force v3 or maybe even less than that?
I’d only like to suggest something complete and helpful/useful to many in a wiki entry.
That’s useful to know. IIRC, version 4 has additional authentication so maybe the OP’s NAS does support it but vero is not trying to authenticate. All current ReadyNASs support nfsv4.
That could be tested if we knew the syntax for authentication - is it like smb I wonder?
That would be interesting indeed. A friend of mine was complaining about this just recently as his NAS does support username and password authentication under SAMBA as well as NFS. But when creating the NFS FSTAB wiki entry I couldn’t find anything on the syntax needed on the Vero’s side to use this authentication. If somebody has ideas on this, I’d be glad to add it to the wiki entry… The friend of mine would be happy because he didn’t like that FSTAB NFS under OSMC requires an authentication-less NFS access to his NAS
That’s what I meant when asking about a change in the NFS implementation… Are the OP’s problems really related to the the NFS version? Or in other words: What should specifically be edited in the wiki entry to avoid new confusion?
Just would like to be sure before adding or changing something about it.
The friend of mine would be happy because he didn’t like that FSTAB NFS under OSMC requires an authentication-less NFS access to his NAS 
