To have this complete… Two logs from my Vero 4k:
That makes sense. But the scan takes less than a second - why is the share not mounted after that?
In the log where the mounting is not working I can find these lines:
13:33:57.436 T:4076946000 DEBUG: CDirectoryProvider[plugin://service.library.data.provider?type=recentmovies&reload=]: refreshing..
13:33:57.436 T:4076946000 DEBUG: CDirectoryProvider[plugin://service.library.data.provider?type=recentepisodes&reload=]: refreshing..
and these:
Jan 04 13:33:57 osmc systemd[1]: mnt-MyBookLivexxx.automount: Got automount request for /mnt/MyBookLive_HH, triggered by 869 (kodi.bin)
Jan 04 13:33:57 osmc systemd[1]: Mounting /mnt/MyBookLivexxx...
Jan 04 13:33:57 osmc systemd[1]: mnt-MyBookLivexxx.mount: Mount process exited, code=exited status=32
Jan 04 13:33:57 osmc systemd[1]: Failed to mount /mnt/MyBookLivexxx.
So, this seems to happen at exatly the same time. Is that observation correct?
But why is the mounting failing in the first place?
In the other log, the mounting is working on the first attempt:
Jan 04 13:37:28 osmc systemd[1]: mnt-MyBookLivexxx.automount: Got automount request for /mnt/MyBookLivexxx, triggered by 914 (JobWorker)
Jan 04 13:37:28 osmc systemd[1]: Mounting /mnt/MyBookLivexxx...
Jan 04 13:37:28 osmc systemd[1]: Starting Preprocess NFS configuration...
Jan 04 13:37:28 osmc systemd[1]: Reached target Host and Network Name Lookups.
Jan 04 13:37:28 osmc systemd[1]: Started Preprocess NFS configuration.
Jan 04 13:37:28 osmc systemd[1]: Starting Notify NFS peers of a restart...
Jan 04 13:37:28 osmc systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
Jan 04 13:37:28 osmc sm-notify[929]: Version 1.3.3 starting
Jan 04 13:37:28 osmc systemd[1]: Started Notify NFS peers of a restart.
Jan 04 13:37:28 osmc rpc.statd[932]: Version 1.3.3 starting
Jan 04 13:37:28 osmc rpc.statd[932]: Flags: TI-RPC
Jan 04 13:37:28 osmc systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Jan 04 13:37:29 osmc systemd[1]: Mounted /mnt/MyBookLivexxx.====================== fstab =================== qiE9Dtax
# 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
192.168.10.26:/nfs /mnt/MyBookLive_HH nfs soft,intr,noexec,rsize=65536,timeo=150,noauto,x-systemd.automount 0 0
192.168.11.22:/nfs /mnt/MyBookLive_Klv nfs soft,intr,noexec,rsize=65536,timeo=150,noauto,x-systemd.automount 0 0
Tell us something about “192.168.11.22” … is the the NAS you have issues with?
This ip is definetly not in your network since your network is 192.168.10 with subnet mask 255.255.255.0. Any access to this ip will be routed to your gateway 192.168.10.1.
I’ll answer your question, but it’s unrelated to the issue.
This mount is in a different network connected via a router-to-router VPN. But it’s not the mount I have issues with. The one with issues is this one: 192.168.10.26
In my logs, you can see that the mount from the other network is mounted without issues after the first one which fails:
Jan 04 13:34:59 osmc systemd[1]: mnt-MyBookLive_xxx.automount: Got automount request for /mnt/MyBookLive_xxx, triggered by 850 (JobWorker)
Jan 04 13:34:59 osmc systemd[1]: Mounting /mnt/MyBookLive_xxx...
Jan 04 13:34:59 osmc systemd[1]: Reached target Host and Network Name Lookups.
Jan 04 13:34:59 osmc systemd[1]: Starting Preprocess NFS configuration...
Jan 04 13:34:59 osmc systemd[1]: Started Preprocess NFS configuration.
Jan 04 13:34:59 osmc systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
Jan 04 13:34:59 osmc systemd[1]: Starting Notify NFS peers of a restart...
Jan 04 13:34:59 osmc sm-notify[1596]: Version 1.3.3 starting
Jan 04 13:34:59 osmc rpc.statd[1597]: Version 1.3.3 starting
Jan 04 13:34:59 osmc rpc.statd[1597]: Flags: TI-RPC
Jan 04 13:34:59 osmc systemd[1]: Started Notify NFS peers of a restart.
Jan 04 13:34:59 osmc systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Jan 04 13:35:00 osmc systemd[1]: Mounted /mnt/MyBookLive_xxx.
My RPi3 is located within the other network (192.168.11.xx) and mounting both NAS NFS mounts as well. Without any issues and with exactly the same settings.
My Vero 4k is located within the 192.168.10.xx network and mounting both NAS NFS mounts the same way…
But do my logs give any clues?
So there is a difference between Pi and vero you didn’t tell us about. It may explain why Pi can find the NAS quicker than vero.
OOPS: sorry should be the other way round. Ignore me.
No, there’s literally none! It’s the same situation just the other way round. RPi3 and Vero 4k are accessing the same two NAS in the same two networks. And they are not feeding their libraries from the same NAS mount, but from the one “closer” to them - the one within their own network.
The remote mount is just there to be accessible when needed. It doesn’t feed either the RPi3’s nor the Vero 4k’s libraries.
Do you have Wait for Network set in MyOSMC networking.?
2 Likes
If I read the log correctly, when the mounting is not working, it tries to mount before the network is ready:
Jan 04 13:33:57 osmc systemd[1]: mnt-MyBookLivexxx.automount: Got automount request for /mnt/MyBookLivexxx, triggered by 869 (kodi.bin)
Jan 04 13:33:57 osmc systemd[1]: Mounting /mnt/MyBookLivexxx...
Jan 04 13:33:57 osmc systemd[1]: mnt-MyBookLive_HH.mount: Mount process exited, code=exited status=32
Jan 04 13:33:57 osmc systemd[1]: Failed to mount /mnt/MyBookLivexxx.
...
Jan 04 13:33:58 osmc avahi-daemon[354]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.10.44.
Jan 04 13:33:58 osmc avahi-daemon[354]: New relevant interface eth0.IPv4 for mDNS.
Jan 04 13:33:58 osmc avahi-daemon[354]: Registering new address record for 192.168.10.44 on eth0.IPv4.
...
Jan 04 13:34:59 osmc systemd[1]: mnt-MyBookLive_xxx.automount: Got automount request for /mnt/MyBookLive_xxx, triggered by 850 (JobWorker)
Jan 04 13:34:59 osmc systemd[1]: Mounting /mnt/MyBookLive_xxx...
Jan 04 13:34:59 osmc systemd[1]: Reached target Host and Network Name Lookups.
Jan 04 13:34:59 osmc systemd[1]: Starting Preprocess NFS configuration...
Jan 04 13:34:59 osmc systemd[1]: Started Preprocess NFS configuration.
Jan 04 13:34:59 osmc systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
Jan 04 13:34:59 osmc systemd[1]: Starting Notify NFS peers of a restart...
Jan 04 13:34:59 osmc sm-notify[1596]: Version 1.3.3 starting
Jan 04 13:34:59 osmc rpc.statd[1597]: Version 1.3.3 starting
Jan 04 13:34:59 osmc rpc.statd[1597]: Flags: TI-RPC
Jan 04 13:34:59 osmc systemd[1]: Started Notify NFS peers of a restart.
Jan 04 13:34:59 osmc systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Jan 04 13:35:00 osmc systemd[1]: Mounted /mnt/MyBookLive_xxx.
When disabling the library auto updating on startup the order is this way:
Jan 04 13:37:27 osmc avahi-daemon[360]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.10.44.
Jan 04 13:37:27 osmc avahi-daemon[360]: New relevant interface eth0.IPv4 for mDNS.
Jan 04 13:37:27 osmc avahi-daemon[360]: Registering new address record for 192.168.10.44 on eth0.IPv4.
...
Jan 04 13:37:28 osmc systemd[1]: mnt-MyBookLivexxx.automount: Got automount request for /mnt/MyBookLivexxx, triggered by 914 (JobWorker)
Jan 04 13:37:28 osmc systemd[1]: Mounting /mnt/MyBookLivexxx...
Jan 04 13:37:28 osmc systemd[1]: Starting Preprocess NFS configuration...
Jan 04 13:37:28 osmc systemd[1]: Reached target Host and Network Name Lookups.
Jan 04 13:37:28 osmc systemd[1]: Started Preprocess NFS configuration.
Jan 04 13:37:28 osmc systemd[1]: Starting Notify NFS peers of a restart...
Jan 04 13:37:28 osmc systemd[1]: Starting NFS status monitor for NFSv2/3 locking....
Jan 04 13:37:28 osmc sm-notify[929]: Version 1.3.3 starting
Jan 04 13:37:28 osmc systemd[1]: Started Notify NFS peers of a restart.
Jan 04 13:37:28 osmc rpc.statd[932]: Version 1.3.3 starting
Jan 04 13:37:28 osmc rpc.statd[932]: Flags: TI-RPC
Jan 04 13:37:28 osmc systemd[1]: Started NFS status monitor for NFSv2/3 locking..
Jan 04 13:37:29 osmc systemd[1]: Mounted /mnt/MyBookLivexxx.
...
The second mount seems to be mounted on access here, not on boot. 
Exactly. The mount request comes from kodi.bin, presumably for the library scan. Try Wait for Network.
You asked the right question! Thank you so much!!! 
After setting it back to on, the mounting and auto updating of my library worked like a charm again.
Didn’t even have that setting in mind. It seems that it had been set as the mounts and the auto updating used to work… Maybe the Stretch test build reset that setting to off. 
What is the default state of this setting? If it’s off, it sould definitely be on in my oppinion!
Glad it worked. It makes sense to have Wait for Network on when you have a remote library but probably not otherwise.
FWIW, I enabled library update on startup on my vero and didn’t have any issues. I think that’s because I have
in my systemd unit file. I believe you can put similar options in an fstab line but haven’t tried it.
Well, the library files are located on my Vero, but the music and video files are on the NAS which isn’t so remote - it’s in the same network.
What would be the downside of having “waiting for network” on by default? If there’s no network or it’s unavailable no service would be starting until a network is available? Or is it just stopping services which need a network/internet connection?
Yeah, maybe this would be an option. The problem is: FSTAB did work before, so I never dug deeper into how it works and what can be configured. Also now, I didn’t really understand a lot when I looked for guides on how NFS and FSTAB work in general. My Linux knowledge is very limited…
Maybe someone could write a wiki entry not only for FSTAB mounts, but especially for NFS FSTAB mounts explaining what commands (like defaults,x-systemd.automount,noauto) actually do and which are useful to add… This would be awesome! 
I there is no network, a 1-minute delay in starting kodi
Well, that’s a big downside Could a setting just for library auto updating be useful here? Under “auto update library on startup” something like: wait for network to be ready before starting library auto update service
This option could be on by default and not interfere with the general “wait for network” option under MyOSMC - and the downsides of that one being turned on by default.
Might that be possible and a good idea, @sam_nazarko?
I’m not sure whether that’s something that can be done trivially.
Kodi’s ability to detect network connectivity is not always reliable; and we may end up blocking or waiting unnecessarily.
I see… That’s a bummer.
Is this option something that can be added to a NFS FSTAB mount, too? This would solve the issue, too, I guess. And “wait for network” under MyOSMC could be turned off again.
I don’t see how that would help. You won’t be able to do anything with kodi without access to your media so might as well use the setting already there in MyOSMC.
It could go in the wiki article when you have given us the first draft 
I’m a bit late to this thread, but x-systemd.automount should try to mount the share once it’s been accessed - and it’s not usually an issue that the network comes up a bit late.
I have a hunch that some of the other /etc/fstab options, notably soft and timeo, might be conflicting with x-systemd.automount. Setting “Wait for network” might work but it’s probably just side-stepping the underlying problem.
intr in /etc/fstab is ignored after kernel 2.6.25.
It just made sense in this scenario we’re talking about, because it seems to be issue - the library updating service not waiting for the network to be ready. But if it can be solved differently, obviously that would be the way to go. My point just is: the “wait for network” under MyOSMC sounds a lot more general and basic than what I proposed and doesn’t really make sense in this scenario either.
I see 
I could try… But as I said, I don’t understand FSTAB or NFS at all (and I couldn’t manage to do so until now). Would it be a good idea to have someone write a wiki entry who doesn’t understand what he’s writing about? 
But if I get help with it from others who can provide me with a list of commands one can use with NFS FTSAB mounts and what they do in which scenario, I’d be willing to do the typing…
Well, that was what I was asking before… Could someone tell me whether my FSTAB line itself is the problem. I don’t know
So, that I can take out of my line?