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 !

    • Offizieller Beitrag

    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 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | 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!

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

    • Offizieller Beitrag

    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 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | 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 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"). :thumbup:

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

  • Evening folks,


    wonder if you can help me, i have the same issue as OP except after removing noexec from /etc/openmediavault/config.xml and running omv-salt deploy run fstab my raid array no longer mounts. when trying to mount witht he WebUI i get the following error:


    Code
    {"response":null,"error":{"code":0,"message":"Failed to execute command 'export PATH=\/bin:\/sbin:\/usr\/bin:\/usr\/sbin:\/usr\/local\/bin:\/usr\/local\/sbin; export LANG=C.UTF-8; mount -v --source '\/dev\/disk\/by-label\/Media' 2>&1' with exit code '32': mount: \/srv\/dev-disk-by-label-Media: wrong fs type, bad option, bad superblock on \/dev\/md127, missing codepage or helper program, or other error.","trace":"OMV\\ExecException: Failed to execute command 'export PATH=\/bin:\/sbin:\/usr\/bin:\/usr\/sbin:\/usr\/local\/bin:\/usr\/local\/sbin; export LANG=C.UTF-8; mount -v --source '\/dev\/disk\/by-label\/Media' 2>&1' with exit code '32': mount: \/srv\/dev-disk-by-label-Media: wrong fs type, bad option, bad superblock on \/dev\/md127, missing codepage or helper program, or other error. in \/usr\/share\/php\/openmediavault\/system\/process.inc:182\nStack trace:\n#0 \/usr\/share\/php\/openmediavault\/system\/filesystem\/filesystem.inc(738): OMV\\System\\Process->execute()\n#1 \/usr\/share\/openmediavault\/engined\/rpc\/filesystemmgmt.inc(927): OMV\\System\\Filesystem\\Filesystem->mount()\n#2 [internal function]: Engined\\Rpc\\OMVRpcServiceFileSystemMgmt->mount(Array, Array)\n#3 \/usr\/share\/php\/openmediavault\/rpc\/serviceabstract.inc(123): call_user_func_array(Array, Array)\n#4 \/usr\/share\/php\/openmediavault\/rpc\/rpc.inc(86): OMV\\Rpc\\ServiceAbstract->callMethod('mount', Array, Array)\n#5 \/usr\/sbin\/omv-engined(537): OMV\\Rpc\\Rpc::call('FileSystemMgmt', 'mount', Array, Array, 1)\n#6 {main}"}}

    The outpuyt of the omv-salt command is as follows:



    I even tried adding noexec back in to /etc/openmediavault/config.xml and ran the omv-salt command again and still no luck (just the errors above)


    I have ran the following


    Code
    mdadm --examine /dev/md127

    which gave me the output

    Code
    root@nas:~# mdadm --examine /dev/md127
    mdadm: No md superblock detected on /dev/md127.

    Please help :(


    Thanks

Jetzt mitmachen!

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