JoshStrobl

The context is mainly network drives, yes.

Feel free to edit the title accordingly.

WetGeek I don't see why it wouldn't work on Plasma, but yea if you aren't concerned about pulling in a bunch of deps then @ermo's HOWTO is the way to go.

    JoshStrobl changed the title to HOWTO: Set up network mounts with systemd automount .

    JoshStrobl I don't see why it wouldn't work on Plasma

    Sorry to have another question, but I want to be sure we're both referring to the same utility. I assumed the package name for GNOME Disks would probably be something like gnome-disks, but that couldn't be found. After a couple more searches, I did find gnome-disk-utility, so I installed that.

    In that utility's menus, I could find nothing to do with mounting remote shares, or any other kind of shares, for that matter. So that leads me to ask, "Am I using the right utility, or should I be looking for a different package"?

    The only reason I'm so attracted to GNOME Disks is because you said it modifies /etc/fstab. If these shares can be auto-mounted with the right options there, I'd like to see the entries it creates. I've spent a lot of time trying to make that work -- and it DID work for a while -- but then changes were made by an update, and I've needed to mount them manually ever since.

    So, if it's just a matter of installing a different package, I'd like to try that first. If not, I'll create the necessary file.

    • ermo replied to this.

      WetGeek

      Is there any particular reason you're ignoring the HOWTO at the top that literally shows you how to do it with systemd .mount and .automount units instead? 🤔

      Systemd actually parses /etc/fstab lines and then automatically converts them into (the equivalent of) .mount and .automount behind your back.

        ermo Is there any particular reason you're ignoring the HOWTO at the top

        I'm not ignoring it. Rather, I read it very thoroughly. If you'll read my post that's just above yours, you'll see the explanation why I also want to try it with fstab.

        I'm sure your method will work well, and probably on the first try. As a retired software engineer, I'm quite comfortable with creating text files, however in this case, I'm trying to figure out how a different approach once worked, and then didn't work. I'd like to see what fstab options might be able to make it work again, as a learning experience.

        Then, I'll probably create the file you illustrated, clean out fstab, and use your method. Thanks for posting that, by the way.

        ermo Systemd actually parses /etc/fstab lines and then automatically converts them into (the equivalent of) .mount and .automount behind your back.

        Yes, this describes how it worked for me before. The options column in my fstab lines invoked systemd to mount the nfs shares. Then after an update one week, that stopped working, and my options no longer worked with systemd.

        The options that once worked for me: noauto,x-systemd.automount, and I have no idea what changes caused that approach to stop working.

          • [deleted]

          • Edited

          WetGeek

          You don't need these options if you set up an automount with systemd.
          The default behavior with a systemd automount is to only mount the location on demand / when it is accessed.

          But yeah, mounting NFS or Samba shares from fstab (at boot or on demand) never worked for me no matter which options I threw at it.

          The systemd automount just works.

            [deleted] You don't need these options if you set up an automount with systemd.

            Agreed, and I've already indicated that I plan to use that method. So please, no further discouragement of fstab options. I already plan to do what you're all telling me to do. In fact, I'm almost finished with it.

            What I was ALSO trying to figure out, is what caused the fstab method to stop working, when it had previously been working great with x-systemd for a time, and what might cause that to start working again. Mysteries get my attention.

            But that part is far less important to me, and given the amount of anguish it appears to cause, I'm willing to drop it altogether. It's the "as needed" aspect that led to my decision to go with the sytemd file(s). That should save a least 1/2 second or so at startup time.

            The only thing that would make me regret using the systemd method will be if Nautilus (and other file managers) don't list the shares in their UI as they do now. They wouldn't be mounted at startup, and that would make it much less convenient to access them. I'll find out once I've changed over.

              • [deleted]

              • Edited

              WetGeek

              At least Dolphin doesn't show the mount under "Remote" until it has been mounted on demand.
              I added an entry under "Places" to it so I can just click that if it hasn't been mounted by something else before.

              I also just wanted to point out to not use those 2 options specifically inside the mount file (if you are using the systemd method) because that could lead to further trouble / errors.

              @ermo Thank you for this guide.

              I too was having issues mounting NFS shares using fstab entries. No matter what I did only mounting them in CIFS mode worked. Creating/using SystemD mounts worked perfectly for me now.

              Maybe one day @JoshStrobl will add this method information to a Solus WIKI or documentation to help others.

                WetGeek
                I just tried it. Yes Disks will install and run in Plasma.. However, it shows my storage drive already flagged to automount, but it doesn't. I'm not familiar with Disks tho, and may be doing something wrong.

                WetGeek What I was ALSO trying to figure out, is what caused the fstab method to stop working, when it had previously been working great with x-systemd for a time, and what might cause that to start working again. Mysteries get my attention.

                I maintain Samba on Solus (and have done so for a few years now) and -- like you -- used to use /etc/fstab with the noauto,x-systemd.automount options to mount my CIFS shares until it stopped working.

                Looking at my logs, it appears that the problem might be that (with the fstab approach) systemd is simply too 'eager' when trying to start the mounts; they start up before the network interface is actually ready, so once the limit is reached on the allowed tries, systemd gives up the mount and never tries them again, hence necessitating your mount -a (which works at that point because the network is actually up).

                My HOWTO isn't as much a "solution" as it is a "workaround". A slightly better workound might very well be to set up a "onFail: wait 1 second, then retry; rinse and repeat N times" rule in the units. Right now, the mount is tried repeatedly (and possibly forever) until it succeeds.

                  codewizard1975 Maybe one day @JoshStrobl will add this method information to a Solus WIKI or documentation to help others.

                  I added it here in order to gauge the interest in terms of making it an official Help Center article and in order to collect more feedback before it was suggested for inclusion in the Help Center proper. =)

                  Thank You for the kind words though and happy that you found it useful. ^^'

                  ermo systemd is simply too 'eager' when trying to start the mounts

                  I've seen this before, and someone proposed using an option that would require the mounts to be done after the network had been started, but If I recall correctly (it's been a while) that didn't work for me. However, it would be nice to find a different option that could be used that actually works.

                  My problem is that, although using mount -s is slightly annoying, fixing that has been really low on my to-do list. I start a terminal in its own workspace after every startup, and it takes very little more effort to mount everything. Maybe it's about time for me to research this further. It's been long enough since my previous disappointment that there may be newer articles with more useful information now.

                  • ermo replied to this.

                    WetGeek I've seen this before, and someone proposed using an option that would require the mounts to be done after the network had been started, but If I recall correctly (it's been a while) that didn't work for me. However, it would be nice to find a different option that could be used that actually works.

                    You're probably referring to the _netdev option. And yeah, I've tried that. Doesn't work for me either.

                    If you do end up finding either a solution or discovering a way to improve my "workaround", do feel free to share your findings at your leisure.

                    And best of luck with it! ^^'

                      ermo You're probably referring to the _netdev option.

                      Yes, I was reminded of that when I started researching the matter again. One of the problems with trying to get a better understanding is the fact that just about every article I could find was so outdated. I was beginning to get enthusiastic about one, but then noticed it was from 2013. I'm pretty sure that predates the time my original approach stopped working, so I didn't think it was worth the trouble to set up that method and watch it fail again.

                      As I mentioned, getting my shares mounted automatically is in the category of "nice to have," as far as I'm concerned, but certainly not a necessity. Being retired, the few seconds that it takes me to issue a mount command are insignificant, since I'm setting up a terminal anyway. I guess I'm just curious enough (and stubborn enough) to want to make it work.

                      Since my curiosity hasn't yet been satisfied, I'll continue to look for the answer I'm seeking. And if I find something that works, I'll definitely let you know.