MergerFS folders not mounted in /sharedfolders

    • OMV 4.x
    • MergerFS folders not mounted in /sharedfolders

      Hi everyone,

      After a reboot OMV4 fails to mount the directories from my mergerfs pool into the /sharedfolders directory. The directories from my regular, non-pooled disk mount there fine. If I create a shared folder from the web UI after boot everything gets mounted as it should. My theory is that it's because FUSE is mounted after the sharedfolders-[].mount scripts run, but I'm pretty new to all this. Here are what I think are relevant log snippets, in chronological order. These are during startup:

      This is the MergerFS pool being mounted:

      Source Code

      1. Nov 29 00:17:30 nounvault systemd[1]: Mounted /srv/8a57fc99-ce30-48a4-9ed2-7588e0c9d9f6.
      This is a folder from that pool failing to mount slightly later:

      Source Code

      1. Nov 29 00:17:30 nounvault systemd[1]: sharedfolders-Media.mount: Starting requested but asserts failed.
      2. Nov 29 00:17:30 nounvault systemd[1]: Assertion failed for Mount shared folder Media to /sharedfolders/Media.

      Here is FUSE mounting a bit later still:

      Source Code

      1. Nov 29 00:17:30 nounvault systemd[1]: Mounting FUSE Control File System...
      2. Nov 29 00:17:30 nounvault systemd[1]: Mounted FUSE Control File System.

      I've searched the forum a lot but I haven't found a fix. Thanks for any help!

      I'm using the latest OMV4 on an ASUS P55 motherboard.

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

    • In a couple systems I saw, if the directory is removed (ie /sharedfolders/Media), the systemd mount will fail. Adding the directory back should fix the problem.
      omv 5.1.2 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.1.9
      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!
    • I should mention there are 4 shared folders from the pool and they all fail to mount. How would I test to see if i.e. /sharedfolders/Media is missing? Should I unmount the mergerfs pool (in this case called 'Primary') and check to see that /sharedfolders has all the same directories in it?

      Edit: There are 4 directories in /sharedfolders corresponding to the 4 shared folders from the pool right after restarting the system, and they are empty.

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

    • I use mergerfs but not with the OMV plugin, it's too coarse for my needs. I do the mounts myself in /etc/fstab OUTSIDE the # >>> [openmediavault] # <<< [openmediavault] section.
      --
      Google is your friend and Bob's your uncle!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I - 16GB CC - Silverstone DS380
    • I spent quite a while on systemd - and I finished by modifying fstab because the same "after=" clause put in the systemd ".mount" files generated automaticaly by openmediavault has no effect, and on the contrary, works when put in fstab, like that :
      /srv/UnionFSfolder/ShareName /sharedfolders/ShareName none x-systemd.after=srv-dev\x2ddisk\x2dby\x2dlabel\x2dsde\x2dZAD66MV5.mount,bind,nofail 0 0

      "x-systemd.after=" tells "/lib/systemd/system-generators/systemd-fstab-generator", which translates fstab to systemd ".mount" files at boot time, to mount after "x2dZAD66MV5.mount", which is the last disk of my array, has been mounted, so I am sure the UnionFS is set.

      You can find the target ".mount" file name ("srv-dev\x2ddisk\x2dby\x2dlabel\x2dsde\x2dZAD66MV5.mount" in my example - set it to your disk) in "/run/systemd/generator".

      Of course, I renamed the "sharedfolders-*.mount" files in "/etc/systemd/system" so that they are not taken into account at boot time.
    • I encountered this issue as well. Another way to solve it with systemd would be to make a wait service.

      First make the wait script

      Shell-Script: /usr/bin/wait-for-mergerfs

      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



      Create the wait service

      Shell-Script: /etc/systemd/system/mergerfs-wait-online.service

      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

      Create override for the necessary mounts

      Shell-Script

      1. systemctl edit sharedfolders-media.mount

      Place the following in the file

      Source Code

      1. [Unit]
      2. Requires=mergerfs-wait-online.servie
      3. After=mergerfs-wait-online.service

      This solution has the benefit of not needing to edit fstab or openmedia config

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

    • jamesjfa wrote:

      I too have the same issue. I had rebuild my server and copied all my data back over. After a reboot, /sharedfolders/folder shows no files.

      Only difference between yesterday and today is that my drives are now EXT4 instead of BTRFS.

      Instead of looking under /sharedfolders for your files... look under /srv. You should see your UUID's for your disk, and you should see one created for your merged system... This is where your data is.. it's not gone.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • gderf wrote:

      jamesjfa wrote:

      I had rebuild my server and copied all my data back over.
      Exactly what does this mean?
      I was changing to larger drives so decided to rebuild another OMV system. Once complete I copied my data to the new system.


      KM0201 wrote:

      jamesjfa wrote:

      I too have the same issue. I had rebuild my server and copied all my data back over. After a reboot, /sharedfolders/folder shows no files.

      Only difference between yesterday and today is that my drives are now EXT4 instead of BTRFS.
      Instead of looking under /sharedfolders for your files... look under /srv. You should see your UUID's for your disk, and you should see one created for your merged system... This is where your data is.. it's not gone.

      Yes I have already mapped (where I had mappings to /sharedfolders) to /srv

      It's just that the files under /sharedfolders before. Just not sure what has changed.

      Cheers,
      James
      OMV 4.x running under ESX with SAS drives passed through
    • Copying data does not populate OMV's internal configuration. You have to actually recreate the shares in the OMV GUI. Did you do that?
      --
      Google is your friend and Bob's your uncle!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I - 16GB CC - Silverstone DS380
    • 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.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • 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?
      Sorry yes I should have been clearer. The data is all good. No issues there at all. I used rysnc to copy between servers etc (after creating the shares).


      KM0201 wrote:

      Eventually, we just mapped Plex directly to his data under the /srv directory and that solved the problem.
      Exactly what I have done now. I did have it mapped to /sharedfolders on the previous build without any issues.

      Cheers,
      James
      OMV 4.x running under ESX with SAS drives passed through
    • KM0201 wrote:

      Eventually, we just mapped Plex directly to his data under the /srv directory and that solved the problem.
      This is why I never use sharedfolders as the directory targets in program configurations. I always use the actual raw filesystem paths.
      --
      Google is your friend and Bob's your uncle!

      RAID - Its ability to disappoint is inversely proportional to the user's understanding of it.

      ASRock Rack C2550D4I - 16GB CC - Silverstone DS380
    • gderf wrote:

      KM0201 wrote:

      Eventually, we just mapped Plex directly to his data under the /srv directory and that solved the problem.
      This is why I never use sharedfolders as the directory targets in program configurations. I always use the actual raw filesystem paths.
      and I understand that and don't disagree.. but 90% of the tutorials (that I've seen) out there tell people to point at /sharedfolders... so it's an issue or new users.
      Air Conditioners are a lot like PC's... They work great until you open Windows.

    • @hurricanehrndz, I just tried your solution.
      It works for me now! but I did not see at once that I had to add my sharedfolders mounts behind the "Before=" (and I will have to do so each time I'll add a share in OMV...). I also changed "for i in {1..5};" to "for i in {1..300};", just in case. I don't care if my boot is slow.

      FYI I have another service based bon the same principle that do uncrypt my disks, retrieving the key with a ftp from another machine on the LAN, and that was this service that was causing late mergerfs mounting...

      Thank you!

      I have two remarks for whoever reads this:
      - I have Docker and Virtualbox installed - and they start before the sharefolders are mounted. to delay their start as much as possible, I added them to the before= list of the mergerfs wait service...
      - Also, I saw that nfs.service starts very early, just after network.target local-fs.target. What happens if the share is on snapraid? - btw I didn't check for CIFS.