SOLVED NFS share doesn't mount at boot

[wschmbomrpqg]

Hello everyone.

This is not completely related to FreeNAS but I hope it is okay to post this here.

I try to mount a NFS share from FreeNAS on my computer running Debian 10.
It does not automatically mount at boot but if I try manually afterwards, it just works fine.

This is the error message I get: mount.nfs: Network is unreachable

And this is my /etc/fstab:

Code:

# <file system>              <mount point>   <type>   <options>                                                                               <dump>  <pass>
10.0.0.4:/mnt/pool/dataset   /mnt/NAS        nfs      defaults,rw,nfsvers=4,minorversion=1,x-systemd.after=network-online.target,_netdev      0       0

I've already added the mount options x-systemd.after=network-online.target,_netdev as suggested in several places around the internet.
But this didn't help...

I'd appreciate if anyone has an idea how I could get this to work.

(Or should I just use SMB/CIFS?)

 

[Elliot Dierksen]

It is totally not FreeNAS related, but I think the problem is that the system isn't ready to mount it at that point in the boot process. You have the mount listed with a pass number (last field) of 0. I would suggest a pass number of 2 or higher. That would make it try to mount that file system later in the boot process. I bet your network stack isn't ready at pass 0.

 

[Elliot Dierksen]

https://en.wikipedia.org/wiki/Fstab Pass number has to do with fsck order, not mounting order. That means disregard the earlier comment. I still think it means networking isn't ready when the mount is attempted, but it is by the time you log in. Does it have the ability to do netwait? That would be for it to pause after networking is started until the netwait target (usually the default gateway) is reachable by ICMP. Then perhaps the mount would succeed during the boot process.

 

[Fredda]

I'd appreciate if anyone has an idea how I could get this to work.

You could use the automounter instead. This way the share does not get mounted on boot but at the time someone tries to access it.

 

[KrisBee]

@wschmbomrpqg Edit your fstab to simplify the nfs entry to:

Code:

10.0.0.4:/mnt/pool/dataset   /mnt/NAS        nfs      defaults     0       0

Here's an example:

Code:

root@debian10vm:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=f653c0ec-551e-4fea-88cb-99528b660e6f /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=8867e107-9307-4d6b-b8b7-e0f115d9729d none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
192.168.0.22:/mnt/NasPool/ndata /mnt nfs defaults 0 0
 
root@debian10vm:~# nfsstat -m
/mnt from 192.168.0.22:/mnt/NasPool/ndata
 Flags: rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.125,local_lock=none,addr=192.168.0.22

root@debian10vm:~# journalctl -xb | grep nfs
-- Subject: A start job for unit nfs-config.service has begun execution
-- A start job for unit nfs-config.service has begun execution.
Jul 29 08:28:38 debian10vm systemd[1]: nfs-config.service: Succeeded.
-- The unit nfs-config.service has successfully entered the 'dead' state.
-- Subject: A start job for unit nfs-config.service has finished successfully
-- A start job for unit nfs-config.service has finished successfully.
-- Subject: A start job for unit nfs-client.target has finished successfully
-- A start job for unit nfs-client.target has finished successfully.
Jul 29 08:28:38 debian10vm kernel: FS-Cache: Netfs 'nfs' registered for caching
root@debian10vm:~#

 

[wschmbomrpqg]

Does it have the ability to do netwait? That would be for it to pause after networking is started until the netwait target (usually the default gateway) is reachable by ICMP.

I don't know what you mean by that.
The _netdev and x-systemd.after=network-online.target option I passed should do exactly that. Wait with mounting until the network is reachable. (And it always worked like this when I used cifs shares with my old Synology NAS)

Edit your fstab to simplify the nfs entry to:

That was the first thing I tried. Didn't work either.

 

[Samuel Tai]

Connecting to NFS shares at boot using fstab in Debian 9 Stretch – IGR IT blog

Try option: x-systemd.automount.

 

[wschmbomrpqg]

I know about the automount thingy but I don't like it.
Had this setup some time ago with cifs shares and when I tried to access my KeePass databased on that share, KeePass complained that there is no such file. So it didn't get automounted if KeePass tried to access a file on the share.

I always had to click on the share in my file manager. Which was quiete annoying.

 

[Patrick M. Hausen]

In FreeBSD I would recommend using the "bg" (background) option for the mount. You might want to look for the equivalent in Linux.

 

