NFS systemd automount not working

Help and Support
1

Hi! Long time osmc user, have a Vero 4k. Just took the April update and I’m having issues with systemd automount of my NFS share. It has been working fine previously, and issuing ‘mount /my/mnt’ after ssh’ing in works to mount the share. ‘showmount -e’ lists the share on my server (Asus AX88U router).

journalctl output repeats like this:

Apr 23 21:51:33 vero systemd[1]: Set up automount home-osmc-mnt-mybook.automount.
Apr 23 21:51:41 vero systemd[1]: home-osmc-mnt-mybook.automount: Got automount request for /home/osmc/mnt/mybook, triggered by 864 (JobWorker)
Apr 23 21:51:41 vero systemd[1]: Mounting /home/osmc/mnt/mybook...
Apr 23 21:51:41 vero systemd[1]: home-osmc-mnt-mybook.mount: Mount process exited, code=exited status=32
Apr 23 21:51:41 vero systemd[1]: Failed to mount /home/osmc/mnt/mybook.
Apr 23 21:51:41 vero systemd[1]: home-osmc-mnt-mybook.mount: Unit entered failed state.

My fstab:

media.home.lan:/tmp/mnt/sda1 /home/osmc/mnt/mybook nfs nfsvers=3,noauto,defaults,user,noatime,intr,x-systemd.automount 0 0

Any thoughts or anyone experiencing this? I’ve read several older threads with similar issues and none were resolved.

2

Manual mounting

$mount -v mybook
mount.nfs: timeout set for Wed Apr 24 12:56:08 2019
mount.nfs: trying text-based options 'nfsvers=3,intr,addr=192.168.27.1'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.27.1 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.27.1 prog 100005 vers 3 prot UDP port 41978

Automount of this share worked fine on the previous version of OSMC, as well as continues to work fine on another rpi with raspbian which I use with Plex.

3

Hi,

Have you got wait for network enabled in MyOsmc?

Thanks Tom.

4

I do not, and did not previously either. I do not want to slow the boot process, which is why I opted for systemd automount.

5

Hi,

the the flags noauto and x-systemd.automount, the share shouldn’t being mounted unless accessed; so by default not on start up. It looks like something is trying to access the share on startup, is a library scan enabled on startup?

Tom.

9

I have add-ons that use the drive for temp folders, so yes. But even long after startup, I can ssh in and try to access the share via terminal, and the automount fails. I can also manually mount the share successfully, then unmount it, then try to access it again to trigger the automount, and the automount fails again. After, I can again successfully manually mount the share. It seems like something specific to the automount that has broken.

10

If you provide full logs we might be able to get a better idea of what’s happening.

11

Full logs : (removed)

I would request a mod to delete those when done with them, thanks!

12

Here’s what the log shows:

Apr 25 06:36:44 vero mediacenter[422]: Starting Kodi...
...
Apr 25 06:36:51 vero systemd[1]: home-osmc-mnt-mybook.automount: Got automount request for /home/osmc/mnt/mybook, triggered by 860 (JobWorker)
Apr 25 06:36:51 vero systemd[1]: Mounting /home/osmc/mnt/mybook...
Apr 25 06:36:51 vero systemd[1]: home-osmc-mnt-mybook.mount: Mount process exited, code=exited status=32
Apr 25 06:36:51 vero systemd[1]: Failed to mount /home/osmc/mnt/mybook.
...
Apr 25 06:36:55 vero connmand[380]: eth0 {add} address 192.168.27.158/24 label eth0 family 2

Both Kodi and the NFS mount(s) are starting before the device is connected to the network.

You’re also seeing

Apr 25 06:36:54 vero ovpn-USMidwest[399]: RESOLVE: Cannot resolve host address: us-midwest.privateinternetaccess.com:1198 (Name or service not known)

for the same reason.

13

The ovpn line is my install of openvpn, trying to connect before the interface comes up apparently, which seems odd because it should have the correct systemd targets. But you can see it connect shortly later.

So the failed mount due to network makes sense. But following access attempts after the link comes up should succeed, and they aren’t.

14

Not until “Wait for Network” is enabled.

The log shows that systemd tries 6 times to connect to the NFS share, and finally gives up:

Apr 25 06:36:51 vero systemd[1]: home-osmc-mnt-mybook.automount: Unit entered failed state.
15

Similar ticket : Fstab automount broken?

I’ll try toggling that option around tonight.

16

Hi,

From looking at the log, I’m not sure how the update would have stopped this working as you expect; in fact I would expect wait for network to have to be enabled for it work as you’ve described. I’m not saying what you are describing is impossible or wrong, just odd that’s all.

Anyway you may have mileage with simplifying the fstab entry, for example intr has been deprecated since kernel 2.6.25. I would try something like:

media.home.lan:/tmp/mnt/sda1  /home/osmc/mnt/mybook nfs noauto,x-systemd.automount

Also I would consider looking at autofs, as it more tolerable of network outage; or in this case just not up yet. Details can be found here:

Thanks Tom.

17

Thank you :slight_smile: I’ll look into this tonight and report back.

1 Like
18

So ‘wait for network’ seems to have solved my issues. I’m able to mount via fstab and autofs. autofs is also able to mount the share with ‘wait’ disabled, but I’m going to leave it checked, as without it I get some startup errors until autofs retries.

I’m curious to know why this behavior changed with this update, but thanks to everyone for the help and the autofs suggestion!

1 Like
19

The behaviour probably didn’t change; but Kodi may be starting slightly earlier now which would’ve exposed this race condition.

Sam