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.

    • 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'm not a fan of having a bunch of temporary workaround scripts and services lying around, so I looked into what I can do with the systemd unit in question

      You could also override the entire systemd mount unit so that auto-generation doesn't change anything in the grand scheme of things. Of course if OMV does change something, you'll need to edit the override manually.

      I'm still not sure which changes caused all of this in the first place
    • kribby wrote:

      I'm still not sure which changes caused all of this in the first place
      Well here's a curve ball, I've just moved to MergerFS and SnapRaid from Raid5, I backed everything up, then removed SMB shares, followed by the shared folders, then the Raid all in the GUI.
      Upgraded two drives, then set up MergerFs and SnapRaid from 2 new and 2 previously used drives, I set up the shares exactly as I had them on my Raid5 but under the fuse mount point, then restored the files from the backup.
      My /sharedfolders are populated with the folders I set up, why/how I don't know but I don't reference these folders In anything, I use /srv.

      But I agree temporary workarounds are what they are, temporary and will almost certainly be overwritten when there is an update.
      Raid is not a backup! Would you go skydiving without a parachute?
    • hurricanehrndz wrote:

      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




      Could you edit the last sourcecode so it says "Requires=mergerfs-wait-online.service" ? I can't test it right now but I'm 99 % sure this fix didn't work because I copied/pasted it over without looking too closely and it needs that "c" ;)
    • I made a crude "workaround" to this "bug" in the MergerFS implementation on my new setup of OMV ("migrated" from Amahi + Greyhole)

      The workaround is not so much of a workaround, I just disabled MergerFS - and pointed the shared folders to the individual folders on the individual disks
      - at it's current state MergerFS unusable for me, and I don't feel comfortable with the temporary solutions offered in this thread.

      For me it works for now, as the individual data is not scattered throuh the different disks yet, and there still is enough free space on all det individual disks. (Had to do a cleanup of the Greyhole JBOD system before I migrated to OMV - so I'm glad this happened now, and not later.

      I'll gladly use MergerFS later on when a permanent sollution is made to OMV/MergerFS
    • SchOX wrote:

      I'll gladly use MergerFS later on when a permanent sollution is made to OMV/MergerFS
      I have used mergerfs for years on OMV 3.x and OMV 4.x without any problems.

      However, I do not use the OMV UnionFS plugin (which is just mergerfs). I configure mergerfs by hand in fstab. And I do not reference any OMV shared folders in the fstab configuration. I use the absolute fully qualified filesystem paths instead.
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • I will think about changing the unionfilesystems plugin (major change) but I still don't understand the need. mergerfs makes decisions based on disk space not folder space. I realize when you pool folders, it might satisfy some file location OCD :D
      omv 4.1.23 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!
    • I have directories on multiple disks merged with mergerfs as opposed to entire disks being merged. Mergerfs is still making where to write to location decisions based on available disk space.

      The reason I merge selected directories instead of entire disks is that there is a lot of content on the disks that I do not want to be seen in the pools.
      --
      Google is your friend and Bob's your uncle!

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

      I have directories on multiple disks merged with mergerfs as opposed to entire disks being merged. Mergerfs is still making where to write to location decisions based on available disk space.
      I understand how you set it up but if you pool entire disks and put files in /disk#/path/to/folder, megerfs will put files in /disk1/path/to/folder and /disk2/path/to/folder and disk3/path/to/folder. How is pooling just folders making this different? I guess if you wanted different root folder names or you didn't want some folders pooled to other drives but this is the OCD kicking in again :)

      And I know mergerfs still works because the disk free space is the same for one folder as it is for the disk.
      omv 4.1.23 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!
    • Pooling just the folders I want to see in a pool leaves out the stuff I don't want to see in a pool ie the rest of the content of the disks.

      Also, IIRC the plugin allows only one pool to be created, and I want several - finer grain control.
      --
      Google is your friend and Bob's your uncle!

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

      Also, IIRC the plugin allows only one pool to be created, and I want several - finer grain control.
      You can have lots of pools. You can just only use a disk once per pool. Changing the plugin to allow disks to be used more than once is easier than changing it to use folders.

      gderf wrote:

      Pooling just the folders I want to see in a pool leaves out the stuff I don't want to see in a pool ie the rest of the content of the disks.
      Ok. Now we are getting somewhere. Say you have the following folders:

      docs
      pics
      music

      Right now (just a guess), you make a pool for docs so that pics and music aren't in it. And a pool for music so that docs and pics aren't in it. Then you create a shared folder from the docs pool called docs and shared folder from the music pool called music.

      On my system, I create one pool of all disks with the same folder structure. Then I create shared folder on the pool for docs which doesn't have pics or music in it and a shared folder on the pool for music which doesn't have docs or pics in it.

      These two examples do the same thing. Are you doing something different?
      omv 4.1.23 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!
    • I am accomplishing basically the same thing. The difference is that instead of shared folders on the pool I have mountpoints that are the individual pools. For example in fstab and using globbing:

      # >>> [sftp-mergerfs]
      /srv/dev-disk-by-label-d*/multimedia-content-d*/movies /srv/dev-disk-by-label-d1/sftp/outgoing/movies fuse.mergerfs ............................
      /srv/dev-disk-by-label-d*/multimedia-content-d*/music /srv/dev-disk-by-label-d1/sftp/outgoing/music fuse.mergerfs ................................
      /srv/dev-disk-by-label-d*/multimedia-content-d*/tv-series /srv/dev-disk-by-label-d1/sftp/outgoing/tv-series fuse.mergerfs ........................
      # <<< [sftp-mergerfs]

      The above three lines are all I have added to fstab outside the [openmediavault] section. I have never edited these or added more of them in several years of use across OMV 3.x and OMV 4.x

      My disks are labeled d1, d2, d3, and so on. When I add a new disk I label it as the next higher dn. I then create the directory structure on it as shown above, with the asterisks being replaced by n.
      --
      Google is your friend and Bob's your uncle!

      OMV 4.x - ASRock Rack C2550D4I - 16GB ECC - Silverstone DS380
    • I think I saw this issue a year or two ago. I have x-systemd-required for each drive added in the mergers extra options. If I am not mistaken I’ve worked a little bit on redoing the mkconf script that generates mergerfs entries to generate those systemd entries, left the task unfinished as I never did pr or even committed I think I left on gist. @ryecoaaron is the mkconf script still php based ?
      New wiki
      chat support at #openmediavault@freenode IRC | Spanish & English | GMT+10
      telegram.me/openmediavault broadcast channel
      openmediavault discord server
    • gderf wrote:


      However, I do not use the OMV UnionFS plugin (which is just mergerfs). I configure mergerfs by hand in fstab. And I do not reference any OMV shared folders in the fstab configuration. I use the absolute fully qualified filesystem paths instead.
      I prefer to use as much of the functionality out of the box - as this is not my hobby - it's a tool :) - I understand why you do this - and you have a lot more experience and knowhow than me.
      If I wanted to use a "hacked" solution for JBOD - I would probably have gone for Greyhole, as I know that system better - and it has some features MergerFS does not have - but I choose OMV because of it's "point and click" plugin / container approach the less I know that the server is there - the better - It just has to do it's job :)

      I Started with FreeNAS back in the days, and have run Amahi for several years - and I hope OMV needs less attention to be kept up to date :)
    • omv 4.1.23 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!
    • This isn't as big a disaster as I thought now that I've used this for a bit since all the stuff on my bigdisk is not affected and all the dockers/plugins/cifs use the bigdisk directly so I'm going to give up on fixing this and just keep lurking until a surefire fix is in. I tried the stuff in 10 and I don't think it works for me because I'm not using zfs so waiting for zfs doesn't work (I could be wrong).
    • So I have a similar, yet different situation that I'm scratching my head for...

      unionFS with the shared folders created in OMV GUI. ALL shared folders in unionFS mount correctly. Only some subfolders are available.

      i.e.

      /sharedfolders/media only has "Music" and "Unsorted"

      when you browse to the UUID of the unionFS pool, /pool UUID/media has "Music", "Movies", "TV Shows", etc...

      the sharedfolders created in OMV GUI are Media, Users, etc...

      So it's only some of the subfolders of the shares that aren't showing up.

      Show up fine in samba, or in the terminal and I go to the UUID for the unionFS pool.


      Any ideas?
      Is this old airplane safe to fly? How in the world do you think it got to be this old?
    • taichun wrote:

      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.
      Have the same problem and for now this workaround seems to work.
    • valent0ne wrote:

      taichun wrote:

      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.
      Have the same problem and for now this workaround seems to work.

      I ended up using the same script, and saved it in /bin - then I set up a scheduled job to run the script at every reboot. I also point at the mergerfs mount point in /srv vice /sharedfolders and no problems now.
      Is this old airplane safe to fly? How in the world do you think it got to be this old?
    • Users Online 1

      1 Guest