Default Docker Volume Mapping Preferences Coming in unRAID 6.2


jonp

Recommended Posts

Preface

 

Container Authors,

 

I’m writing to you all today to make you aware of the first of a few changes we will be making to Docker management in version 6.2.  Our primary focus with these changes is to simplify things for new users and reduce the amount of time and self-education required to get started using containers on unRAID. If you have questions or feedback regarding these changes, please post them as a reply in this thread.

 

Overview

 

Almost all container templates utilize at least one volume mapping for storing application data outside of the container itself. In the majority of the container templates that exist for unRAID, the container path used for this has been /config.  In unRAID 6.1.x and previous versions, container templates could provide a default host path that would be used for the /config container path. 

 

In unRAID 6.2, users will find a new setting available on the Docker Settings page which will allow them to specify a path to store application data by default.  If the user enters a value for this setting (such as /mnt/user/appdata), all containers the user adds to Docker that contain a /config container path will automatically have the corresponding host path set to the value specified in that field (appended with a sub-folder that matches the Container Name).  This will override any default value that a container template has for the host path of the /config volume mapping. If the user chooses to leave this setting blank, the template-provided host path will be used by default (or it will remain blank if no default host path is specified by the container template).

 

In addition to the default mapping preference for /config, we also will recommend a default volume mapping that all containers receive to simplify and unify how users get to their data from within container-hosted applications.  The value the user enters into this field will result in the automatic creation of a /unraid container path for all newly added containers that will map to this field. We have plans to set a default value on this field for users based on whether or not they have user shares enabled (if yes == /mnt/user; if no == /mnt).  This way, regardless of which container they are adding, users will consistently be able to go to the same path from within ANY container to access storage on unRAID.  If the user clears this setting (making it blank), then this setting will be ignored.

 

Lastly, if a user has a value specified for the default /config or /unraid mapping, when adding a new container to the system, the “basic” view mode will not display these mappings at all (they will be hidden from the user).  Advanced view will make them visible and allow the user to edit them manually.  All additional volume mappings specified within the container template (e.g. /tmp, /, /mnt/user/movies, etc.) will always be displayed, even if in basic view.

 

Note:  this will only affect new containers users add to their system after the release of 6.2. Containers added prior to 6.2 will maintain their existing volume mappings as specified.

 

Example

 

Container Name:  app123

Template /config host path definition:  /mnt/user/appdata/bobsapp

User preference /config host path definition:  /mnt/user/appconfig

User preference /unraid host path definition:  /mnt/user

 

On the Add Container page:

  • The volume mappings for /config and /unraid will be hidden under basic view.
  • Under advanced view, /config will have a host path mapping to /mnt/user/appdata/app123
  • Under advanced view, /unraid will have a host path mapping to /mnt/user

 

Update 1

 

In addition to trying to automap /config container paths to a default preference that the user specifies, we will also implement an attribute to template XML that allows an author to specify a container path as "appdata."  Here's an example with the TaskBoard container:

 

So this container really wants to use /var/www/TaskBoard to store it’s application data.  There is no /config container volume, but the equivalent is what /var/www/TaskBoard would be.  Here’s the relevant XML for the template where the author specifies the mapping you see there (I cheated and manually put in the <ContainerDir> element for this example):

 

  <Data>

    <Volume>

      <HostDir>/mnt/user/appdata/TaskBoard</HostDir>

      <ContainerDir>/var/www/TaskBoard</ContainerDir>

      <Mode>rw</Mode>

    </Volume>

  </Data>

 

With our new "type" attribute for the <Volume> tag, it could look like this:

 

  <Data>

    <Volume type=“appdata”>

      <HostDir>/mnt/user/appdata/TaskBoard</HostDir>

      <ContainerDir>/var/www/TaskBoard</ContainerDir>

      <Mode>rw</Mode>

    </Volume>

  </Data>

 

If the user didn’t have a preference entered under Docker Settings for their preferred appdata location, then the <HostDir> element would be used.  If the user did have a preference specified, the <HostDir> element would be replaced with that preference.

Link to comment

I think this scheme will help some, but we will still have to educate the users on the pros/cons of having appdata on cache, and how to make that happen. Maybe there could be an additional checkbox or something in Docker Settings to make appdata cache-only. With the recent changes to mover, this could also be accomplished by setting the default for the /config mapping to /mnt/cache/appdata. Don't know exactly what I think would be best way to implement, just putting it out there for consideration.

