Only some fstab shares being mounted on boot

[geoff_noob]

Recently some nfs shares (homenasmedia) from my Synology NAS have not been automatically mounting on my 4K+ on boot as they did previously.

My homenasmedia share mounts perfectly using sudo mount /mnt/homenasmedia command, just doesn’t automatically mount on boot.

Unusually, my TVRecordings share does mount at boot. Why the difference? Same NAS, same config? Same fstab and mount point config.

By process of elimination I think the problem might be with OSMC OS because:

My NAS probably isn’t at fault because:

• Other nfs shares (TVRecordings) from the same NAS using the same NAS config automount during boot
• I can mount /mnt/homenasmedia manually via CLI

My fstab file probably isn’t at fault because:

• Automounting worked well using longstanding fstab until a couple or so weeks ago
• My TVRecording mount mounts automatically on boot and it has same fstab entry and mount point permissions as homenasmedia

I played around with fstab last night as i noticed noauto might be better as just auto, however changing didn’t make a difference, just thought i would try options before resorting to forum. Paste of fstab below.

My mountpoints aren’t at fault because:

• the permissions for homenasmedia are the same as TVrecordings, and TVrecordings mountpoint does automount during boot. Paste of mountpoints below.

This ‘fault’ occurred about the same time as:

• I updated to the latest version of Synology firmware
• I’ve replaced all ETH cables with new T586A spec
• I Updated OSMC to May update
• I changed from confluence skin to Aon version (from the ‘Get More’ skins function in OSMC)
• I installed a new 5 port netgear switch
• i started to use tvheadend and tvheadend htsp addon PVR client.

I don’t think this issues could be realted to new skin, switch, ETH cables or TVHE. Perhaps new firmware on NAS, however no significant commentary on Synology forums on nfs shares issue since Synology firmware update.

FSTAB
192.168.1.31:/volume1/Media /mnt/homenasmedia nfs noauto,x-systemd.automount,noatime 0 0
192.168.1.31:/volume1/Family\040Files /mnt/familyfiles nfs noauto,x-systemd.automount,ro,noatime 0 0
192.168.1.31:/volume1/TVRecordings /mnt/tvrecordings nfs noauto,x-systemd.automount,noatime 0 0
#/dev/vero-nand/root / ext4 defaults,noatime 0 0

Mount Points
osmc@vero:~$ cd /mnt
osmc@vero:/mnt$ ls -la
total 20
drwxr-xr-x 6 root root 4096 May 26 21:28 .
drwxr-xr-x 23 root root 4096 Nov 8 2018 …
drwxr-xr-x 2 root root 0 May 29 13:09 familyfiles
drwxrwxrwx 2 root root 4096 May 28 17:43 homenasmedia
drwxrwxrwx 4 root root 4096 Nov 12 2018 storage-fstab
drwxrwxrwx 4 root root 4096 May 28 19:00 tvrecordings
osmc@vero-baroda:/mnt$

Interestingly familyfiles isn’t automounting either, but like homemasmedia mount does mount manually via CLI.

Is anyone else having similar problems? Should i use the timeout option in fstab … maybe the NAS firmware update did something to nfs sharing timeouts? I did a forum search in this forum and saw a weird post about only the 2nd or 3rd entry in fstab automounting …

I’m very happy to upload log files if it helps.

Thanks in advance.

Cheers, Geoff.

[nabsltd]

Do you have “wait for network” enabled?

It’s possible that some of the mounts are trying before the network is completely connected, while other mounts don’t get called until after the network is up.

[grahamh]

@geoff_noob

I’m very happy to upload log files if it helps.

Good idea. You might like to have a poke around with systemd-analyze as well.

[geoff_noob]

i have 3 nfs shares. Changing to ‘wait for network’ ended up mounting 2 of 3. The remaining share requires CLI to mount, but then mounts well.

Https://paste.osmc.tv/cijibiwedu

(you might see that i interrupted a recording to reboot, i was aware of this and its not unexpected).

