NFS FSTAB mount not working on boot anymore

Hello there,

first time in a long time I’m having an issue that is really annoying me and I can’t figure out what the problem is. After a lot of smaller issues that came up related to bandwidth here in the forum I changed my NAS mounts to NFS using FSTAB. This has been working like a charm for a while now, but since some time ago (I suspect the Debia Stretch test build) one of my two shares I’m mounting on boot is not mounting properly anymore.

Both mounts are located on two identical MyBookLives on which I configured NFS access via a osmc user without any password. The FSTAB lines I have been using for quite some time without an issue are these:

192.168.xx.xx:/nfs /mnt/MyBookLive nfs soft,intr,noexec,rsize=65536,timeo=150,noauto,x-systemd.automount 0 0

Both mounts used this line with different IPs obviously. After it stopped working for the first mount of the two, I tried changing the line to this:

192.168.xx.xx:/nfs /mnt/MyBookLive nfs soft,noexec,nosuid,nodev,noatime,rsize=16384,wsize=16384,intr,x-systemd.automount 0 0

Still, the first NFS mount is not mounted on boot. When I use sudo mount /mnt/MyBookLive the share is mounted without a problem. It’s just not working after booting up the Vero.

Side note: mounting the same moung via NFS FSTAB from my RPi3 is working like a charm on boot.

Is there an obvious issue with my FSTAB lines that could cause this? Or are logs needed?

Cheers! :slightly_smiling_face:

Is this supposed to be timeout?

Also have tried to access the mounts from command line (eg ls) as they are not mounted by default but only when accessed.

Check your journalctl.

timeo=n

The time in deciseconds (tenths of a second) the NFS client waits for a response before it retries an NFS request.

Thanks just read up on it, not sure if 150 is a sane value if default is 600

I only tried to access them via WinSCP (SFTP) and via the Vero itself. And the one mount that doesn’t work isn’t mounted on access then as I’d expect it to… Would it be different via command line?

I’m a total noob in many Linux areas… :see_no_evil: What should I do here?

Well, I just copied the line from somewhere and just posted it once here on the forum when I was asked to use FSTAB. The comments told me that it was fine… Which it has been for quite some time. So, to be honest, I don’t even really know what the FSTAB lines I’m using are doing exactly word by word. :joy:

This must be a timing issue. We had a long discussion on systemd dependencies with @dillthedog @bmillham recently, but can’t find it now.

Edit: Just realised it’s all in the [Howto] post linked below.

1 Like

Without any background knowledge, that was what I expected it to be, too. Because the first mount is not mounted, but the second one always is. Any ideas how to solve that? Maybe delaying the mounting on boot a bit, so that it’s working properly (maybe the network is not ready yet?)…

BTW: using LAN here. So, there’s no long waiting for the Wifi to connect here.

At risk of being excommunicated for heresy of not using fstab, I’m using systemd unit files on vero to mount shares on a Pi: [How to] Use systemd to mount remote shares

For nfs, I just use this:

[Unit]
Description=Mount nfs shared folder
Wants=connman.service
After=connman.service
After=network-online.target wpa_supplicant.service
Wants=network-online.target wpa_supplicant.service

[Mount]
What=192.168.1.1:/mnt/1Text4
Where=/mnt/1Text4
Type=nfs
Options=noauto,rw

[Install]

Well… I could try that some time, but I’d love to not be crucified for such an act of blasphemy :joy: In other words: I’d like to get FSTAB working again as it has been working for quite some time before.

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…