I second all that @Hooverdan said.
I just wanted to bring further details on the following:
Always a good idea to be careful and ask before moving forward if you’re unsure, absolutely… I wish I had that wisdom many times in the past
It all comes down to what we’re doing when you select Shares to use during a Rock-on install wizard. Indeed, what you do there is simply selecting a Share to be bound to a docker container in a certain way. For instance, in Plex’s case, if you are selecting the share named Plex-config (that you created in Rockstor) to be used for the “Config Storage” field in the Plex Rock-on install wizard, it simply tells the Docker container that it can use this Share as the folder with the path
/config as seen by the container. This folder still “belongs” to your Rockstor system, though, it is simply made available to the container. This means that when you uninstall the Rock-on and thus destroy the docker container, the “Plex-config” share will remain untouched and nothing will be deleted from there.
As Docker containers are designed to be ephemeral, binding shares/volumes like that is the only way to ensure you have persistent data when you destroy and rebuild the container.
This means that you can safely re-use the same Shares and settings (ports, etc…) when you re-install the same Rock-on and you should be back in the same state as you were before. Uninstalling a Rock-on and re-installing is using the same shares and settings as before is actually the recommended way to update a Rock-on (incidentally I am about to submit all this information to be added to our docs).
You are correct that re-using shares can be problematic in some cases, though: only when using the same share in multiple Rock-ons. Let’s continue with the Plex-config share example above, for instance. For Plex, this is where it will write to disk all the settings specific to Plex. Now, if you select this same Share as config storage for another Rock-on, you are risking the second Rock-on overwriting some of the files from the first one (and vice-versa). This is usually a very good recipe for creating conflicts so you should avoid it.
In general, I would recommend to always use distinct shares when installing Rock-ons, unless you know exactly how the Rock-on will use theses shares and you know you’ll be fine. Note, however, that you can add a share that is not initially pre-defined to some Rock-ons, in such case re-using the same is usually the intention. This is indeed commonly used to make some data available to multiple Rock-ons. You can have a look at the related section of our docs on that if you’re interested:
Hope this helps,