Link to comment

I think this scheme will help some, but we will still have to educate the users on the pros/cons of having appdata on cache, and how to make that happen.

 

So I didn't bring this up in the OP because it wasn't pertinent to the topic, but since you mention it, I might as well disclose our plans for that.

 

In short, we intend to auto-create shares for Docker when the service is initially enabled. Everything will depend on what the situation is when Docker is first enabled on the Settings page.

 

If user shares are not enabled (not the default but could happen):

  If no cache disk/pool:

    /config -> /mnt/disk1/appdata

    /unraid -> /mnt/

  if cache disk/pool exists:

    /config -> /mnt/cache/appdata

    /unraid -> /mnt/

 

In this case we create the appdata directory when Docker is first started.  If this case is detected, and the appdata directory does not exist, we could add some text to the page that says, "Lime Technology highly recommends using a cache disk/pool to store your appdata share."

 

If user shares are enabled:

  /config -> /mnt/user/appdata

  /unraid -> /mnt/user/

 

In this case we can change shfs so that if a mkdir occurs on /mnt/user and there is no /boot/config/shares/appdata.cfg file, it will try to create on /mnt/cache if it exists, else will pick one of the /mnt/disk shares according to 'high-water'.  Since the default 'use cache' is "No" the mover will not move an appdata share created like this.

 

Also, we are implementing another small "tweak" to the OP which I will edit here shortly.

In addition to trying to automap /config container paths to a default preference that the user specifies, we will also implement an attribute to template XML that allows an author to specify a container path as "appdata."  Here's an example with the TaskBoard container:

 

So this container really wants to use /var/www/TaskBoard to store it’s application data.  There is no /config container volume, but the equivalent is what /var/www/TaskBoard would be.  Here’s the relevant XML for the template where the author specifies the mapping you see there (I cheated and manually put in the <ContainerDir> element for this example):

 

  <Data>

    <Volume>

      <HostDir>/mnt/user/appdata/TaskBoard</HostDir>

      <ContainerDir>/var/www/TaskBoard</ContainerDir>

      <Mode>rw</Mode>

    </Volume>

  </Data>

 

With our new "type" attribute for the <Volume> tag, it could look like this:

 

  <Data>

    <Volume type=“appdata”>

      <HostDir>/mnt/user/appdata/TaskBoard</HostDir>

      <ContainerDir>/var/www/TaskBoard</ContainerDir>

      <Mode>rw</Mode>

    </Volume>

  </Data>

 

If the user didn’t have a preference entered under Docker Settings for their preferred appdata location, then the <HostDir> element would be used.  If the user did have a preference specified, the <HostDir> element would be replaced with that preference.

 

How do we plan to handle running the same container more than one time? As i read it now there will be a direct path clash with all version using the same app data?

 

What you are asking for is a new feature request that would benefit a relatively small number of users. If you feel strongly about it, please post that as a feature request, not here in a thread designed for community developers to discuss the changes we are making for 6.2.

Link to comment

This is not a feature request it is a logic problem with your planned implementation that could result in data loss.

 

Incorrect.  The issue that you want resolved exists the same today with 6.1.x and has existed since the first implementation of Docker.  If you want, you can file it under a defect report if you feel so strongly about this not being a feature.  Point is, this is not the appropriate thread to discuss it.

Link to comment
  • 3 months later...

Just looked at this because linuxserver obviously wants to be compliant with unraid regarding dockers, but have to say the notion of /unraid being mapped to /mnt or /mnt/user scares the hell out of me.

 

giving any container carte blanche access to the whole array like that is a recipe for disaster if someone who's not that experienced writes a container and unwittingly puts in a delete etc, or an app is a little promiscous with it's writing.

 

 

Link to comment

Just looked at this because linuxserver obviously wants to be compliant with unraid regarding dockers, but have to say the notion of /unraid being mapped to /mnt or /mnt/user scares the hell out of me.

 

giving any container carte blanche access to the whole array like that is a recipe for disaster if someone who's not that experienced writes a container and unwittingly puts in a delete etc, or an app is a little promiscous with it's writing.

While I do agree with you, can you come up with a better way?  ie: Can you explain volume mappings to your Grandmother and have her understand.

 

And, you could always set the default access mode to be read-only

 

 

Link to comment

Just looked at this because linuxserver obviously wants to be compliant with unraid regarding dockers, but have to say the notion of /unraid being mapped to /mnt or /mnt/user scares the hell out of me.

 

