OMV 5.3.3-1 disabling /sharedfolder/ feature - why?

  • Hi everyone,
    i am currently running a OMV5 installation on a Pi3 to test every aspect before upgrading my main Pi4-OMV4 fileserver.


    I just noticed an update in the latest OMV5 package:



    I am a bit confused on the second point of the changelog.
    What is the problem with the /sharedfolder/<xyx> feature?


    I currently use them a lot to generalize the path to my docker configuration directory.
    I have one /sharedfolder/docker_config/ directory with all the various config of the containers I am running.


    If /sharedfolder/ is disabled (or may be discontinued in the future altogether) what is the proper way to bind-mount configurations in docker?


    Thanks,

  • It is being disabled by default because it is a pain in the ass. If anything is using the bind mount (which is what /sharedfolders are), salt can't restart them causing the salt run to fail. If you use them, just the the OMV_SHAREDFOLDERS_DIR_ENABLED entry in /etc/default/openmediavault to no and follow the directions in the description here - https://github.com/openmediava…2847c2d24144c41d57ed4a5d8


    Otherwise, if you want to use something better, use the /srv/device_name_example/sharedfolder_name paths. It isn't much harder. You could even create a symlink using the symlink plugin if it is too hard.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Thank you! I suspected that.
    I have already discovered I can use the "/srv/dev-disk-by-label-" path before, however i preferred the sharedfolders because they would be disk independend and I could move them around if I needed to do some maintenance without having to reconfigure all the docker containers.


    Is the sharedfolder feature that causes salt to be so slow when applying changes?


    Right now its performance is the only thing that is keeping me to upgrade the "production" (lol sounds so fancy) OMV4 with OMV5.
    It takes an average of 2-3 minutes on a PI4 4gb RAM and a quite decent SD card just to add a shared folder..

  • Is the sharedfolder feature that causes salt to be so slow when applying changes?

    It seems to be a large part. I just added a folder on my RPi4 and it took 1m45. After disabling sharedfolders, adding another one took 15 secs.


    Right now its performance is the only thing that is keeping me to upgrade the "production" (lol sounds so fancy) OMV4 with OMV5.
    It takes an average of 2-3 minutes on a PI4 4gb RAM and a quite decent SD card just to add a shared folder..

    "Production" on an RPi??

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • "Production" on an RPi??

    Haha I didn't know how best to indicate it, maybe the joke didn't get through. Basically i have one RPi-4 that uses OMV4 and is the main one where all my disks are connected and all my containers run. This would be the "production" :P


    Then I use the older RPi3 to test and experiment without having to worry to mess with my main OMV installation.


    On a side note, I upgraded to 5.3.3-1 but the updater script told me that my configuration file has been manually modified. It cannot be as this is a fresh install.


    I compared it with the one on github and traced the "issue" to the install script adding these three parameters near the end of the installation:



    Code
    # set defaults in /etc/default/openmediavault
    omv_set_default "OMV_CPUFREQUTILS_GOVERNOR" "${GOVERNOR}"
    omv_set_default "OMV_CPUFREQUTILS_MINSPEED" "${MIN_SPEED}"
    omv_set_default "OMV_CPUFREQUTILS_MAXSPEED" "${MAX_SPEED}"

    This would cause the updater not to add the OMV_SHAREDFOLDERS_DIR_ENABLED="NO" setting to the configuration. Is this behavior intended?
    I guess if I re-do a fresh install I should automatically get that setting to NO.

  • Is this behavior intended?

    Yes. That is why the omv_set_default function exists. Lots of plugins including core OMV plugins change values in the defaults. That is why Debian asks if you want to change it.

    I guess if I re-do a fresh install I should automatically get that setting to NO.

    Yes but why would you re-install? You can manually add the OMV_SHAREDFOLDERS_DIR_ENABLED="NO" entry to /etc/default/openmediavault and run omv-salt stage run prepare followed by omv-salt deploy run systemd

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Hi again,
    I tried to add the OMV_SHAREDFOLDERS_DIR_ENABLED="YES" setting into:
    /etc/default/openmediavault
    then run:
    omv-salt stage run prepare
    and
    omv-salt deploy run systemd
    as suggested inthe changelog.
    I then rebooted.


    Unfortunately every time I add a sharedfolder it takes more than 1:30 minutes and the /sharedfolder/<xyz> is still created.
    deleting a sharedfolder takes the same magnitude of time..
    Is there anything I can try to diagnose?

  • Unfortunately every time I add a sharedfolder it takes more than 1:30 minutes and the /sharedfolder/<xyz> is still created.

    Confusing.
    YES means the entry in /sharedfolders/ will be created
    NO would mean it is not being created.

  • Hi,
    Yesterday I tried several time to make my OMV5 accept the NO parameter for avoid creating the sharedfolder but without success.


    I re-installed OMV5 from scratch and now the setting was NO by default.


    However the time taken to execute the various apply-changes is not so much improved.
    RPi3 with latest raspbian lite, latest omv script run, one USB2 7200rpm drive attached and I got these result:
    - create shared folder : 1:40 sec
    - delete shared folder : 1:20 sec
    - add shared folder to SMB and enable smb : 1:50s
    - enable or disable monitoring : 1:33


    all of this in "rest" conditions, all docker containers shut off no transfer ongoing, ethernet cable connected..


    Is this normal?

  • are you sure new sharedflolders are created?


    i still have the entries in /sharedfolders that were added befor 5.3.3 but if i add a new share in web gui - that new share didn't appear in /sharedfolders/ - so what is "missing" is a cleanup - but new ones dosn't created if you set the config to no.

  • Having the /sharedfolders directory and possibly sub-directories in that directory doesn't hurt anything. The "cleanup" is completely optional.


    rmdir /sharedfolders/* /sharedfolders # rmdir is used to guarantee it doesn't delete any files.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I'm a little confused. I thought the whole point of removing the sharedfolders was to avoid issues and improve performance. Would the "cleanup" have no effect then?


    In any case, it feels odd to have the older shares still in /sharedfolders while new wouldn't.

  • I thought the whole point of removing the sharedfolders was to avoid issues and improve performance. Would the "cleanup" have no effect then?

    People are confusing just have a directory on the filesystem (not even a symlink) with bind mounts which is what this is actually disabling. The bind mounts are the problem because it is a systemd mount that can't restart when it is in use and takes a "long" time to restart when it isn't in use. So, no, cleaning the folders up will affect nothing.


    In any case, it feels odd to have the older shares still in /sharedfolders while new wouldn't.

    They are just directories with the same name as the shares. They were mount points but once sharedfolders is disabled, they are just directories. Nothing more. You can't reference old shares using them because they aren't symlinks or bind mounts. Not sure how to make this anymore clear.

    omv 5.5.2 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!