with omv-mkconf missing, OMV_FSTAB_MNTOPS_EXT4 variable deprecated... how can one modify fstab the "clean" way?

    • OMV 5.x (beta)
    • with omv-mkconf missing, OMV_FSTAB_MNTOPS_EXT4 variable deprecated... how can one modify fstab the "clean" way?

      Hi masters, I hope you are doing well.

      I need to remove "noexec" from the EXT4 mounted drives in my system (you know, the usual docker issue).
      I could do it the "dirty way" by modifying fstab manually and re-mount , but I would like a persistent way to do so, and the WebUI does not go into those details yet, not even in OMV5. (would be a nice feature though.. hint hint)

      ANYWAY, i tried the following:
      - the Techno-DAD way ( he took it from openmediavault.readthedocs.io/en/latest/various/fs_env_vars.html ) , modifying the attributes in the openmediavaul config.xml file. Did not work because omv-mkconf no longer exists in OMV5, so cannot launch the necessary omv-mkconf fstab command (looked everywhere). FAIL
      - the gderf way (master moderator), by setting the environment variable OMV_FSTAB_MNTOPS_EXT4 in /etc/default/openmediavault. Basically a) set the variable b) restart the daemon c) unmount / remount the drives using the WebUI
      OMV_FSTAB_MNTOPS_EXT4="defaults,nofail,user_xattr,exec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0
      and then restarting the daemon ( i even rebooted actually). Nope: the variable is ignored which means is deprecated/no longer valid. UTTER FAIL

      So, the question is: with omv-mkconf gone, disappeared from the new release, and the mounting variables deprecated, how can one persistently "CLEAN" remove noexec from EXT4 mounts ?

      Thanks in advance !
    • Jormaster2k wrote:

      Did not work because omv-mkconf no longer exists in OMV5, so cannot launch the necessary omv-mkconf fstab command (looked everywhere)
      omv-mkconf is now omv-salt deploy run in most cases. So, it is omv-salt deploy run fstab. Setting the default should still work as well but you need to run the omv-salt command.
      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!
    • ryecoaaron wrote:

      Jormaster2k wrote:

      Did not work because omv-mkconf no longer exists in OMV5, so cannot launch the necessary omv-mkconf fstab command (looked everywhere)
      omv-mkconf is now omv-salt deploy run in most cases. So, it is omv-salt deploy run fstab. Setting the default should still work as well but you need to run the omv-salt command.
      Hi Aaron,

      It worked like a charm for the standard EXT4 filesystems: fstab was edited and all FS are without noexec. Thank you !!

      So that's resolved, BUT...

      Unfortunately I have to report two bugs, one potential and one immediate, in the hopes that you may direct this to who may be interested, in the appropriate dev areas... or forum bug area for OMV5.
      1) while launching the salt command, I got a 'DeprecationWarning' (see below the extract). It may need some python code remediation at some point: who/where should I report this to?
      2) the omv-salt command while fixing the fstab, did unfortunately also MESS with the unionFS mountpoint i have (created with the WebUI plugin, of course), forcing an unmount. I am not sure that this was a big issue thought, because I rebooted immediately to test if fstab was mounting right, and the reboot did in fact restore the unionFS mount itself in /srv/84b16c30-bb58-46d1-bff3-799961a6197b.


      Yet during that reboot I got all new error messages, and all smb shares associated to the unionFS filesystem were broken.
      The error was captured at reboot as [ASSERT] Assertion failed for Mount shared folder xxxxx to /Sharedfolders/xxxxx (where xxxxx are each of my shares): unionFS was mounted correctly but the shared folders were broken.
      To fix that I had to delete all the smb shares in the WebUI and re-make them.
      Again, its a bug, and I fixed my own personal issue, but this might be of interest for the devs.

      So, below is an extract of the omv-salt deploy run fstab command output: the first is the initial output with the deprecation warning, the a whole bunch of correct mounts for my FSs except the unionFS, then at the bottom is the log of the forced unmount.
      ---------- #Issue 1

      /usr/lib/python3/dist-packages/salt/modules/file.py:32: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
      from collections import Iterable, Mapping
      /usr/lib/python3/dist-packages/salt/utils/decorators/signature.py:31: DeprecationWarning: `formatargspec` is deprecated since Python 3.5. Use `signature` and the `Signature` object directly
      *salt.utils.args.get_function_argspec(original_function)


      ---------- #Issue 2 (also see attached picture of boot errors)
      ID: mount_no_bind_mountpoint_dc7a7b80-8828-47a3-a4c6-e2ebe6dccd31
      Function: mount.mounted
      Name: /srv/84b16c30-bb58-46d1-bff3-799961a6197b ##This is the generated name of my UnionFS filesystem made of 6 of 8 disks)
      Result: True
      Comment: Target was successfully mounted
      Started: 22:30:04.614104
      Duration: 162.709 ms
      Changes:
      ----------
      mount:
      True
      umount:
      Forced unmount because devices don't match. Wanted: 84b16c30-bb58-46d1-bff3-799961a6197b, current: 1of8:2of8:3of8:4of8:5of8:6of8, /etc/1of8:2of8:3of8:4of8:5of8:6of8

      Summary for debian
      -------------
      Succeeded: 21 (changed=1)
      Failed: 0
      Total states run: 21
      Total run time: 612.031 ms

      -------------


      I resolved by deleting the shared folders using the WebUI and re-making them again.
      Still, why would this happen?

      I hope this helps somehow.
      Thanks much again !!
      Images
      • problem.png

        298.09 kB, 971×379, viewed 13 times
    • surfbum wrote:

      Thank you I was just going to ask this question too. I did try to look at the documentation where did you find the mkconf to salt change??
      Changelog
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Jormaster2k wrote:

      1) while launching the salt command, I got a 'DeprecationWarning' (see below the extract). It may need some python code remediation at some point: who/where should I report this to?
      This is a Debian upstream issue which will hopefully be fixed soon.
      Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Jormaster2k wrote:

      the omv-salt command while fixing the fstab, did unfortunately also MESS with the unionFS mountpoint i have (created with the WebUI plugin, of course), forcing an unmount. I am not sure that this was a big issue thought, because I rebooted immediately to test if fstab was mounting right, and the reboot did in fact restore the unionFS mount itself in /srv/84b16c30-bb58-46d1-bff3-799961a6197b.
      This is going to be just about impossible to fix because it only happens when you change the mounting options of the pool's underlying filesystems and they need to be remounted.
      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!
    • ryecoaaron wrote:

      Jormaster2k wrote:

      the omv-salt command while fixing the fstab, did unfortunately also MESS with the unionFS mountpoint i have (created with the WebUI plugin, of course), forcing an unmount. I am not sure that this was a big issue thought, because I rebooted immediately to test if fstab was mounting right, and the reboot did in fact restore the unionFS mount itself in /srv/84b16c30-bb58-46d1-bff3-799961a6197b.
      This is going to be just about impossible to fix because it only happens when you change the mounting options of the pool's underlying filesystems and they need to be remounted.
      Actually I investigated a bit more and found the issue and a solution, which is actually a reuse !!!

      The issue is persistent: everytime omv-salt is used by me directly or by OMV gui to apply webUI changes and update stuff (e.g. adding/removing another share), the issue comes back: forced unmount of unionFS and at the reboot assertion error of all the shared folders that are related to the same unionFS mount (see picture above).
      I suspect that when omv-salt command runs, it re-organizes the order in which the OS mounts the file systems and the other shared folders using fstab and then systemd mounts.

      So, the issue is that everytime an OMV config reconfigure happens, the unionFS gets unmounted :!: , and at reboot OMV attempts to mount the systemd mounts (e.g. /etc/systemd/system/sharedfolders-media.mount) BEFORE the dependency from fstab - the related unionFS filesystem - is done being mounted :!: :!: .
      I am not sure if this happens because unionFS takes longer time to mount, of if its a bug or what, but it is repeatable and persistent. If I were to fix this issue the clean webUI way, I would have to redo all my shares each time this happens.

      Alas, hurricanehrndz to the rescue !! (See his post in this forum : "MergerFS folders not mounted in /sharedfolders"). :thumbsup:

      His elegant workaround solution was to create a wait service and then create a "systemd" service override for all the necessary shared folders mounts dependent from the unionFS filesystem, to wait for it to be mounted first.

      Voila' everything now works perfectly again! No need to destroy and rebuild my shares in WebUI EVERY single time omv-salt is launched to apply config changes: at the next reboot everything runs smoothly.

      I hope this is a bug that can be fixed in future updates: OMV should be made to adopt a wait method for unionFS based shared folders and/or establish dependency on it being mounted first.

      I hope this also helps others with a situation like mine.

      Thank you again for your help !!
    • Absolutely no support through PM!

      I must not fear.
      Fear is the mind-killer.
      Fear is the little-death that brings total obliteration.
      I will face my fear.
      I will permit it to pass over me and through me.
      And when it has gone past I will turn the inner eye to see its path.
      Where the fear has gone there will be nothing.
      Only I will remain.

      Litany against fear by Bene Gesserit
    • Users Online 2

      2 Guests