giving any container carte blanche access to the whole array like that is a recipe for disaster if someone who's not that experienced writes a container and unwittingly puts in a delete etc, or an app is a little promiscous with it's writing.

Can you explain volume mappings to your Grandmother and have her understand.

 

 

not without a seance

 

 

Link to comment

Since sparkly bumped this maybe someone could clear something up for me.

 

I have always specified /mnt/cache/appdata instead of /mnt/user/appdata simply because I don't think of appdata as being a normal user share and I want to make it more obvious.

 

But I have also read on the forum that /mnt/user does not work with hard links. Is this true and could this be an issue when specifying /mnt/user/appdata?

Link to comment

Just looked at this because linuxserver obviously wants to be compliant with unraid regarding dockers, but have to say the notion of /unraid being mapped to /mnt or /mnt/user scares the hell out of me.

 

giving any container carte blanche access to the whole array like that is a recipe for disaster if someone who's not that experienced writes a container and unwittingly puts in a delete etc, or an app is a little promiscous with it's writing.

Can you explain volume mappings to your Grandmother and have her understand.

 

 

not without a seance

Oops... didn't know  Although I guess that means the answer is "no"
Link to comment

and you don't take the brakes off the car because three pedals might confuse some drivers......

Here in the States it would confuse most drivers so we take the clutch away. You can get one if you really want one but it might be a special order for some models if it's even available.
Link to comment

The net result is that volume mapping is a PITA to explain.  Automatic mappings to /mnt or /mnt/user while I don't agree with is definitely the easiest way to handle the problem for users.

 

The threads are filled with WTF and why isn't this working, etc.  Sure there are downsides, but the upshot is that the support requests should drop significantly.  Additionally, nothing is saying that the knowledgeable user can't override it.

 

Find a better way.  I can't really think of one, and since LT really wants to make the whole system easy to use, this does fit the bill.

Link to comment

Anybody know the answer to this

...I have also read on the forum that /mnt/user does not work with hard links. Is this true and could this be an issue when specifying /mnt/user/appdata?

since /mnt/user/appdata was part of the proposal?

 

i've seen issues that have been resolved in containers by using /mnt/cache/appdata in place of /mnt/user/appdata

Link to comment

and you don't take the brakes off the car because three pedals might confuse some drivers......

Here in the States it would confuse most drivers so we take the clutch away. You can get one if you really want one but it might be a special order for some models if it's even available.

 

merikans really are special, lol.

The States is also leading the charge in coming out with automatic transmissions on transport trucks so that they can lower the quality of drivers for them...
Link to comment
  • 3 weeks later...

Anybody know the answer to this

...I have also read on the forum that /mnt/user does not work with hard links. Is this true and could this be an issue when specifying /mnt/user/appdata?

since /mnt/user/appdata was part of the proposal?

 

i've seen issues that have been resolved in containers by using /mnt/cache/appdata in place of /mnt/user/appdata

 

To bump up this thread and provide my $0.02

 

I concur with sparkly's statement. Many of my containers do not work if the appdata is on a user share. In other words, /mnt/user/appdata does not work, but /mnt/cache/appdata works and /mnt/diskX/appdata works as well (likely due to links, but did not have a chance to confirm)

 

Another thing I wanted to highlight is that mapping /mnt or /mnt/user by default is not a good idea. Why not leave that decision up to the container authors and make it optional? That way if a container needs access to the array (for instance plex definitely does) then the author can put that option in.

 

For instance my duckdns container has absolutely no need for /mnt mapping. In fact I could get away with not even having an appdata folder as all the necessary info is in the template xml (it needs the duckdns subdomain and the api key, which are passed as environment variables so it can run a cron script every 5 minutes to update the dynamic dns address).

 

Which brings me to my third point which may be out of scope for this thread, and if so please let me know the best place to discuss that. The reason the duckdns container still has the appdata folder is because during a container update, the xml was updated to include the environment variables in the template. In the old method, the user had to modify a config file in the appdata folder to input the subdomain and the api key). However, since the container xml's do not get updated when unraid updates a container, I had to provide a failsafe option that relies on the config file if environment variables are not set. I had to do a bunch of extra coding to keep both methods in just because I knew that existing users would not read the changelog and would not realize the missing env variables.

 

