Fstab NFS mount broken in December built


I had mounted my NFS shared folder with fstab in the October build (with the helpful support of bmillham and dillthedog Vero 4k: Stuttering when replaying 4k hevc files / Help Fstab mounting an NFS share - SOLVED) using this line , “ /mnt/film nfs x-systemd.automount,noauto,user,rw 0 0”.

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 “ /mnt/film nfs x-systemd.automount,noauto,user,rw 0 0”?

Thanks in advance, Mark

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.

Does it mount with a mount /mnt/film command?

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 ( /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).

Here’s the log for the Vero running the December build where the fstab mount isn’t working https://paste.osmc.tv/gulokimifi

And here’s the log fore the Vero running the October build where the fstab mount is working https://paste.osmc.tv/texixoloqi

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?

This is still showing the October configuration:

/etc/apt/sources.list is still for Debian jessie
Kernel version is 3.14.29-42
Kodi version is 17.5

The APT logs are empty:

====================== APT term.log =================== RcBRrsRs

---------------------- APT term.log END --------------- RcBRrsRs

====================== APT history.log =================== B8sj7DO8

---------------------- APT history.log END --------------- B8sj7DO8

That’s not what kodi is showing…

Here’s a picture just took of that Kodi within My OSMC where it stats it’s on the December build

I ran through the instructions on How to submit a useful support request - General - OSMC to upload the logs. Specifically these three lines

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)

best just to use grab-logs -A and post the URL that it shows. You may have uploaded an old version of uploadlog.txt

Thanks Graham, here’s the URL I get for the Vero 4k with the issue with the fstab mount not working

Let me know if it’s right and I’ll do the same for the Vero 4k where the mount is working?


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: /mnt/films nfs vers=3,x-systemd.automount,noauto,user,rw 0 0

Also, verify that the IP of the NAS hasn’t changed!

1 Like

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)

Thanks so much for your help.

@Chillbo may wish to add this to his Wiki article. It looks like stretch defaults to nfsv4 which some NASs may not support.

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.

This is odd because my NAS does not support NFSv4, but I don’t need the vers=3 to connect from my Vero 4K or Pi2 or Linux Mint systems.

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… :+1:t2: 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 :rofl:

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.

I think this might be Kerberos authentication you’re talking about. It’s massive overkill for OSMC, but feel free to read up on it if you’re curious. :wink:

Not quite true. He can restrict access on the basis of IP address.