Should I edit /etc/fstab?

General
22

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.

23

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.

24

Great to see it works now. Enjoy it.

25

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/$USER then 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 options x-gvfs-show and x-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:

  • noauto:

    With noauto, the mount unit will not be added as a dependency for local-fs.target or remote-fs.target. This means that it will not be mounted automatically during boot, unless it is pulled in by some other unit. The auto option has the opposite meaning and is the default.

  • nofail:

    With nofail, this mount will be only wanted, not required, by local-fs.target or remote-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.

  • users (or user):

    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, and nodev (unless overridden by subsequent options, as in the option line users,exec,dev,suid).

  • soft or softerr (optional)

  • softreval (optional)

27

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?

28

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.

29

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.

30

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.automount where 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

?

31

Hey folks, I just wanted to share a weird thing that started occuring with my systemd mounted NFS shares.

I don’t know why, maybe an update changed something, but my Bazzite gaming PC started chewing a tonne of data from my TrueNAS NFS shares that are auto-mounted.

What it ended up being was my systemd localsearch file indexing process indexing my NFS shares.

I found it by looking in btop and finding the process consuming CPU and then network traffic. It shows as systemd → localsearch3.

I use systemd to automount my NFS shares in /etc/fstab like this:

192.168.1.100:/mnt/hdd/music/ /home/user/nas-mounts/music nfs rw,user,noauto,async,noatime,x-systemd.automount,x-systemd-timeout=10s,,x-systemd.mount-timeout=10s,x-systemd.idle-timeout=10min,x-systemd.requires=network-online.target 0 0

I think my issue likely stems for mounting the NFS share inside my home directory which should be getting indexed.

There’s a few fixes:

  1. Mount your NFS shares somewhere outside of the home directory.

  2. Add a .trackerignore file to the folders so the systemd localsearch process ignores those directories

I went with 2 because it was the easiest. I have not properly tested 1 may do so later to confirm it work.