Differences in permanently(FSTAB) auto mounting NFS share (client) Gnome vs. XFCE

Support Network
,
1

Hi,
I successfully modified FSTAB file to automount an NFS share in Manjaro XFCE, it automounts after reboot.

I modified the exact same file(FSTAB) with the exact same text in Manjaro Gnome on a different machine(same NFS share), but the share dose not automount after reboot. Please note the share can be mounted manually, but after reboot, it does not automount, but functions normally after manually mounting.

Is there a difference in automounting via FSTAB in XFCE vs. Gnome distributions?

Thanks

2

My guess is that it would be a timing issue. You cannot mount a remote filesystem before the network is up, and it’s probably due to that.

1 Like
3

Thanks Aragorn,
How would I check the “timing issue”?
Thanks

4

Well, you could check the boot log… :arrow_down:

journalctl -b

Another option is… :arrow_down:

systemd-analyze critical-chain
5

It gets worse than that. The logic behind “network is up” is all over the place when it comes to Linux.

It could be…

  • The network interface itself is up/active
  • An IP address has been assigned to the network interface
  • A server on the local network is reachable
  • An internet target is reachable (e.g, “google.com” or “8.8.8.8” or “manjaro.org”)

Not even the provided systemd targets address this thoroughly, as seen in previous threads on this forum.

You could create your own custom “target”, which returns “true” when the NFS server is reachable (by ping), in which a systemd-mount (or fstab entry) depends on this target.

Just as an aside, I have a systemd service that rsyncs to a local NAS server, and when I view the logs it indeed shows that it “fails” multiple times before actually running when I resume from suspend. (This is because within the script, it keeps trying to ping the local NAS server every 2 seconds, and only when the NAS server responds to the ping will the rsync task execute. Think about that…) Before I had that “condition” the systemd service would fail and abort, to much of my confusion.)

1 Like
6

systemd-mount is probably a more reliable way of doing it than /etc/fstab if the NFS client isn’t kept running 24/7. :thinking:

7

It’s not only that. Some network adapters are terrible about establishing a working connection when resuming from suspend, for example. My laptop lacks an ethernet port, and so I have to use a USB-C-to-RJ45 dongle, which takes it dear sweet time to re-connect after resuming from suspend. :cry:

EDIT: I prefer the systemd units method (since it feels more “modular” and you can make copies of these files to use for later or as templates), but some people will hold a knife to your throat if you dare veer away from the fstab.

1 Like
8

For networked storage, this is undoubtedly the superior method.

1 Like
9

I don’t hate the guy, but I was never a fan of Lennart Poettering. :unamused:

:face_with_hand_over_mouth:

@dude_1776, in your case, it’s not “resume from suspend” but “immediately after reboot” that seems to be the issue. However, I wouldn’t be surprised if you noticed the NFS mount hangs for a few seconds (or more) if you resume from suspend from this machine. :person_shrugging:

1 Like
10

Since the topic has no marked solution - I suggest using system units to do the lifting

A generic introduction to mount units

An example on how to create NFS mount which doesn’t hang your system on boot or waking up