MergerFS folders not mounted in /sharedfolders

  • I solved all my issues with mounting MergerFS shares at startup by commenting out the AssertPathIsDirectory directive that referenced the MergerFS folder being shared. For example:

    My only guess as to why this works is that Systemd is trying to check if this location is present (and a directory) before fuse can fully mount the MergerFS union. Commenting out the line doesn't appear to be hurting anything, and maybe a recent update made having that specific directive detrimental?

  • I was helping someone else w/ this issue last week. I'm assuming this is some sort of bug w/ mergers.. When you create a share on the merged filesystem.... the share will initially show up in the /sharedfolders folder, like every other share created in the webUI. After a restart, the shared folder disappears, but will still be in the shared folders section of OMV. Where this confused the person I was helping, was Plex. He had moved 2-3 small files into /sharedfolders/Movies.. scanned everything, and it was fine. Moved the rest of his data over and after a reboot.. Plex no longer saw his files because /sharedfolders/Movies did not exist any longer. Since the OMV smb.conf maps directly to the /srv folder he could still see them over SMB/CIFS.. which furthered his confusion.


    Eventually, we just mapped Plex directly to his data under the /srv directory and that solved the problem.

    Hi,
    I am having the exact same problem and it drives me nuts!
    See here
    No files shown in shared folders - but in SMB?
    and
    here
    Permission of folders inside sahredfolders change after reboot...


    I know how to point plex and others to the absolute path. But if I want to use this trick
    USB Backup Plugin: Backing up multiple shares with one Job
    for my backup I need the /sharedfolders directory - right?


    So it would be nice to solve. What is the final solution which survives an update and which is permanent even for new added shares?


    Thanks.
    Fabian

    MoBo: Fujitsu D3417-B
    CPU: Intel Celeron G3900
    RAM: Samsung DDR4 - 8 GB ECC
    Case: Fractal Design Node 80
    HDD: SSD 64GB (System), 2*3TB+1*4TB (Data) + 1*4TB (Parity). UnionFS + Snapraid
    OMV 4
    Router: Fritzbox 7590

    • Offizieller Beitrag

    I do not doubt the skills of Kribby but I have doubts about mine!

    There is one caveat in that fix and it's this # This configuration file is auto-generated. Which implies that if there is an update then that file will be overwritten and you will need to do it again.


    Edit: Look at post 10 I'm sure he's a developer for Emby and post 20 by @gron who has made some modifications.

  • I can confirm that the solution from MergerFS folders not mounted in /sharedfolders works on latest OMV 4.

    There is one caveat in that fix and it's this # This configuration file is auto-generated. Which implies that if there is an update then that file will be overwritten and you will need to do it again.

    Correct. I created a second shared folder and the change from the first shared folder was overwritten. Which means any time you use the Add or Edit button in the GUI (even for another shared folder) you'll have to redo the change(s). This does not happen when using the ACL button btw., so personally I can live with it.

  • There is one caveat in that fix and it's this # This configuration file is auto-generated. Which implies that if there is an update then that file will be overwritten and you will need to do it again.
    Edit: Look at post 10 I'm sure he's a developer for Emby and post 20 by @gron who has made some modifications.

    I read the solution post10 but I have a question ! :( sorry for that


    so I have to do one "Shell-Script: / usr / bin / wait-for-mergerfs" per sharefolder ?

  • I had this same problem. I did the steps in post 10 but first it didn't work. What is missing from those instructions is that you have to enable the mergerfs-wait-online.service after you have created it.


    Something like:

    Bash
    systemctl enable mergerfs-wait-online.service

    if i remember correctly. This might be obvious to a lot of you, but for me, having no knowledge of Systemd this was the missing link.


    @Revers62
    No, you don't have to make more than one "Shell-Script: / usr / bin / wait-for-mergerfs". I made only one, and it worked. I guess that when the script succeeds, it is safe to assume that all other folders can be mounted as well.


    I DO still have a problem with NFS. The service is running, but the /exports/"shared folder" folders are empty! stopping and starting the NFS service using the OMV gui doesn't result in mounted NFS folders.
    Only when I removed one of the four configured folders, and recreated it, were all the folders correctly mounted at /exports/"shared folder".


    What can I do to remedy this?

    • Offizieller Beitrag

    so I have to do one "Shell-Script: / usr / bin / wait-for-mergerfs" per sharefolder ?

    I would assume just one, but according to @gron he had to add his shares to the wait service, Post 21 is a solution but's it's an out generated config file which will get overwritten with an update. @Paradido solution is another option and taking that into an option might be to create all the shares prior to making a change.
    On the other hand @gderf solution is the most obvious one to use, 'raw data path' for program configs, the only problem I would have with that is brushing up on creating fstab entries.
    The issue here is the fact that shares are not mounted in /sharedfolders in a timely manner therefore the execution of a script or the modification of the config in post 21 is an effective workaround. The /sharedfolders also makes it easier for new users to locate those shares.
    I have been looking at moving away from my raid setup to use mergerfs and snappraid, for me this would mean reconfiguring my Dockers as well unless I adopt one of the workarounds, or use /srv/dev/etc with an fstab entry, the later being a permanent fix/solution.

  • I still do not really know what to do as a permanent fix. The information in this thread is not really straight forward...but maybe I just have to read it all again.


    Is this a known problem?
    Why do people recommend snapraid/unionFS in OMV...this is running into trouble especially with novice users...


    Except of this issue I am really impressed by this system. I am sure I will solve it ;)
    Hints still welcome.

    MoBo: Fujitsu D3417-B
    CPU: Intel Celeron G3900
    RAM: Samsung DDR4 - 8 GB ECC
    Case: Fractal Design Node 80
    HDD: SSD 64GB (System), 2*3TB+1*4TB (Data) + 1*4TB (Parity). UnionFS + Snapraid
    OMV 4
    Router: Fritzbox 7590

  • Why do people recommend snapraid/unionFS in OMV...this is running into trouble especially with novice users...



    Except of this issue I am really impressed by this system. I am sure I will solve it ;)
    Hints still welcome.

    I have no problems with any of this, but I also do not use the OMV UnionFS plugin. It is too coarse to fit my needs, only allowing entire drives to be joined.


    I configure my mergerfs settings in fstab by hand. It is not difficult to do this, and mergerfs is extremely well documented. Everything you need to know is here: https://github.com/trapexit/mergerfs

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • I still do not really know what to do as a permanent fix. The information in this thread is not really straight forward...but maybe I just have to read it all again.


    Is this a known problem?
    Why do people recommend snapraid/unionFS in OMV...this is running into trouble especially with novice users...


    Except of this issue I am really impressed by this system. I am sure I will solve it ;)
    Hints still welcome.

    Read post 10 + 27 = sucess


    I do not find your message very nice for developers who spend certainly much more time working on OMV than you have to fix a bug.

    • Offizieller Beitrag

    Why do people recommend snapraid/unionFS in OMV

    Because some of us have been using them for years without issues.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • I do not find your message very nice for developers who spend certainly much more time working on OMV than you have to fix a bug.

    I am really sorry for this. I totally did not want to disrespect all the work which went into the plugin or the whole OMV-Project. I am really enjoying it. And I have to say I am happy that I finally find the reason for my problem in this thread. I spend some hours to find a solution myself and tried to find some help in the forum...I just could not nail it down (was not thinking about) mergerFS/UnionFS.
    I will try to understand the solution in post 10 + 27.
    I hate to just type in some things without really knowing what to do...lets see.
    I have the impression that it is getting over my skill...I will report back.
    Thanks for all the input.
    Best.
    Fabian

    MoBo: Fujitsu D3417-B
    CPU: Intel Celeron G3900
    RAM: Samsung DDR4 - 8 GB ECC
    Case: Fractal Design Node 80
    HDD: SSD 64GB (System), 2*3TB+1*4TB (Data) + 1*4TB (Parity). UnionFS + Snapraid
    OMV 4
    Router: Fritzbox 7590

  • Ok, here we go.
    I start with post #10.
    The wait script should be like this

    Bash
    #!/bin/bash
    #/usr/bin/wait-for-mergerfs
    for i in {1..5}; do
      if [[ -e "/srv/e7f4be7f-ade2-4e06-a819-58883b226cc3/media" ]]; then
        exit 0
      fi
      sleep 1
    done


    As far as I know everything behind the # is a comment. So I do not care the mergerfs. I use unionFS. I am not sure how similar they are.
    So this one is clear. great!


    After this I go to the wait service

    Here I am totally lost...in general I have no idea what is happening here...just to point out a few:
    In line 3 it is mergerfs again...is this a problem for me? I use unionFS. Ore is it just the name/a variable?
    In line 5 zfs is mentioned. I do not use zfs as a filesystem.


    I stop here...
    I am just afraid to just do what is mentioned in post 10 without knowing what is happening.
    If you say it is safe to just try, I go for it. I have no idea what might happen to my system.
    So the only solution for me right now after a reboot is to add a new share and delete it afterwards again. Than all shares are active and can be accessed normally.
    Still looking for a simpler solution like this:
    Delay docker service start till specific HD is mounted
    Maybe there is something like "restart share"?
    Thank for all the help.
    Fabian

    MoBo: Fujitsu D3417-B
    CPU: Intel Celeron G3900
    RAM: Samsung DDR4 - 8 GB ECC
    Case: Fractal Design Node 80
    HDD: SSD 64GB (System), 2*3TB+1*4TB (Data) + 1*4TB (Parity). UnionFS + Snapraid
    OMV 4
    Router: Fritzbox 7590

  • @FFrank


    you have to adapt this line to your system


    if [[ -e "/srv/e7f4be7f-ade2-4e06-a819-58883b226cc3/media" ]]; then


    It's the line 4 in sheell-script.


    For that look in your folder /serv/


    you will find a serv/xxxxxxxxxxxxxxx/name_of_one_of_your_share


    that I get corrected if I say bullshit :)

  • The unionFS Plugin on OMV 4.x IS mergerfs.

    Ok, this id a good information!
    Thanks.
    Fabian

    MoBo: Fujitsu D3417-B
    CPU: Intel Celeron G3900
    RAM: Samsung DDR4 - 8 GB ECC
    Case: Fractal Design Node 80
    HDD: SSD 64GB (System), 2*3TB+1*4TB (Data) + 1*4TB (Parity). UnionFS + Snapraid
    OMV 4
    Router: Fritzbox 7590

  • Yes, I know this. But thanks for the info.
    Fabian

    MoBo: Fujitsu D3417-B
    CPU: Intel Celeron G3900
    RAM: Samsung DDR4 - 8 GB ECC
    Case: Fractal Design Node 80
    HDD: SSD 64GB (System), 2*3TB+1*4TB (Data) + 1*4TB (Parity). UnionFS + Snapraid
    OMV 4
    Router: Fritzbox 7590

  • Greetings, OMVers:


    I created the following script to re-mount all the inactive sharedfolder mounts in one go and just created an @boot scheduled job to run it. Working fine for me so far after each reboot. However it's still safer to have all processes to use the actual mounts located under /srv than the /sharedfoldes reference ones.



    Bash: remount-sharedfolders.sh
    #!/bin/bash
    
    
    for FOLDER in `systemctl list-units --state=inactive -t mount | grep sharedfolders | awk '{print $1}'`
    do systemctl restart $FOLDER
    done


    Hope this helps!


    P.S. Just want to point out that this solution will work for people who's been setting up multiple mergerfs sharedfolders (like me) and you don't need to mess with multiple auto-generated systemd service/mount files. However the re-mounting does come slightly delayed during the boot process, compared to solutions suggested before.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!