Can we add a method to update the container xml's in dockerman? One suggestion I can come up with is, dockerman can tag the user entered (manually) variables so they are distinguishable from the dev added ones. So during a container update, dockerman can check for differences in the dev modified variables and prompt the user for changes or confirmation.

 

That way, when I updated the duckdns container, the new xml would contain two new dev entered variables that do not exist on the dockerman saved one and it could prompt the user and ask them to enter that new info.

 

Sorry for the long post but I wanted to get it out before the next version is ready.

 

Thanks

Link to comment

I too have had issues with the /mnt/user/appdata mapping instead of /mnt/cache/appdata.  If the appdata is "cache only" and the cache settings are not set properly, a write can fail to the appdata share on the cache.  For example, the cache has 20GB free space and the cache "Min. Free Space" is set to 50GB, the write will fail to the appdata if mapped to /mnt/user/appdata.

Link to comment

Anybody know the answer to this

...I have also read on the forum that /mnt/user does not work with hard links. Is this true and could this be an issue when specifying /mnt/user/appdata?

since /mnt/user/appdata was part of the proposal?

 

i've seen issues that have been resolved in containers by using /mnt/cache/appdata in place of /mnt/user/appdata

 

To bump up this thread and provide my $0.02

 

I concur with sparkly's statement. Many of my containers do not work if the appdata is on a user share. In other words, /mnt/user/appdata does not work, but /mnt/cache/appdata works and /mnt/diskX/appdata works as well (likely due to links, but did not have a chance to confirm).

 

If that's the case, we need bug reports opened and logs so we can resolve.

 

Another thing I wanted to highlight is that mapping /mnt or /mnt/user by default is not a good idea.

 

Why?  Users will have the option to NOT have this happen with a toggle under the Docker Settings page (a checkbox to auto-map all user shares to all new containers).  It will be on by default, but can be toggled off.

 

Why not leave that decision up to the container authors and make it optional? That way if a container needs access to the array (for instance plex definitely does) then the author can put that option in.

 

Authors shouldn't be determining where data goes on a user's system.  Instead, the user should have that choice.  That's how installing applications on ANY OS would work for fairly logical reasons.

 

There are numerous issues with letting an author specify the host path mapping for containers.  I've seen examples where authors path to /mnt/somethingrandom instead of a common path that is on all systems.  If a user added a container and just accepted that as a default value, then whatever would be written to that path would literally be going to RAM.  Nothing would persist and memory would slowly get chewed up until eventually the system would start to have issues because of low memory.

 

To go a step further, authors don't all use the same container path name for common paths.  E.g. /data vs. /appdata or /media vs. /movies.  So now the user has to remember, on an app by app basis for all their containers, what volume mappings tie to what hostmappings.  If we have a universal rule that /unraid maps to /mnt/user or /mnt for ALL containers, then when users are leveraging ANY application in a container and need to path to some share on the host, it would be the same method (just browse to /unraid).

 

For instance my duckdns container has absolutely no need for /mnt mapping. In fact I could get away with not even having an appdata folder as all the necessary info is in the template xml (it needs the duckdns subdomain and the api key, which are passed as environment variables so it can run a cron script every 5 minutes to update the dynamic dns address).

 

But what does it hurt for it to be there?  I get that some folks have OCD when it comes to data access, but keep in mind that for years we have had plugins, which have unrestricted access to the entire system (all data paths both on persistent storage, the flash device, and the root ram filesystem).  No one seemed to mind.  So now we have docker where we CAN restrict that, but should we?  For experienced users, managing data access on a container by container basis is easy, but for new users, this just adds extra confusion that isn't necessary.  We have to care about the new user experience because our growth as a company is entirely reliant on new users at this point.  For the duckdns container to have access to /mnt/user or /mnt/appdata isn't a big deal.

 

Which brings me to my third point which may be out of scope for this thread, and if so please let me know the best place to discuss that. The reason the duckdns container still has the appdata folder is because during a container update, the xml was updated to include the environment variables in the template. In the old method, the user had to modify a config file in the appdata folder to input the subdomain and the api key). However, since the container xml's do not get updated when unraid updates a container, I had to provide a failsafe option that relies on the config file if environment variables are not set. I had to do a bunch of extra coding to keep both methods in just because I knew that existing users would not read the changelog and would not realize the missing env variables.

 

Can we add a method to update the container xml's in dockerman? One suggestion I can come up with is, dockerman can tag the user entered (manually) variables so they are distinguishable from the dev added ones. So during a container update, dockerman can check for differences in the dev modified variables and prompt the user for changes or confirmation.

 

