MergerFS folders not mounted in /sharedfolders

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • 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:

      Source Code

      1. # This configuration file is auto-generated.
      2. [Unit]
      3. Description=Mount shared folder Storage to /sharedfolders/Storage
      4. DefaultDependencies=no
      5. After=zfs-mount.service
      6. Conflicts=umount.target
      7. RequiresMountsFor=/srv/a3b05b91-3788-4b5e-8620-91cb2101364e
      8. # AssertPathIsDirectory=/srv/a3b05b91-3788-4b5e-8620-91cb2101364e/storage
      9. AssertPathIsDirectory=/sharedfolders
      10. AssertPathIsMountPoint=/srv/a3b05b91-3788-4b5e-8620-91cb2101364e
      11. [Mount]
      12. What=/srv/a3b05b91-3788-4b5e-8620-91cb2101364e/storage
      13. Where=/sharedfolders/Storage
      14. Type=none
      15. Options=bind,nofail
      16. [Install]
      17. WantedBy=local-fs.target
      Display All
      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?
    • KM0201 wrote:

      gderf wrote:

      Copying data does not populate OMV's internal configuration. You have to actually recreate the shares in the OMV GUI. Did you do that?
      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 (Data) + 1*4TB (Parity). UnionFS + Snapraid
      OMV 4
    • Revers62 wrote:

      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.
      Raid is not a backup! Would you go skydiving without a parachute?

      The post was edited 1 time, last by geaves ().

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

      geaves wrote:

      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.
    • geaves wrote:

      Revers62 wrote:

      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 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:

      Shell-Script

      1. 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?
    • Revers62 wrote:

      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.
      Raid is not a backup! Would you go skydiving without a parachute?
    • 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 (Data) + 1*4TB (Parity). UnionFS + Snapraid
      OMV 4
    • FFrank wrote:

      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: github.com/trapexit/mergerfs
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • FFrank wrote:

      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.
    • FFrank wrote:

      Why do people recommend snapraid/unionFS in OMV
      Because some of us have been using them for years without issues.
      omv 4.1.22 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.15
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Revers62 wrote:

      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 (Data) + 1*4TB (Parity). UnionFS + Snapraid
      OMV 4
    • Ok, here we go.
      I start with post #10.
      The wait script should be like this

      Shell-Script

      1. #!/bin/bash
      2. #/usr/bin/wait-for-mergerfs
      3. for i in {1..5}; do
      4. if [[ -e "/srv/e7f4be7f-ade2-4e06-a819-58883b226cc3/media" ]]; then
      5. exit 0
      6. fi
      7. sleep 1
      8. 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

      Source Code

      1. # /etc/systemd/system/mergerfs-wait-online.service
      2. [Unit]
      3. Description=mergerfs wait online
      4. DefaultDependencies=no
      5. After=zfs-mount.service
      6. Conflicts=umount.target
      7. Before=export-media.mount sharedfolders-media.mount
      8. [Service]
      9. Type=oneshot
      10. ExecStart=/usr/bin/wait-for-mergerfs
      11. RemainAfterExit=yes
      12. [Install]
      13. WantedBy=local-fs.target
      Display All
      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 (Data) + 1*4TB (Parity). UnionFS + Snapraid
      OMV 4
    • Revers62 wrote:

      @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 :)
      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 (Data) + 1*4TB (Parity). UnionFS + Snapraid
      OMV 4
    • 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.


      Shell-Script: remount-sharedfolders.sh

      1. #!/bin/bash
      2. for FOLDER in `systemctl list-units --state=inactive -t mount | grep sharedfolders | awk '{print $1}'`
      3. do systemctl restart $FOLDER
      4. 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.

      The post was edited 1 time, last by taichun ().

    • Users Online 1

      1 Guest