NFS FSTAB mount not working on boot anymore

Changing this value didn’t change anything.

Actually, now I noticed that I also changed the order of the two mounts in FSTAB, so now the second mount is not mounted properly. Although both NAS shares are identical(ly configured), one is mounted properly and one isn’t. :expressionless:

On a side note: the mounting of one of the shares isn’t working even when the NAS doesn’t have to be woken up and is already running and ready for access.

Does this tell you anything (the two mounts have different names)?:

osmc@osmc:~$ sudo mount -av
/mnt/MyBookLivexxx      : ignored
/mnt/MyBookLivexxx       : ignored

Or this (result of journalctl -xe):

-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit remote-fs.target has begun shutting down.
Jan 04 12:38:06 osmc systemd[1]: mnt-MyBookLive_HH.automount: Path /mnt/MyBookLixxx is already a mount point, refusing start.
Jan 04 12:38:06 osmc systemd[1]: Failed to set up automount mnt-MyBookLivexxx.au
-- Subject: Unit mnt-MyBookLivexxx.automount has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit mnt-MyBookLivexxx.automount has failed.
--
-- The result is failed.

@Chillbo: Well, you specify the ip address in the fstab but use the dns name when mounting manually.
Are you sure the NAS still has still the same ip assigned like specified in the fstab?

Other direction:
If you specified the ip of the OSMC device in the NAS devices to allow access, are on both devices the correct and actual ip configured?

It’s not the DNS name, it’s the FSTAB mount name. When I type a different name it gives me this:

mount: can't find /mnt/MyBookLivexx in /etc/fstab

Yep, just checked again :+1:t2:

I didn’t specify any IP in my NAS devices. I’m just using the NFS access that is already pre-configured on my NAS. And the config is the same on both devices, working flawless on one of them with my Vero and flawlessly on both from my RPi3. The FSTAB config is exactly the same on my Vero and my RPi3.

And you use the same mount point /mnt/MyBookLivexxx for both NAS?

No. The xxx is just a placeholder… There are two mount points under /mnt/

@Chillbo: Looks you’re an experienced user, some logs would be fine:

BTW.: I Always use fstab-options " defaults,x-systemd.automount,noauto" with my Synology NAS since years without problems. Perhaps you also give this a try.

Here in the forum, yep! Just not when it comes to FSTAB. Will provide logs in a minute…

It should not be different but it shows you easier what’s going on. So SSH into the Vero and run ls -lah /mnt/MyBookLive will try to mount it show either the empty directory or the mounted one.

sudo journalctl | grep -i nfs will show you all nfs related messages

If it is always the first mount not working have you tried to create a fake first mount entry in the hope the next two will work (not a solution but a workaround)

Ok, got that. Result of this command after reboot:

osmc@osmc:~$ ls -lah /mnt/MyBookLivexxx
total 8.0K
drwxr-xr-x 2 root root 4.0K Jul 20 11:18 .
drwxr-xr-x 4 root root 4.0K Jul 20 11:18 ..

For the other mount it gives me this:

osmc@osmc:~$ ls -lah /mnt/MyBookLive_xxx
total 452K
drwxrwxr-x 8 root osmc  64K Apr  5  2014 .
drwxr-xr-x 4 root root 4.0K Jul 20 11:18 ..
drwxr-xr-- 2 root root  64K Jan  3 14:36 .mediacrawler
drwxrwxr-x 5   99 osmc  64K Nov 28 20:01 Bilder
drwxrwxr-x 4   99 osmc  64K Nov 27 15:28 Musik
drwxrwxr-x 9   99 osmc  64K Jan  3 12:55 Public
drwxrwxr-x 4   99 osmc  64K Nov 20 06:07 Sicherung
drwxrwxr-x 5   99 osmc  64K Mar 25  2016 Videos

This is what I get with this command:

osmc@osmc:~$ sudo journalctl | grep -i nfs
Jan 04 13:05:30 osmc kernel: RPC: Registered tcp NFSv4.1 backchannel transport m                                                                                                                                                                                                                                             odule.
Jan 04 13:05:30 osmc kernel: FS-Cache: Netfs 'nfs' registered for caching
Jan 04 13:05:30 osmc kernel: NFS: Registering the id_resolver key type
Jan 04 13:05:30 osmc kernel: nfs4filelayout_init: NFSv4 File Layout Driver Regis                                                                                                                                                                                                                                             tering...
Jan 04 13:05:30 osmc kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb                                                                                                                                                                                                                                             .de).
Jan 04 13:05:30 osmc systemd[1]: Starting Preprocess NFS configuration...
Jan 04 13:05:30 osmc systemd[1]: Started Preprocess NFS configuration.
Jan 04 13:05:30 osmc systemd[1]: Reached target NFS client services.
Jan 04 13:07:09 osmc systemd[1]: Starting Preprocess NFS configuration...
Jan 04 13:07:09 osmc systemd[1]: Started Preprocess NFS configuration.
Jan 04 13:07:09 osmc systemd[1]: Starting Notify NFS peers of a restart...
Jan 04 13:07:09 osmc systemd[1]: Starting NFS status monitor for NFSv2/3 locking                                                                                                                                                                                                                                             ....
Jan 04 13:07:09 osmc systemd[1]: Started Notify NFS peers of a restart.
Jan 04 13:07:09 osmc systemd[1]: Started NFS status monitor for NFSv2/3 locking.                                                                                                                                                                                                                                             .

So, one of the mounts is not working. And the order doesn’t matter. Just changed it. Still only the one that wasn’t mounted before isn’t mounted properly either after changing the order (first, second place - doesn’t matter).

What I noticed now, as I disabled “update library (music and video) on startup” for the logging, suddenly the mount is mounted on boot properly. I should add: only the mount that wasn’t mounted before is feeding my library. The other mount is just there to be accessible when needed. So, disabling auto update of the libraries only affects the mount that wasn’t mounted before… :face_with_raised_eyebrow:

This is reproducible… Auto updating the library (with the library fed only by the mount that isn’t mounted) prevents the mount from being mounted every time. Disabling this setting (not updating the library on startup) allows the mounting to work as expected - every time after a reboot.
Any ideas? :see_no_evil::joy:

Well could be that the auto update was locking the directory before the automounter jumped in to mount the share (just a guess)

That’s what it looks like… But why does it prevent the mounting from happening? Even when trying to access the mount afterwards.

And this should definitely not happen! I’d like my library to auto update (Normally I’d use the auto update library addon aswell to have regular updates of my library. But I have this uninstalled for now, so it’s not messing with the issue here.).

As I got the hint to use NFS FSTAB mounting from @sam_nazarko… Do you have any idea why these two things (NFS FSTAB mounting and auto updating the library) seem to be interfering and how this could be solved?

Side note here again: My RPi3 is auto updating its library from the other NFS FSTAB mount the same way the Vero is auto updating its library from the mount we’re talking about here. But it doesn’t prevent the mount from showing up on the RPi3. There, mounting of both mounts and auto updating the library from one of them is working like charm…

To have this complete… Two logs from my Vero 4k:

The first log with library auto updating on startup activated - and the mount it feeds its library from not being mounted on boot.

The second log with library auto updating on startup deactivated - and the mount it feeds its library from being mounted properly on boot.

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. :face_with_raised_eyebrow: