MergerFS folders not mounted in /sharedfolders

Hello,

i have the same problem. I have reinstalled omv. But the same issue.

Skaazi

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.

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.

Hello there,

I have the exact same problem (using OMV4, snapraid, mergerfs).
Has someone got a solution to it - or should I edit fstab ? or play with systemd services order ?

Thank you for your answer Trenchfoot. I think I'm going to dig a little bit on the systemd service order side; I will let you know if I have any success.

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

#!/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

Create the wait service

# /etc/systemd/system/mergerfs-wait-online.service
[Unit]
Description=mergerfs wait online
DefaultDependencies=no
After=zfs-mount.service
Conflicts=umount.target
Before=export-media.mount sharedfolders-media.mount


[Service]
Type=oneshot
ExecStart=/usr/bin/wait-for-mergerfs
RemainAfterExit=yes


[Install]
WantedBy=local-fs.target

Create override for the necessary mounts

systemctl edit sharedfolders-media.mount

Place the following in the file

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

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

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.

Quote from jamesjfa

I had rebuild my server and copied all my data back over.

Exactly what does this mean?

Quote from jamesjfa

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.

Quote from gderf

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.

Quote from KM0201

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

Copying data does not populate OMV's internal configuration. You have to actually recreate the shares in the OMV GUI. Did you do that?

Quote from gderf

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.

Quote from gderf

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).

Quote from KM0201

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

Quote from KM0201

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.

Quote from gderf

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.

@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.