In my homelab I’ve got a TrueNAS and I stored my pictures, music and videos on there. Via a NFS share I mounted with autofs the folders to my Linux laptop. I mounted these with autofs at /mnt/nfs/music, /mnt/nfs/pictures and /mnt/nfs/videos.
I used a symbolic link to link the contents of these directories to /home/Music/, /home/Pictures/ and /home/Videos/
I specifically did it this way, so that the Music, Pictures and Videos folder would not cause the Files application to freeze if it got disconnected with TrueNAS. It would only keep loading if one would click on the actual directory (i.e., Music, Pictures, Videos) while the system searches unsuccessfully for the linked content in that case.
However, when I add the symbolic links of the contents, autofs never unmounts these directories when they are not in use. Except for the videos folder, which is empty. The moment I add these symbolic files, I can hear the hard disks of the TrueNAS spinning and with sudo nethog I can see a large data transfer between the TrueNAS and the client by the root user with no PID.
It seems as if the laptop system is sort of indexing the contents, while it does not feel the need to do that with the /mnt/nfs/* folders. However, even after the indexing seems over, with watch "mount | grep nfs" I see that the NFS directories for pictures and music remain mounted.
Anyone has experience with this? And possibly knows what is happening and/or knows how to solve it?
Thank you @jay! I do indeed use GNOME. I’ve added .trackerignore in the root of the directories and it does seem indeed that the system stopped indexing. I don’t hear the hard disks of the TrueNAS spinning as hard as before, but with watch "mount | grep nfs" I see that the NFS shares are not automatically unmounting, except for the (empty) Videos directory.
So something else seems to be at play as well. I only had Firefox and the terminal active while waiting for the unmounting. What can I do to see what’s happening, what’s keeping the NFS directories active?
What distro are you using? It might be systemd at play, it’s pretty known that systemd auto mounts stuff often, or doesn’t let go of existing mounts, even if they are mounted using autofs. Actually, autofs in particular is not recommended for systemd systems.
You should use systemd automount. I’m not familiar with it myself, because I prefer autofs, but here’s something I found. It’s not very complicated, compared to autofs.
I used lsof but there were no open files handles within the shares.
I then went with systemd automount and after I set it up, I got the same problem. It all works as supposed to when only mounted at /mnt/nfs/* but once I create the symbolic links to the contents from within the ~/Pictures or ~/Music folder it does not automatically unmount anymore.
systemctl status mnt-nfs-Pictures.automount gave the following result:
● mnt-nfs-Pictures.automount - Automount Pictures
Loaded: loaded (/etc/systemd/system/mnt-nfs-Pictures.automount; enabled; vendor preset: enabled)
Active: active (running) since Sat 2023-03-18 16:51:01 CET; 2min 14s ago
Triggers: ● mnt-nfs-Pictures.mount
Mar 18 16:51:01 M70q systemd: Set up automount Automount Pictures.
Mar 18 16:51:02 M70q systemd: mnt-nfs-Pictures.automount: Got automount request for /mnt/nfs/Pictures, triggered by 69550 (gmain)
Mar 18 16:51:33 M70q systemd: mnt-nfs-Pictures.automount: Got automount request for /mnt/nfs/Pictures, triggered by 69558 (Monitor thread)
Mar 18 16:52:15 M70q systemd: mnt-nfs-Pictures.automount: Got automount request for /mnt/nfs/Pictures, triggered by 69558 (Monitor thread)
Mar 18 16:52:56 M70q systemd: mnt-nfs-Pictures.automount: Got automount request for /mnt/nfs/Pictures, triggered by 69558 (Monitor thread)
So it seems that ‘Monitor thread’ is keeping the automount from timing out. Possibly this could be the same culprit as with AutoFS.
But even if it gets automatically unmounted, the Monitor thread gets it re-mounted again.
I tried searching to learn more about ‘Monitor thread’, but I only get articles about monitoring cpu threads. Do you have an idea what this could be?
I think I may have experienced something possibly related to this. it was a long time ago, so please excuse how vague this is going to be. I never did fully get to the bottom of it so I never added this to my notes.
So, while using AutoFS and having a mount exist within my home directory, it acted very very very odd. It seemed that having the mount point a few subdirectories lower may have helped, but I’m not sure. I tried for a while to find a solution but ended up having to move on to something else. So what I ended up doing was creating the parent directory for mounting things at /mnt/truenas. In addition to that, I changed my users default folder settings in ~/.config/user-dirs.dirs so that way my “Music” directory (for example) would relate to a subdirectory under /mnt/truenas.
I know that my situation was not completely the same as yours, I wasn’t using symlinks for example. But I wonder if both of us ran into the same issue, even though the way we went to solve it is different. My conclusion at that time was that there’s something within the home directory that’s being factored in where it probably shouldn’t. Unfortunately, I ran out of time.
I don’t remember why I didn’t try that when I ran into the issue I did. But it can sometimes work better than symlinks.
Other AutoFS and systemd-automount issues I have yet to solve:
Folders will sometimes unmount, even when I have a file manager open to a directory within the mount. It will keep pushing me back one level until I end up back at the root folder. To counter this, I have to run “watch ls” in a terminal attached to that directory to get it to stop doing that.
Samba shares don’t automatically refresh. So when I save a file, I have to hit F5 every time to see it. I know that this is by design when it comes to Samba and is actually expected behavior. But then again, other operating systems don’t have this issue so somebody somewhere managed to solve this.