Network shares in fstab fail always if wifi, sometimes if ethernet

Ask Fedora
, , ,
1

Hi
I have two machines, one NUC 12th gen pro “wall street canyon” with an 1240P CPU/GPU and a B550 AMD platform Ryzen 5600 machine. Both are running Fedora 38 KDE (the only diff is that the AMD machine is using X11 because while color profiles can be applied in Wayland, they don’t apply gamma / brightness correctly and as such photo editing is being done on the AMD machine).

The AMD machine is connected via ethernet. On the NUC it doesn’t matter, I’ve tried both and the difference is: using wifi the network shares are never mounted, using ethernet they are on about half of the boots. The AMD machine has never failed in mounting the network share.

Both originally had this line in /etc/fstab:

//192.168.50.2/obsvault /home/to/hrod_obsvault cifs uid=1000,gid=1000,credentials=/home/to/.smb,iocharset=utf8,vers=3.0 0 0

(Now only the AMD machine has it) . For the NUC I’ve tried altering the line to include _netdev (does nothing for this issue) and x-systemd.requires=network-online.target though NetworkTarget indicates fstab will employ it automatically.

sudo systemctl is-enabled NetworkManager-wait-online.service systemd-networkd-wait-online.service replies enabled, disabled.

I tried this whole thing nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10 0 0 but it doesn’t make a difference to the NUC machine, if on wifi it will 100% of the time say mount error(101): Network is unreachable and if on ethernet around half times.

I tried making a systemd service unit that has

After=network-online.target
Wants=network-online.target

and it yields the same result, mount does not wait until the NUC has established a network connection properly.

I’ve currently “solved” it by a systemd service unit with a timer that runs 30 secs after boot (and then unmounts on power off) but I feel it would be nice if the NUC could work as flawlessly as the AMD machine. I suspect that the AMD machine is as incapable of waiting for the network to be online and is merely faster at getting online, partially because the NUC sometimes succeeds when using ethernet, but I don’t know that.

I’ve also tried to use nfs instead of samba, it makes no difference. If one samba share and one nfs share they will always both work or both fail (due to network unavailable when mount attempts to happen).

What words of wisdom have thee? : )

2

WiFi is a beast that does all manner of strange things like frequency hopping and MAC address randomization. It is also vulnerable to signal degredation from things like fluorescent (or even LED) lights.

Your best bet for a boot-time mount over a WiFi connection would probably be to script it and configure the script to retry several times. Something like the following might work (untested).

#!/usr/bin/bash

COUNT=0
TRIES=10
while ! mountpoint -q /home/to/hrod_obsvault; do
  mount.cifs //192.168.50.2/obsvault /home/to/hrod_obsvault -o uid=1000,gid=1000,credentials=/home/to/.smb,iocharset=utf8,vers=3.0
  sleep 0.5
  COUNT=$(($COUNT+1))
  [[ $COUNT -ge $TRIES ]] && break
done

You could put the above in /etc/rc.d/rc.local and enable it by executing chmod +x /etc/rc.d/rc.local. You might also want to make sure that the rc.local script starts after the network is online by creating a /etc/systemd/system/rc-local.service.d/override.conf file containing the following.

[Unit]
After=remote-fs-pre.target network-online.target
Before=umount.target
Conflicts=umount.target

[Service]
ExecStop=/usr/bin/umount /home/to/hrod_obsvault

It’s messy, but for something as unreliable as WiFi, that is probably about the best you could do. A slightly better solution might be to use autofs if you want to research that.

Edit: If you are good at writing systemd services, they actually have retry directives and mountpoint conditionals such that you could do all of the above without needing a Bash script or relying on the legacy rc-local service.

3

Thanks for your reply and advice : )

If the script would wait for network-online (which I didn’t seem manage to make mine do) it seems like a slightly nicer solution than waiting for an arbitrary amount of time after boot when you know the machine will reasonably be online and then try to mount.

(The affected machine doesn’t have to use wifi, it may as well use ethernet. I tried wifi in order to see whether it would make a difference for this, which it did)

I saw that someone had prior suggested to use networkd instead of NetworkManager so I followed https://www.addictivetips.com/ubuntu-linux-tips/set-up-systemd-networkd/ , and then left out all the extras from etc/fstab (since it reportedly should wait for the network for network boots before trying to mount), I left it like the line I gave above, and it has now worked for ten+ boots and reboots (via ethernet). It’s not definite yet since it did mount around half the time with NetworkManager but it’s looking promising.

4

Yes, I too consider systemd-networkd to be superior to NetworkManager and I configure all my systems to use it. I don’t normally recommend it to people, however, because it does have a larger “learning curve”.

For example, concerning this particular issue, systemd-networkd even has specific tunables to adjust exactly which interfaces systemd-networkd-waid-online.service will actually wait for. From the man page (systemd.network):

RequiredForOnline=
Takes a boolean or a minimum operational state and an optional maximum operational state. Please see networkctl(1) for possible operational states. When “yes”, the network is deemed required when determining whether the system is online (including when running systemd-networkd-wait-online). When “no”, the network is ignored when determining the online state. When a minimum operational state and an optional maximum operational state are set, “yes” is implied, and this controls the minimum and maximum operational state required for the network interface to be considered online.