Since upgrading from Fedora 40 to the newer releases (41, 42) my NFS mounts assigned in my FSTAB no longer mount at boot. I have used the same fstab setup with only minor changes since Fedora 32. I have checked the SELinux logs with no denial found. To be sure that was not the problem I also tried changing SELinux to permissive mode, no changes. To be clear, I can run a “mount -a” command that works.
That is strange, afaik the _netdev parameter should instruct systemd to wait with mounting the share until the network is online so it is not obvious to me right now why it fails. I take it that the NFS share has been available the entire time?
Yes, the share has not experienced any downtime. This is purely a result of moving to a newer Fedora version. I updated from 40 to 41, and assumed it was just a bad upgrade process. I freshly installed Fedora 42 to find it is still a problem.
Thanks for the help, that seems to have worked on the share I tested with. I find it a little odd the background tag, and system-d automount just now became an issue.
I had a look at the manpage and I am not sure what exactly both of these options do. But as far as I understood they might be conflicting or might need configuration to work. The computer will try to mount everything in the fstab at boot even without these options. I think only reason you might wanna look into the ‘bg’-parameter might be because it can apparently remount the drive when the connection breaks. But as I said I never used those so I am not familiar with their usage.
I’ve been using autofs for eons on Fedora so that I don’t have to fiddle with these options.
Autofs dynamically mounts shares at point of access and unmounts after a period of inactivity. Mounting nfs and cifs shares (with some config) is enabled out of the box.
I find it perfect to access any nfs shares in my homelab by simply natigating (e.g. cd) into /net/<machine>/<share>. Simply add bookmarks to your most commonly accessed shares in “Files” and you have the benefit of GUI operations.
I tested this command with a few variations. The actual problem was x-systemd.automount, the bg command may be deprecated but doesn’t break it.
I’ll have to look into the autofs. I’ve been using the fstab setup for well over 10 years, and it has just migrated along with me through the years.
Some 10 years ago I recognized that I fiddle with network shares too much in my homelab and don’t want to update fstab entries across machines all the time.
dnf install autofs
systemctl enable --now autofs
Now you can access nfs shares in the /net folder.
I don’t know why Linux distros don’t make this behavior default… probably something to do with security
My NFS shares come from a Truenas box. I make sure that the user I setup for ACL permissions to the share has the same login name, and password that is used on the individual computer.
Alternatively you can use authentication like kerberos if you are on NFS v4.
By default nfs uses id mapping between machines to authenticate users, then common (LI/U)NIX groups and permissions for file access. Adequate for (my) home lab.
I moved away from TrueNas because it got into my way in too many ways. Security was one of them.
So, I think there are different ways to authenticate with NFS, but I don’t want them
I have nothing really to add other than on pure arch I had similar issues yesterday…it worked the day before so what gives?! Yeah syntax depreciation…the silent killer.
Wandering sideways from the topic here, but as a desktop I always found handling of ephemeral network shares to be the single most frustrating part of the experience.
The kernel(s) seem to bear an implicit historical expectation that filesystems shouldn’t unmount for any reason. the DE’s do their own thing up in userspace with media/gigantic-hash/path that maybe terminal applications can’t even use presumably because portals. and they might not be the same path on another device.
systemd automount has worked ok for me. but still flakes out, horribly even with 10s timeouts still on e.g. a laptop were it’s often hopping off-network, or on, and off vpn. then locks the terminal (can’t ls/ df) and sometimes so bad it kills the DE session on e.g. wake from sleep. I assembled a short script to unlink all the remote shares, and run it from -sh (because autocomplete also locks). ok, this is maybe 30 seconds twice a day, but I’m tempted to daemonise it to do that if it just can’t ping the fs.
Honestly I could not tell if autofs was (probably only in the eyes of systemd-omnivore) deprecated (did I use it on solaris; can’t remember). It is worth a look.
I see it’s been solved already, but just wanna add regardless:
With those options, it looks like the mount wasn’t even attempted. fstab will mount everything automatically, and will fail and stop the boot unless nofail is specified. Now given that it didn’t fail and stop the boot, that would leave as the only conclusion that it wasn’t even attempted in the first place.
Why that is or why it changed from one release to the next I’m not sure, would probably have to take a look into what changed in the NFS drivers or systemd.
@mihawk90
I checked my archived documents, this has been the exact configuration of my fstab since at least 2019. That would have been Fedora 29. It had worked absolutely with no issue until the implementation change in Fedora 41. What changed at the point I have no idea.
@anon21802893
Yes, a lot of the options added in my command through the years were caused from option deprecation. At one time it contained intr. nfsvers=3 was added back when ubuntu was implementing different versions of nfs. Basically this thing is a cobbled together mess of options that were required based on what linux base I was using at the time.
@exovert The pauses are what lead to adding the bg option to the command if I remember correctly.
it was caused by running two NICs on two subnets. They were originally causing delays until I created a priority queue in network manager, changed both to static IP, and explicitly assigned DNS to one of the adapters. That fixed that issue back then.
