Docker FAQ feedback


Recommended Posts

Q why should my appdata share be cache only

A because the damn mover will move files and the docker won't be able to find them...

 

refine as appropriate, lol.

Better question would be why when I set appdata to be /mnt/user/appdata/$APPNAME and mover moves it why do I have problems since that path is still valid regardless of whether the files are sitting on the cache drive or on the data drives.
Link to comment

Q why should my appdata share be cache only

A because the damn mover will move files and the docker won't be able to find them...

 

refine as appropriate, lol.

Better question would be why when I set appdata to be /mnt/user/appdata/$APPNAME and mover moves it why do I have problems since that path is still valid regardless of whether the files are sitting on the cache drive or on the data drives.

 

something about mover and files in use ??? i don't know tbh...

Link to comment

Q why should my appdata share be cache only

A because the damn mover will move files and the docker won't be able to find them...

 

refine as appropriate, lol.

Better question would be why when I set appdata to be /mnt/user/appdata/$APPNAME and mover moves it why do I have problems since that path is still valid regardless of whether the files are sitting on the cache drive or on the data drives.

 

something about mover and files in use ??? i don't know tbh...

And neither do I...  Don't have the time (read that as don't care enough - there's a work around already) to investigate fully.
Link to comment

I haven't forgotten about the request for writing up the cache-only FAQ. Having a little trouble figuring out the question though.

 

I just answered one this morning because the user's docker quit working. He said he had recently upgraded from an RC as if that was the problem. His diagnostics showed the appdata share with default settings, and the syslog showed mover moving it.

 

Maybe the question should be: My docker was working fine yesterday. What happened?

 

Check out JustinChase's method, multiple questions, found here.  I thought that was a great idea, when it's the same problem but manifests in different ways.

Link to comment

I was talking with Sparkly, and he had a decent enough idea (don't want to stroke his ego just yet and say good idea) about this.

 

Since dockerMan is pretty much off limits to modifications, it is possible to modify Community Apps to alleviate some of this problem.

 

I can have CA automatically fill out empty host volume paths as /mnt/user, and take a shot and fill out any container paths of /config to /mnt/cache/appdata/$APPNAME

 

This would obviously be a selectable feature (disabled or enabled by default?), with huge warnings about the risks of passing /mnt/user and would only affect adding new containers or default settings.  Edits it wouldn't touch.

 

/config mappings should ideally have another xml tag that labels it as the appdata folder, but I'm not going to go and propose a new schema change for something like this just yet.

 

Looking for the peanut gallery's input here.

 

what a great idea...

Since I don't see any downside on having this as an optional experimental feature, I'll be pumping out an update to CA later today that will incorporate this.

 

One additional thing that I've added is that it if /mnt/user/appdata does not exist (ie: no share created), then it will create it, and also set it to be cache only.  (unRaid ignores this setting if there is no cache drive existing)  edit: I thought it did, but it turns out that writes to a cache only share without a cache drive will fail.  So without a cache drive present, I merely create the directory, but don't bother with setting any rules for the share.

 

If there share already exists, then I won't touch the cache settings because I don't think its right to modify a user's settings

 

Link to comment

I can have CA automatically fill out empty host volume paths as /mnt/user, and take a shot and fill out any container paths of /config to /mnt/cache/appdata/$APPNAME

 

This would obviously be a selectable feature (disabled or enabled by default?), with huge warnings about the risks of passing /mnt/user and would only affect adding new containers or default settings.  Edits it wouldn't touch.

 

/config mappings should ideally have another xml tag that labels it as the appdata folder, but I'm not going to go and propose a new schema change for something like this just yet.

 

Looking for the peanut gallery's input here.

 

I think it's a great idea!

 

One additional thing that I've added is that it if /mnt/user/appdata does not exist (ie: no share created), then it will create it, and also set it to be cache only.  (unRaid ignores this setting if there is no cache drive existing)

 

If there share already exists, then I won't touch the cache settings because I don't think its right to modify a user's settings

 

 

Also, great idea.

 

Sometimes I really love this place :)

 

Other times I'm sad I started down this path when none of these great tools were available.  Oh the time I could have saved it they had been ;)

Link to comment

If there is no cache drive and unRAID just cruises on ignoring that, then won't the appdata files eventually get spread out throughout the array drives?

 

Maybe if jo cache drive, then set it to use disk1 only.

Isn't the worst case that multiple drives would spin up?  You could always modify the share settings accordingly.  There's no way that something like this is going to be able to optimize the settings for any particular user.  Right now on this experiment I'm more concerned with a setup that will just plain work.  Optimizations come later.

 

But feedback like this is what I / we need.

 

Just pumped out the update to CA.  No way I can test 190 apps to see if it populates them correctly, and there is always going to be an exception to the rule somewhere.

 

Link to comment

On a somewhat related note, I'm contemplating a "Docker Sanity Check" plugin

 

Something to go through and fix problems.

 

The only problem right now that pops into my head that's fixable would be appdata not set to be cache only (on systems with a cache drive)

 

Now here's the question if anyone has a good answer for it.  Why does mover mess up appdata shares?  Is it only because the user's path mappings refer to /mnt/cache/appdata instead of /mnt/user/appdata?  Or because mover messes up permissions?  After mover has moved everything over to the array, can it just be copied back, appdata set to cache only and be good to go?

 

 