[Elliot Dierksen]

I don't know what you mean by that.

In FreeBSD/FreeNAS, there is an option to tell the system to pause during the boot process until a particular IP address (usually the default gateway) is reachable via ICMP. It sounds like something isn't ready yet when the mount is attempted. Is your client using a static IP address or DHCP? What kind of switch (if applicable) is the client connected to?

 

[Samuel Tai]

How about mounting it from /etc/rc.local after all the networking comes up?

 

[wschmbomrpqg]

In FreeBSD/FreeNAS, there is an option to tell the system to pause during the boot process until a particular IP address (usually the default gateway) is reachable via ICMP... Is your client using a static IP address or DHCP? What kind of switch (if applicable) is the client connected to?

But the client is not FreeBSD, it is Linux.
The client does have a static IP but configured via DHCP, not on the client itself.
It is connected to a "dumb" switch. Nothing special there.

How about mounting it from /etc/rc.local after all the networking comes up?

/etc/rc.local is deprecated and shouldn't be used anymore.

I found that "the correct way" would be to create a systemd service...
But to be honest that sounds a bit weird. I just want to mount that stupid share.
Can't be that hard, wtf.

I will just use autofs now. At least this works.

 

[Patrick M. Hausen]

Let me google that for you:

Common NFS mount options in Linux – The Geek Diary

It is important to know the parameters used while mounting the NFS mount points on clients. It is particularly important to know them if you are facing a performance issue or a functional issue with the NFS mount point. Below is the list of options used while mounting NFS mount points as shown...

www.thegeekdiary.com

fg (foreground) / bg (background)

– Specify fg for directories that are necessary for the client machine to boot or operate correctly. If a foreground mount fails, it is retried again in the foreground until it succeeds or is interrupted. All automounted directories are mounted in the foreground; you cannot specify the bg option with automounted directories.

– Specify bg for mounting directories that are not necessary for the client to boot or operate correctly. Background mounts that fail are re-tried in the background, allowing the mount process to consider the mount complete and go on to the next one. If you have two machines configured to mount directories from each other, configure the mounts on one of the machines as background mounts. That way, if both systems try to boot at once, they will not become deadlocked, each waiting to mount directories from the other. The bg option cannot be used with automounted directories.
– The default is fg.

Looks you just need "bg" like I already stated is the case in FreeBSD.

 

[wschmbomrpqg]

Looks you just need "bg"

I tested it and it did not work.

 

[KrisBee]

@wschmbomrpqg Apart from changing mount option in /etc/fstab, I don't know what attempt you've made to debug your nfs mount problem, e.g looking at journalkctl -xb, systemd-analyze critical-change, listing systemd targets etc. For a std deb10 install, desktop or server, nfs client mounts don't work out the box, but after installing "nfs-common" the appropriate systemd targets etc should be configured. The systemd fstab generator parses and auto generates the mount units. As an alternative you can create the appropriate .mount ( and .automount) unit files and start/enable these, but I wouldn't expect that to be necessary. If it's a desktop install and you've changed how your networking is handled - removed network manager for example - that could be one reason the typical systemd boot sequence is giving you a problem.

 

[wschmbomrpqg]

I've installed the nfs-common package for sure. :D
As I've said it worked with a manual mount -a.

The problem is indeed that the network isn't available at this time in the boot process.

edit: Since the automount works for now I'll mark this topic as solved.
Thanks to anyone!

 

[KrisBee]

As a post-script did you actually look at dmesg etc to see if you system was trying to mount the nfs share before dhcpclient succeeded?

 

[wschmbomrpqg]

With sudo dmesg | grep -i dhcp I can't find anything.
What's the keyword I should be looking for?

 

[KrisBee]

Of course, I should have written journalctl, not dmesg ( old habtis! ). If you ever want to give systemd automount another go, you could easily end up with something like this in /etc/fstab to try to cover various eventualities:

Code:

10.0.0.4:/mnt/pool/dataset   /mnt/NAS nfs _netdev,x-systemd.automount,noauto,x-systmed.mount-timeout=10s,timeo=14,x-systemd.idle-timeout=60

Then you can watch both "journalctl -u mnt-NFS.mount" and "journalctl -u mnt-NFS.automount" to see if it works as expected. ( check systemctl -t mount for correct mount unit names)