This is strange. Is Bazzite so much different from Aurora that it does that? I receive system updates about once a week and never have problems with them, things just keep working. It is hard to understand why the system should want to edit the fstab file, it’s a personal file the user can change after the initial setup to make things work the way they should work.
Hmm, maybe that’s just my lack of understanding how the atomic systems work, I’m still fairly new to it. I must have just assumed that the /etc/fstab got replaced with a new one when a new image was downloaded for a major system update.
I might give the fstab a try instead and see how it goes.
[Edit]
Added to my fstab and everything works properly. We’ll see how things go.
Thank you @JandeMus and everyone else who helped me through this learning experience.
Great to see it works now. Enjoy it.
I’m also successfully using /etc/fstab for my NFS mounts in Bluefin. A few additional helpful mount options for NFS shares include:
-
x-gvfs-show: Show mount entry in the UI (Nautilus)If the directory for a device is known and outside
/media,$HOME(typically/home/foo) or/run/media/$USERthen the device is not shown in the user interface. Additionally, if any of component directories in its directory starts with a dot (“.”), the device is not shown either. This policy may be overriden by use of the optionsx-gvfs-showandx-gvfs-hide.
Instead of auto-mounting (at boot), one can also specify the entry to be mounted on demand (i.e. on access). To do so, don’t specify the x-systemd.automount option but instead:
-
With
noauto, the mount unit will not be added as a dependency forlocal-fs.targetorremote-fs.target. This means that it will not be mounted automatically during boot, unless it is pulled in by some other unit. Theautooption has the opposite meaning and is the default. -
With
nofail, this mount will be only wanted, not required, bylocal-fs.targetorremote-fs.target. Moreover the mount unit is not ordered before these target units. This means that the boot will continue without waiting for the mount unit and regardless whether the mount point can be mounted successfully. -
Allow any user to mount and to unmount the filesystem, even when some other ordinary user mounted it. This option implies the options
noexec,nosuid, andnodev(unless overridden by subsequent options, as in the option lineusers,exec,dev,suid). -
softorsofterr(optional) -
softreval(optional)
Well I tried the noauto option but either I am doing something wrong, or it doesn’t work.
I wrote the noauto option instead of x-systemd.automount in the fstab line
Rebooted after having saved the file
I then typed ls /mnt/NAS which gave me no result, meaning the NAS was not mounted (yet)
Opening the file-manager and clicking on the NAS entry gave me also nothing, in other words the mount is not mounted. (if I understand it correctly)
Do I do something wrong and if so, what?
Sorry, my choice of words with “mounted on demand” was probably a bit misleading, executing mount <mountpoint> is still required. Nautilus does that when clicking on a network share that isn’t yet mounted.
You need to also specify users or user to be able to mount without root privileges.
Hi again,
I now use:
192.168.x.xxx:/nfs/Public /mnt/NAS nfs x-systemd.noautomount 0 0
Computer boots without problem when the Nas is not connected (switched off)
After switching it on, as soon as I want to see what is in the Nas, connection is made and the Nas is mounted.
This is better than it was with x-systemd.automount where the laptop boot process was halted until the Nas was switched on.
I think I will leave it like this for a while to see how things are working out for me.
Thanks for your help.
Ehm, is x-systemd.noautomount a valid mount option at all? I never heard of it and couldn’t find a single reference on the web…
This is better than it was with
x-systemd.automountwhere the laptop boot process was halted until the Nas was switched on.
What about
192.168.x.xxx:/nfs/Public /mnt/NAS nfs x-systemd.automount,nofail 0 0
?