MergerFS folders not mounted in /sharedfolders

  • If I run systemctl status fuse I get this



    Code
    systemctl status fuse
    ● fuse.service
    Loaded: masked (/dev/null; bad)
    Active: inactive (dead)

    If I run systemctl list-units --type service there is nothing listed for fuse which confirms the above.

  • please exactly where should the line be inserted? I have 5 shared folders in Sharedfolders, do I have to enter it in each sharedfolders-name.mount?

    Please try it out! It think this shouldn´t be the final solution, but a test whether the action is working or not.

    OMV 3.0.99 (Gray style)
    ASRock Rack C2550D4I C0-stepping - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304

  • The only way to mount the folders in /sharedfolders for me currently is to modify the
    /etc/systemd/system/sharedfolders-xxx.mount
    here is an example:


    from:


    Description=Mount shared folder MOD to /sharedfolders/MOD
    DefaultDependencies=no
    After=zfs-mount.service
    Conflicts=umount.target
    RequiresMountsFor=/srv/91080aad-6550-4341-9d5e-72bc444afebf/
    AssertPathIsDirectory=/srv/91080aad-6550-4341-9d5e-72bc444afebf/MOD/
    AssertPathIsDirectory=/sharedfolders
    AssertPathIsMountPoint=/srv/91080aad-6550-4341-9d5e-72bc444afebf/




    to


    Description=Mount shared folder MOD to /sharedfolders/MOD
    DefaultDependencies=no
    After=zfs-mount.service
    Conflicts=umount.target
    RequiresMountsFor=/srv/91080aad-6550-4341-9d5e-72bc444afebf/
    #AssertPathIsDirectory=/srv/91080aad-6550-4341-9d5e-72bc444afebf/MOD/
    AssertPathIsDirectory=/sharedfolders
    AssertPathIsMountPoint=/srv/91080aad-6550-4341-9d5e-72bc444afebf/



    I don't know if it's the right way but up until now it's the only one I found working.


    This is for OMV5

  • I experienced this issue after creating a union filesystem today. In my instance, it was mounting the fuse point before the underlying disks were mounted. It immediately after attempted to mount the sharedfolders, which failed because no data was there yet. Only sometime after the sharedfolders failed did it mount the disks.


    I was able to solve this by adding x-systemd.requires to the options for the union filesystem from the plugin window. So for my union of two disks the options are
    defaults,allow_other,use_ino,category.search=newest,x-systemd.requires=/srv/dev-disk-by-label-backup,x-systemd.requires=/srv/dev-disk-by-label-backup2
    Now they seem to be loading fine.

  • I experienced this issue after creating a union filesystem today. In my instance, it was mounting the fuse point before the underlying disks were mounted. It immediately after attempted to mount the sharedfolders, which failed because no data was there yet. Only sometime after the sharedfolders failed did it mount the disks.


    I was able to solve this by adding x-systemd.requires to the options for the union filesystem from the plugin window. So for my union of two disks the options are
    defaults,allow_other,use_ino,category.search=newest,x-systemd.requires=/srv/dev-disk-by-label-backup,x-systemd.requires=/srv/dev-disk-by-label-backup2
    Now they seem to be loading fine.

    @ryecoaaron maybe something that should be done automatically by the plugin.

  • maybe something that should be done automatically by the plugin

    I thought systemd was supposed to resolve the dependencies of a mount when they are in fstab? The mergerfs mounts are always after the individual disks and I don't have this problem on any of my systems. I guess I could add the requires options but it would be nice not to.

    which failed because no data was there yet.

    Are these disks usb disks?

    omv 5.5.12 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • TBH, I have just ignored this problem, my /sharedfolders/ do eventually populate but I never reference them anywhere, even the latest @TechnoDadLife videos use /srv/ in Portainer :thumbup:


    The solution is here not to use the default direct_io in options as this causes problems with docker and docker configs, I can't find the thread but another user highlighted this as it has something to do with mmap,

  • Are these disks usb disks?


    Nope, they're internal sata drives. They even appear above the union mount in fstab like you'd expect. However when I looked at the journalctl it was doing the union, then immediately after the sharedfolders which referenced the union fs, then sometime later the underlying disks. I can post the fstab or something else if it helps figure out why it was doing that.


    TBH, I have just ignored this problem, my /sharedfolders/ do eventually populate but I never reference them anywhere, even the latest @TechnoDadLife videos use /srv/ in Portainer :thumbup:


    The solution is here not to use the default direct_io in options as this causes problems with docker and docker configs, I can't find the thread but another user highlighted this as it has something to do with mmap,


    I much prefer the idea of referencing the /sharedfolders/ instead of the directly using the devices. It makes it easier to update things if anything changes. Like moving from bare drive to unionfs, just update the sharedfolders. It may be a holdover from being drilled into to use as little hardcoded values as possible. Though if it can't be made stable enough to rely upon then it's not the end of the world.


    I already removed the direct_io option since the docs looked like it was suggested against, at least in the general case.

  • They even appear above the union mount in fstab like you'd expect. However when I looked at the journalctl it was doing the union, then immediately after the sharedfolders which referenced the union fs, then sometime later the underlying disks. I can post the fstab or something else if it helps figure out why it was doing that.

    I think it is sad that we can't expect systemd to do things in order the disks are listed in fstab. I guess I can look at adding the x-systemd.requires lines.

    omv 5.5.12 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I found a couple pages (such as this one) which indicate that with systemd, fstab order is not maintained. They're all just turned into .mount files and run in parallel, barring dependencies.

    Yep and that is why I said it was sad.

    omv 5.5.12 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I am pretty sure fstab dependencies are resolved by systemd only when Fs are natives, mergerfs escapes from this.
    I use overlay for a very specific case and the mount occurs after the Fs under is ready in all of the cases.


    that’s also why many sf binds fail when using mergerfs and zfs.
    There is always the option to go back to legacy fstab ordering using kernel boot parameter fstab=yes

  • I just recently got this issue and it doesn't seem like these solutions work for me. I haven't tried the wait service though but one difference is also that one of my two folders does mount properly, and the other does not.


    I did both the x-systemd lines for my three disks (label-disk1, label-disk2, label-disk3), leaving out my parity drive. and I did the commenting out of the shared folder lines after that didn't work.


    Any ideas? Esp considering one folder, which is based on the same fs, mounts and not the other (even before I made these attempts to fix it)


    ignore. Not sure if I actually had this issue. Realized I used the wrong folder name (caps)

  • I experienced this issue after creating a union filesystem today. In my instance, it was mounting the fuse point before the underlying disks were mounted. It immediately after attempted to mount the sharedfolders, which failed because no data was there yet. Only sometime after the sharedfolders failed did it mount the disks.


    I was able to solve this by adding x-systemd.requires to the options for the union filesystem from the plugin window. So for my union of two disks the options are
    defaults,allow_other,use_ino,category.search=newest,x-systemd.requires=/srv/dev-disk-by-label-backup,x-systemd.requires=/srv/dev-disk-by-label-backup2
    Now they seem to be loading fine.

    I had the same problem and this solution works fine and is less intrusive than all the other ones. The only thing I now have to remember is to add this for each new disc of the union. I suggest putting a comment into /etc/fstab to remember this.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!