Are there any other user setup problems that are easily fixable through automation?

Link to comment

I think it messes things up because appdata is no longer on the cache, because mover puts it onto the array.

 

I believe just copying appdata back, but leaving the folder on the array won't work, as having that folder in both places 'confuses' unRAID.  I believe it needs to be moved back, so that it only exists on cache.

Link to comment

I think it messes things up because appdata is no longer on the cache, because mover puts it onto the array.

 

I believe just copying appdata back, but leaving the folder on the array won't work, as having that folder in both places 'confuses' unRAID.  I believe it needs to be moved back, so that it only exists on cache.

That's what I'm hoping for.  Guess I'll add a cache drive to the secondary server tomorrow and try and mess it up and figure out how to fix it.
Link to comment
  • 1 month later...

As a suggestion for the FAQ, though possibly not frequent:

 

How can we manually modify the 'docker start' autostart command that seems to be populated through the template?

 

Background: I have a background script that requires launching a container (through 'docker run', not 'docker start') with flags including --rm and -cpuset-cpus.  I can't see how to include any of these options in the template.  I can keep a copy of the run command (with mappings) handy for use through ssh when the server is rebooted, but it would be great to have this custom container autostarted, or restarted.

 

D

 

Link to comment

As a suggestion for the FAQ, though possibly not frequent:

 

How can we manually modify the 'docker start' autostart command that seems to be populated through the template?

 

Background: I have a background script that requires launching a container (through 'docker run', not 'docker start') with flags including --rm and -cpuset-cpus.  I can't see how to include any of these options in the template.  I can keep a copy of the run command (with mappings) handy for use through ssh when the server is rebooted, but it would be great to have this custom container autostarted, or restarted.

 

D

You should be able to put those extra paramters in the <ExtraParams> </ExtraParams> tag in the template xml. In the webgui it's under advanced view and Extra Paramters.

Link to comment

Requesting review for accuracy of a simple question, found here.

 

Actually, you can move the image file. I have moved it from the cache drive to an SSD outside of the array. All you have to do is, stop docker, move img file, enter the new img path in unraid gui, restart docker.

 

UnRaid webgui is actually pretty smart in the way it treats the image file (props to whoever is responsible). If the image file exists in the location entered, it will use it. If not, it will create a new one. If you stop docker, change the image size to a larger number, and restart, unRaid will automatically resize the existing file and mount it (I assume it uses dd command to add extra bits). You won't have to recreate anything.

Link to comment

Thank you!  I've revised it, would appreciate another review, make sure I got it right!

 

By the way, what rsync command would others use?

 

Sounds about right. Except, I would probably recommend using mc (it is a part of unraid now). It should be much less scary than rsync for newbies.

Link to comment

Thank you!  I've revised it, would appreciate another review, make sure I got it right!

 

By the way, what rsync command would others use?

 

Sounds about right. Except, I would probably recommend using mc (it is a part of unraid now). It should be much less scary than rsync for newbies.

You're right.  I've revised it.  Thank you!

Link to comment
  • 2 months later...
  • 5 months later...

RobJ:  If you want to cut and paste this into your original post, then feel free to do so and then delete this posting, but I think it's important enough to stand alone - just really couldn't think of an appropriate Q&A format for it

 

I gave it some thought, and felt it was better unified, so I did, inplace in yours.  But I can see a rationale for a separate posting dedicated to just appdata pathing.

 

However, I also realized you had found a great way to transfer control of a posting to another user(!), with the help of a moderator, to a user who may be better suited for ongoing maintenance of the subject matter.  And you are closer to that subject matter than I am.  So I've modified your post to unify it, deleted mine, and pointed the Q's in the index to yours.  Feel free to rewrite/reformat/fix it as you like.

Link to comment
  • 2 weeks later...

Questions for FAQ more for authors:

1). Mapping USB device so Container can use the USB device?  Will unRaid need drivers for the USB device or just the Container?  Pass by bus or what USB shows up in unRAID?  I.e. /dev/ttyUSB1

2). Let a Container see unRAID system stats like CPU %, Bandwidth, ram, disk % etc.

 

 

Sent from my XT1563 using Tapatalk

 

 

Link to comment
  • 2 months later...

Questions for FAQ more for authors:

1). Mapping USB device so Container can use the USB device?  Will unRaid need drivers for the USB device or just the Container?  Pass by bus or what USB shows up in unRAID?  I.e. /dev/ttyUSB1

2). Let a Container see unRAID system stats like CPU %, Bandwidth, ram, disk % etc.

 

Bumping this for knowledgeable authors ...

Link to comment

Additional FAQ entries requested -

* linking between containers, ie between sab and sickbeard - this might be best for specific author support FAQ's, as to how their containers should be linked

* folder mapping - sufficiently covered yet?  more needed?

* port mapping - probably need both a general FAQ here, and individual FAQ's for many of the containers

* location for the image file - answered in Upgrading to UnRAID v6 guide, but should be here too

* where to put appdata - probably need a general FAQ here, but could use individual FAQ's for some containers


 

Squid, or anyone else, I know you're busy, but if/when you have time, could you comment on the list above - which ones are covered sufficiently, and which could use more or better info?

Link to comment
  • trurl pinned this topic

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.