I shall learn about systemd-analyze and see if i can provide more info.

Thanks again.

GEoff.

[geoff_noob]

thx, i can run systemd-analyze OK but i can’t interpret output … is there a particular option i should run and paste results on? i.e. systemd-analyze blame or maybe systemd-analyze critical-chain?

I’m wondering if incompatibility between new Synology firmware and OSMC because this issue might have roughly coincided with update to my NAS. Mmm.

systemd.analzyse critical-chain sounds pretty grunty … pasted below is output.

-multi-user.target @13.652s
-transmission.service @3.093s +10.557s -udisks-glue.service @1.196s +1.887s
-basic.target @1.137s -sockets.target @1.136s
-avahi-daemon.socket @1.136s -sysinit.target @1.134s
-sys-kernel-config.mount @1.095s +37ms -systemd-modules-load.service @197ms +894ms
-systemd-journald.socket @193ms –.slice @83ms

Thanks, Geoff.

[grahamh]

systemd-analyze plot > output.svg can help to understand what order things are happening in. View output.svg in a browser.

[geoff_noob]

thx. When i ‘sudo systemd-analyze plot > output.svg’ i get permission denied.

sorry for my basic linux knowledge.

Cheers, Geoff.

[grahamh]

OK, just checked a few things and I suspect the problem comes from the NAS firmware update causing a timing issue. I’m not sure why @chillbo recommends noauto. I have a note that the arch wiki recommends auto which is more logical but I use noauto and it works! If you do use auto (ie the default) then use nofail as well.

The only other thing I can suggest is to add a timeout x-systemd.mount-timeout=30 (say) in fstab to allow the NAS volume to spin up if necessary and do whatever it needs to do.

[fzinken]

@grahamh

The only other thing I can suggest is to add a timeout x-systemd.mount-timeout=30 (say) in fstab to allow the NAS volume to spin up if necessary and do whatever it needs to do.

@geoff_noob
Or try if autofs solves your issue

[dillthedog]

The system seems to be working just fine.

You’ve defined /mnt/homenasmedia as a Kodi source, so it automounts when Kodi accesses it.

You’re using /mnt/TVRecordings for tvheadend, so it also automounts when tvheadend accesses it.

The third mount, /mnt/familyfiles isn’t used by either Kodi or tvheadend and systemd is simply waiting for a process to access it, at which point it will automatically be mounted.

[grahamh]

@dillthedog

You’ve defined /mnt/homenasmedia as a Kodi source, so it automounts when Kodi accesses it.

I wonder how the OP discovered homenasmedia wasn’t mounting, then?

[dillthedog]

At the beginning, “Wait for Network” wasn’t enabled.

Then OP says:

@geoff_noob

i have 3 nfs shares. Changing to ‘wait for network’ ended up mounting 2 of 3. The remaining share requires CLI to mount, but then mounts well.

The one that didn’t mount was /mnt/familyfiles.

[grahamh]

So @geoff_noob needs to enable wait for network and all is good. I don’t think this setting affects tvheadend but that seems to be working (there’s a magic sleep in the unit file).

FWIW, the way I do it since all my devices use WiFi which can take ages to come up is described here.

[How to] Use systemd to mount remote shares

You will get better performance out of remote shares if they are mounted in OSMC’s filesystem. You can do this by putting lines in fstab as described here. But there have been reports of time-outs when OSMC is shutting down. This is probably because systemd is stopping services in the wrong order. Using systemd to mount, rather than fstab, gives us greater control. Here’s how. We are going to share a folder on server 192.168.1.11 which has a share name of ShareFolder and needs username you…

[geoff_noob]

thanks all for suggestions and assistnace @dillthedog was correct, as soon as Kodi accesses an unmounted share it then mounts. @nabsltd suggestion on wait for network sorted the shares which kodi accesses (media and tv recordings). @grahamh i think also identified that latest nas firmware might have also played a role, and i think that they new firmware may not like quick concurrent mount requests or similar and i now need to use wait for network whereas in the past i didn’t. Thx chaps.