That way, when I updated the duckdns container, the new xml would contain two new dev entered variables that do not exist on the dockerman saved one and it could prompt the user and ask them to enter that new info.

 

Brain is too fried from CES right now to even begin addressing this, but I will speak with Eric and get his input on the best way to handle it.

Link to comment

Anybody know the answer to this

...I have also read on the forum that /mnt/user does not work with hard links. Is this true and could this be an issue when specifying /mnt/user/appdata?

since /mnt/user/appdata was part of the proposal?

 

i've seen issues that have been resolved in containers by using /mnt/cache/appdata in place of /mnt/user/appdata

 

To bump up this thread and provide my $0.02

 

I concur with sparkly's statement. Many of my containers do not work if the appdata is on a user share. In other words, /mnt/user/appdata does not work, but /mnt/cache/appdata works and /mnt/diskX/appdata works as well (likely due to links, but did not have a chance to confirm).

 

If that's the case, we need bug reports opened and logs so we can resolve.

 

Another thing I wanted to highlight is that mapping /mnt or /mnt/user by default is not a good idea.

 

Why?  Users will have the option to NOT have this happen with a toggle under the Docker Settings page (a checkbox to auto-map all user shares to all new containers).  It will be on by default, but can be toggled off.

 

Why not leave that decision up to the container authors and make it optional? That way if a container needs access to the array (for instance plex definitely does) then the author can put that option in.

 

Authors shouldn't be determining where data goes on a user's system.  Instead, the user should have that choice.  That's how installing applications on ANY OS would work for fairly logical reasons.

 

There are numerous issues with letting an author specify the host path mapping for containers.  I've seen examples where authors path to /mnt/somethingrandom instead of a common path that is on all systems.  If a user added a container and just accepted that as a default value, then whatever would be written to that path would literally be going to RAM.  Nothing would persist and memory would slowly get chewed up until eventually the system would start to have issues because of low memory.

 

To go a step further, authors don't all use the same container path name for common paths.  E.g. /data vs. /appdata or /media vs. /movies.  So now the user has to remember, on an app by app basis for all their containers, what volume mappings tie to what hostmappings.  If we have a universal rule that /unraid maps to /mnt/user or /mnt for ALL containers, then when users are leveraging ANY application in a container and need to path to some share on the host, it would be the same method (just browse to /unraid).

 

For instance my duckdns container has absolutely no need for /mnt mapping. In fact I could get away with not even having an appdata folder as all the necessary info is in the template xml (it needs the duckdns subdomain and the api key, which are passed as environment variables so it can run a cron script every 5 minutes to update the dynamic dns address).

 

But what does it hurt for it to be there?  I get that some folks have OCD when it comes to data access, but keep in mind that for years we have had plugins, which have unrestricted access to the entire system (all data paths both on persistent storage, the flash device, and the root ram filesystem).  No one seemed to mind.  So now we have docker where we CAN restrict that, but should we?  For experienced users, managing data access on a container by container basis is easy, but for new users, this just adds extra confusion that isn't necessary.  We have to care about the new user experience because our growth as a company is entirely reliant on new users at this point.  For the duckdns container to have access to /mnt/user or /mnt/appdata isn't a big deal.

 

Which brings me to my third point which may be out of scope for this thread, and if so please let me know the best place to discuss that. The reason the duckdns container still has the appdata folder is because during a container update, the xml was updated to include the environment variables in the template. In the old method, the user had to modify a config file in the appdata folder to input the subdomain and the api key). However, since the container xml's do not get updated when unraid updates a container, I had to provide a failsafe option that relies on the config file if environment variables are not set. I had to do a bunch of extra coding to keep both methods in just because I knew that existing users would not read the changelog and would not realize the missing env variables.

 

Can we add a method to update the container xml's in dockerman? One suggestion I can come up with is, dockerman can tag the user entered (manually) variables so they are distinguishable from the dev added ones. So during a container update, dockerman can check for differences in the dev modified variables and prompt the user for changes or confirmation.

 

That way, when I updated the duckdns container, the new xml would contain two new dev entered variables that do not exist on the dockerman saved one and it could prompt the user and ask them to enter that new info.

 

Brain is too fried from CES right now to even begin addressing this, but I will speak with Eric and get his input on the best way to handle it.

 

off the top of my head, there seem to be issues with containers with sqlite and postgres when mapped to a user share.

