Sharedfolders

  • macom I intentionally want to stay on this thread for less confusion, so others can get a concise explanation for this change. gderf are the "problems" you were referring to discussed in this thread?

    If I understand correctly, this change means that a shared folder is created, but it's just under /srv/storage-drive-ugly-name/<sharedfoldername> now as opposed to under /sharedfolders/?


    Moving forward, how should we be handling shared folders as best practice? TechnoDadLife are you able to chime in on this?

  • macom I intentionally want to stay on this thread for less confusion, so others can get a concise explanation for this change. gderf are the "problems" you were referring to discussed in this thread?

    If I understand correctly, this change means that a shared folder is created, but it's just under /srv/storage-drive-ugly-name/<sharedfoldername> now as opposed to under /sharedfolders/?


    Moving forward, how should we be handling shared folders as best practice? TechnoDadLife are you able to chime in on this?

    There are far too many threads that deal with problems associated with Shared Folders.


    You still don't understand what's happening here and apparently how Shared Folders worked in the past.


    The past behavior was that when you created a Shared Folder you gave it an arbitrary name of your choice and you specified an existing folder that is located on one of your data drives to associate with the share. If that folder didn't already exist on the data drive, then it was created for you on the data drive. Once this was done the share name became available in drop down lists for selection in other areas of OMV. ABSOLUTELY NOTHING ABOUT THIS HAS CHANGED <-- Read this again. Additionally a new folder having the share name you selected was created under /sharedfolders/ on the rootfs and was bind mounted into the filesystem. This is where the problems began to surface because these folders were being used in ways not initially envisioned.


    What is different now is that a new folder having the name you selected for the share is no longer created under /sharedfolders/ on the rootfs. That is all that is different going forward. If you still want this behavior to continue, then the feature can be enabled via an environment variable described elsewhere. However, you need to be aware of what constitutes inappropriate use of these folders under /sharedfolders/ and that you are on your own if you misuse them, knowingly or otherwise. Certain uses of these folders are not supported regardless of users continuing to enable creating them under /sharedfolders/.


    I can not offer any more clarification about this.



    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 5.x on ASRock Rack C2550D4I C0 Stepping - 16GB ECC - Silverstone DS380 + Silverstone DS380 DAS Box.

    Edited 3 times, last by gderf ().

  • ryecoaaron I have been used to using /sharedfolders mount paths for so long (per the direction of folks on the forum) that I've come to believe something "bad" will happen if I use the real mount paths. Is there anything to be concerned with if I switch mappings from the now disabled /sharedfolders to the true paths?

    For example, all of my dockers now no longer function because the path they were referencing (/sharedfolders) is now empty. The true mount paths are available so it's only a matter of updating the docker configs - but I wanted to double check because, again, I have had it ingrained in me to use /sharedfolders.

    Thanks

  • Nothing bad will happen. The sharedfolders are just a bind mount to the absolute path. You are just cutting out the middle man.

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