After a recent update it appears fstab automount isn’t working. I can mount manually, but after a reboot the mounts are not remade, unless I log in via putty and mount -a.
Here is my fstab:
192.168.1.112:/UHD_Movies /mnt/UHD_Movies nfs x-systemd.automount,_netdev,nfsvers=3,intr,noatime,rsize=32768,wsize=32768,nolock,async 0 0
192.168.1.112:/TV_Shows_UHD /mnt/TV_Shows_UHD nfs x-systemd.automount,_netdev,nfsvers=3,intr,noatime,rsize=32768,wsize=32768,nolock,async 0 0
Thanks
Having done a little extra reading trying to find a fix for automount, I’ve edited my ftsab to:
192.168.1.112:/UHD_Movies /mnt/UHD_Movies nfs x-systemd.automount,noatime,nolock
192.168.1.112:/TV_Shows_UHD /mnt/TV_Shows_UHD nfs x-systemd.automount,noatime,nolock
And what happens?
Perhaps if you run grab-logs -A we’ll be able to give a more informed answer.
Have you enabled “Wait for network” under My OSMC > Network?
Same, it doesn’t automount, but I changed it more to clean up the rest of the fstab options than in a hope for automount to work as I didn’t find a change for the x-sysemd.automount.
I’m not sure if there will be a recommended fstab string in the future, (other than mount locations) so I’m looking for the optimal set up.
Wait for network is enabled. The mounts appeared in System Info > Storage before the last update, but not now, unless I putty in and run mount -a
Log output here: ====================== UNAME =================== 0wwkXuO5Linux osmc 3.14.29- - Pastebin.com
Thanks
I can’t see anything obvious.
I would suggest that you slightly modify your fstab lines to remove nolock and add noauto. Although not obligatory, you’d probably want to add 0 0 at the end of the lines. So you’d have:
192.168.1.112:/UHD_Movies /mnt/UHD_Movies nfs x-systemd.automount,noatime,noauto 0 0
192.168.1.112:/TV_Shows_UHD /mnt/TV_Shows_UHD nfs x-systemd.automount,noatime,noauto 0 0
There have been a few reports of NFS failing to mount in Debian stretch where the server is running an old version of NFS. You can add nfsver=3 to each line to see if that helps:
192.168.1.112:/UHD_Movies /mnt/UHD_Movies nfs x-systemd.automount,noatime,noauto,nfsver=3 0 0
192.168.1.112:/TV_Shows_UHD /mnt/TV_Shows_UHD nfs x-systemd.automount,noatime,noauto,nfsver=3 0 0Being new to VERO and Raspbi I just tried using the same format as ubuntu fstab files and it seems to work. My NAS drive mounts using
//192.168.1.99/share /nas cifs credentials=/home/osmc/.smbcredentials,x-systemd.automount 0 0
The credentials files keep my user and password from view
But that’s a SMB/CIFS mount line… Not NFS. 
Sorry, although I know Ubuntu I have only had my Vero a week and still playing. This got my NAS attached and I could access my Music, Photos, Videos etc. As it works for me I thought it might help someone else.
Please try and simplify your FSTAB line a bit to this format:
192.168.1.2:/nfs /mnt/Server_Movies nfs noauto,x-systemd.automount 0 0
as explained in the wiki entry mentioned above.
I am facing the same issues as OP on Vero 4K. I have edited /etc/fstab as per the wiki entry by @Chillbo, and manually mounting works fine. However, automount fails on reboot.
Looking at the logs, I see multiple Mount process exited, code=exited status=32 followed by Unit entered failed state.
Any suggestions?
Could you please post a debug log showing the issue and also post a copy of your fstab lines here. 
Are you using LAN or Wifi network connection?
Output of grab-logs -f -J at https://paste.osmc.tv/kaxagaqami
/etc/fstab:
# rootfs is not mounted in fstab as we do it via initramfs. Uncomment for remount (slower boot)
#/dev/vero-nand/root / ext4 defaults,noatime 0 0
10.1.20.150:/mnt/Wolfswood /mnt/wolfswood nfs noauto,x-systemd.automount 0 0
10.1.20.150:/mnt/Braavos /mnt/braavos nfs noauto,x-systemd.automount 0 0
Using LAN.
@nishark: Looks good, I personally would expand the options to “defaults,noauto, …” but should work also in this form very well.
Please, try the flag “Wait for network” in the menu OSMC GUI -> My OSMC -> Network -> Wired
… and reboot.
I think what may be important but is being overlooked for possible changes to fstab, is that it WAS working until a recent update, then the automount stopped working on boot, but works if manually mounted. To me, that indicates its a system change that affected the automount, rather than the content of the previously working fstab.
No amount of the suggested changes to fstab seem to be correcting it, so it seems like we need to look at what system changes may have impacted it.
It’s difficult to point fingers here, as the majority of people using NFS via fatab do not have problems (myself included).
But it seems likely that out of date NAS software may be the culprit. Have you tried adding vers=3 to the fstab options? Some people have found that to work.
Honestly, not even that seems to be very likely. I’m using a WD MyBook Live that doesn’t even have a GUI for NFS share options (everything has to be configured via SSH) and the last firmware update was shipped more than 2 1/2 years ago.
Everything’s working flawlessly here following the wiki entry (with two NAS and a Vero 4k and a RPi3 running OSMC). 
Sure, my original fstab included that, but from what I understand leaving that out shouldn’t be an issue as it would try to negotiate the best NFS version and would drop down to 3 automatically if needed.
I’m using a modern QNAP which is always updated, and as I say the fstab had vers=3 to begin with and worked, then with (I think Jan’s update) the automount stopped working.
I’m glad at least 2 of us are seeing it, as it seems less likely to be a local thing, even if it doesn’t help narrow down the root cause.
If it’s ‘modern and updated’ then it should allow v4 I’d think.
What’s odd is some people must use vers=3, and others (myself included) don’t. It seems that some NAS fall back correctly and some don’t. If I try to force vers=4 (or nfs4) it fails on my NAS. (A WD MyCloud)
Also, I’d think that because the manual mount of the fstab works, the content of the fstab must be ok, and it’s the automounting on boot that’s not working, right?