and as far as mapping /mnt to a container en masse, i've seen at least one container on CA in the past that did an operation on the whole mount point.. and god knows what it's like on the hub at large.

Link to comment

Anybody know the answer to this

...I have also read on the forum that /mnt/user does not work with hard links. Is this true and could this be an issue when specifying /mnt/user/appdata?

since /mnt/user/appdata was part of the proposal?

 

i've seen issues that have been resolved in containers by using /mnt/cache/appdata in place of /mnt/user/appdata

 

To bump up this thread and provide my $0.02

 

I concur with sparkly's statement. Many of my containers do not work if the appdata is on a user share. In other words, /mnt/user/appdata does not work, but /mnt/cache/appdata works and /mnt/diskX/appdata works as well (likely due to links, but did not have a chance to confirm).

 

If that's the case, we need bug reports opened and logs so we can resolve.

 

Another thing I wanted to highlight is that mapping /mnt or /mnt/user by default is not a good idea.

 

Why?  Users will have the option to NOT have this happen with a toggle under the Docker Settings page (a checkbox to auto-map all user shares to all new containers).  It will be on by default, but can be toggled off.

 

Why not leave that decision up to the container authors and make it optional? That way if a container needs access to the array (for instance plex definitely does) then the author can put that option in.

 

Authors shouldn't be determining where data goes on a user's system.  Instead, the user should have that choice.  That's how installing applications on ANY OS would work for fairly logical reasons.

 

There are numerous issues with letting an author specify the host path mapping for containers.  I've seen examples where authors path to /mnt/somethingrandom instead of a common path that is on all systems.  If a user added a container and just accepted that as a default value, then whatever would be written to that path would literally be going to RAM.  Nothing would persist and memory would slowly get chewed up until eventually the system would start to have issues because of low memory.

 

To go a step further, authors don't all use the same container path name for common paths.  E.g. /data vs. /appdata or /media vs. /movies.  So now the user has to remember, on an app by app basis for all their containers, what volume mappings tie to what hostmappings.  If we have a universal rule that /unraid maps to /mnt/user or /mnt for ALL containers, then when users are leveraging ANY application in a container and need to path to some share on the host, it would be the same method (just browse to /unraid).

 

For instance my duckdns container has absolutely no need for /mnt mapping. In fact I could get away with not even having an appdata folder as all the necessary info is in the template xml (it needs the duckdns subdomain and the api key, which are passed as environment variables so it can run a cron script every 5 minutes to update the dynamic dns address).

 

But what does it hurt for it to be there?  I get that some folks have OCD when it comes to data access, but keep in mind that for years we have had plugins, which have unrestricted access to the entire system (all data paths both on persistent storage, the flash device, and the root ram filesystem).  No one seemed to mind.  So now we have docker where we CAN restrict that, but should we?  For experienced users, managing data access on a container by container basis is easy, but for new users, this just adds extra confusion that isn't necessary.  We have to care about the new user experience because our growth as a company is entirely reliant on new users at this point.  For the duckdns container to have access to /mnt/user or /mnt/appdata isn't a big deal.

 

Which brings me to my third point which may be out of scope for this thread, and if so please let me know the best place to discuss that. The reason the duckdns container still has the appdata folder is because during a container update, the xml was updated to include the environment variables in the template. In the old method, the user had to modify a config file in the appdata folder to input the subdomain and the api key). However, since the container xml's do not get updated when unraid updates a container, I had to provide a failsafe option that relies on the config file if environment variables are not set. I had to do a bunch of extra coding to keep both methods in just because I knew that existing users would not read the changelog and would not realize the missing env variables.

 

Can we add a method to update the container xml's in dockerman? One suggestion I can come up with is, dockerman can tag the user entered (manually) variables so they are distinguishable from the dev added ones. So during a container update, dockerman can check for differences in the dev modified variables and prompt the user for changes or confirmation.

 

That way, when I updated the duckdns container, the new xml would contain two new dev entered variables that do not exist on the dockerman saved one and it could prompt the user and ask them to enter that new info.

 

Brain is too fried from CES right now to even begin addressing this, but I will speak with Eric and get his input on the best way to handle it.

 

off the top of my head, there seem to be issues with containers with sqlite and postgres when mapped to a user share.

and as far as mapping /mnt to a container en masse, i've seen at least one container on CA in the past that did an operation on the whole mount point.. and god knows what it's like on the hub at large.

Then don't use that container. That's a bad container.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.