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

nick2k3 · Feb 24th 2020

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:

Code

openmediavault (5.3.3-1) unstable; urgency=low






  * Use /run instead of /var/run and /run/lock instead of /var/lock.


  * Disable the '/sharedfolder/<xyz>' feature by default on new


    installations because it makes too much problems.


    It can be enabled by setting the environment variable to


    'OMV_SHAREDFOLDERS_DIR_ENABLED="YES"'. Finally run the command


    'omv-salt stage run prepare' to apply the modified default values


    and 'omv-salt deploy run systemd' to create the unit files.


  * Issue #163: Apply hdparm.conf settings at runtime.


  * Issue #604: Wrong primary slave configuration for bond network


    interfaces.


  * Issue #605: Memory usage wrong in Dashboard and system information


    pages.






 -- Volker Theile <volker.theile@openmediavault.org>  Sun, 16 Feb 2020 13:54:00 +0100

Display More

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,

geaves · Feb 24th 2020

Quote from nick2k3

what is the proper way to bind-mount configurations in docker?

/srv/dev-disk-by-label-<name>/<share name> that's the absolute path.

ryecoaaron · Feb 24th 2020

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.

nick2k3 · Feb 24th 2020

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

ryecoaaron · Feb 24th 2020

Quote from nick2k3

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.

Quote from nick2k3

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

nick2k3 · Feb 24th 2020

Quote from ryecoaaron

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

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.

ryecoaaron · Feb 24th 2020

Quote from nick2k3

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.

Quote from nick2k3

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

nick2k3 · Feb 24th 2020

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?

ryecoaaron · Feb 25th 2020

Quote from nick2k3

Is there anything I can try to diagnose?

Nope. Enabling sharedfolders is slow on slow systems. Nothing you can do about this other than use symlinks.

macom · Feb 25th 2020

Quote from nick2k3

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.

nick2k3 · Feb 25th 2020

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?

macom · Feb 25th 2020

On my HC2 it is much faster.

If you set NO is the entry in /sharedfolders/ still created?

nick2k3 · Feb 25th 2020

Quote from macom

On my HC2 it is much faster.

If you set NO is the entry in /sharedfolders/ still created?

No, after the re-installation is no longer created.

I'll try to swithch the Pi3 with the Pi4 and see if it changes anything..

malibu · Feb 27th 2020

Quote from macom

On my HC2 it is much faster.

If you set NO is the entry in /sharedfolders/ still created?

I have that behavior too. /shared folders/ still created even though it is set to no.

I’m not quite sure how to fix it.

draddy · Feb 27th 2020

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.

malibu · Feb 27th 2020

You're right, a new share doesn't get into /sharedfolders/.

So my question is: how can I do the cleanup part?

Thanks!

ryecoaaron · Feb 27th 2020

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.

malibu · Feb 27th 2020

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.

ryecoaaron · Feb 27th 2020

Quote from malibu

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.

Quote from malibu

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.

draddy · Feb 27th 2020

may that helps:

what we see?
1st line check size of /sharedfolders --> 2nd line 60K
3rd line check content of a sharedfolder --> nothing just empty folder
4th line and follows - same folder as symlink.

all right?

Participate now!