mergerfs policy change destroys OMV installation

  • Hi all,


    I am trying to set up a NAS with OMV, using LUKS encryption, SnapRAID and mergerfs (as described in this tutorial: https://michaelxander.com/diy-nas/)

    In the first run, everything worked fine, and initially I chose "epmfs" as policy for mergerfs. I could connect to the pool via SMB and copy files.

    After copying some files I noticed that "epmfs" was the wrong policy and "mfs" would be better for my use case.

    So I changed the policy to "mfs", but after a reboot (with an error message in the WebGUI during reboot) I can't log in, neither via WebGUI, nor via SSH, nor via direct access. Pinging the system is possible.

    Removing the HBA controller (which is necessary to plug in a graphics card for direct access, ITX mainboard) didn't solve the problem, either.


    So I reinstalled OMV from scratch, and installed all plugins one after another, rebooting after each step. Everything works, until the moment I create a mergerfs pool with the "mfs" policy. When I try to reboot after that, I can't log in, again.


    All software is up to date.


    Best regards,


    Bastian


    Edit: Alternatively, how can I rescue this install to continue without mergerfs or with mergerfsfolders?

  • KM0201

    Hat das Thema freigeschaltet.
  • KM0201

    Hat das Thema freigeschaltet.
    • Offizieller Beitrag

    I’m not going to be able to help you but maybe I can help get the ball rolling. I don’t know anything about the LUKS plugin, having never used it. I do recall seeing posts on the forum recently similar to the effect that LUKS and mergers do not work well together. Maybe someone from one of those posts will chime in, or Google will turn up something for you.


    I noticed that the tutorial you linked to involves OMV4. If you are just getting set up with OMV you would be better served by installing version 5 as v.4 has been EOL a good while.


    Also, what kind of hardware are you using?

    System Backup Typo alert: Under the Linux section the command should be sudo umount /dev/sda1 NOT sudo unmount /dev/sda1

    Backup Data Disk to Backup Disk on Same Machine: In a Scheduled Job:rsync -av --delete /srv/dev-disk-by-uuid-f8814ed9-9a5c-4e1c-8830-426968c20ea3/ /srv/dev-disk-by-uuid-e67439d5-00a3-4942-bd5f-b84ab86aa850/ Don't forget trailing slashes, and BE CAREFUL. (HT: Getting Started with OMV5)

    Equipment - Thinkserver TS140, NanoPi M4 (v.1), Odroid XU4 (Using DietPi): PiHole

  • It seems to be an error when using LUKS and mergerfs, you can't use both at the same time, as some of you already mentioned.


    Wouldn't it be better to include a warning in OMV-extras that you can't use both at the same time? Then other users would be less likely to run into this problem...

    • Offizieller Beitrag

    Wouldn't it be better to include a warning in OMV-extras that you can't use both at the same time? Then other users would be less likely to run into this problem...

    This is under consideration (maybe in plugin documentation) because it is becoming apparent that LUKS does not work well with the UnionFS plugin. On the other hand, it's difficult to forecast exactly what users may do, in combination, because the scenarios are near endless.

    For your install:

    I can understand why a user might want to aggregate drives with Mergerfs. But, the question I would ask the typical user is, why use LUKS? LUKS is "physical" protection. Drive encryption has security uses in small businesses and corporations, and for personal use with laptops that may be forgotten and left in public places. But for home servers? In my opinion, that's a bit harder to justify. In the majority of scenarios, a home server would be compromised "over the wire" after LUKS is unlocked.

  • Well, my system has a Xeon E3-1230v2 with AES support, so I assumed I could use LUKS without losing (much) performance.

    Of course, as long as the system is unlocked it is similarly easy (or hard) to compromise as a system without LUKS, but I thought of it as a small extra layer of security for certain situations with the only cost being the time for unlocking the drives after a reboot, which should not happen too often when the system runs stable...


    But because I share your opinion, I decided to ditch LUKS in favor of UnionFS in my case.

    • Offizieller Beitrag

    But because I share your opinion, I decided to ditch LUKS in favor of UnionFS in my case.

    I think you'll be well served by that decision. The only thing LUKS does is prevent your data from being compromised after the physical "theft" of your hard drives. (That's another topic that should be covered in a doc.) LUKS has it's applications for businesses and corporations, where server data my be sensitive (personnel records, financial transactions, etc.), but a good argument for home use is much weaker.

    Generally speaking, if someone breaks into your house, they're not going to be interested in a cube box, without a monitor, that doesn't appear to be a typical PC.

    • Offizieller Beitrag

    See also last paragraph here

    RE: Suggestion: rename the "unionfs" plugin?


    I have been avoiding changing the unionfilesystems plugin because people have been having issues in combination with LUKS when they aren't using auto-unlock.

    I see what you mean. :thumbup:

Jetzt mitmachen!

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