MergerFS folders not mounted in /sharedfolders

  • 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

    • Offizieller Beitrag

    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.

  • 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

  • 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 AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    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 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 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 AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

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

  • 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 AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    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.

    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 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 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 AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    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 ?


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

    • Offizieller Beitrag

    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!

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

  • Have the same problem and for now this workaround seems to work.

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

    • Offizieller Beitrag

    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?

    IMO it would make sense to investigate this issue a little bit more. Maybe the final solution should be to tell the systemd unit that it has to wait for FUSE to get mounted. Maybe adding a new 'After=fuse-xxx.service' line will solve it. Can someone test this, please?

Jetzt mitmachen!

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