Docker FAQ feedback

[sparklyballs]

as i have probably stated before i'm hopeless at writing things up, but just going on things i see getting asked a lot, should cover (in no particular order).

 

linking between containers , ie between sab and sickbeard

 

folder and port mapping

 

where to put the image file

 

where to put appdata.

 

Moderator edit: with abject apologies to SparklyBalls, since his post was the first, I'm commandeering the bottom of it to start this feedback topic for the Docker FAQ.  I decided to pull weight a bit, to keep the FAQ clean, and move all other commentary, relevant or not, to this thread, nothing deleted.  The discussion is good, but this is a better place for it.  It's also available for FAQ requests and suggestions.

[sparklyballs]

Where are my downloads stored?  Why can't I find my downloads from one Docker in another Docker?  Why can't I see my (something) folder in the Docker?

 

These and other, similar questions and complaints are very frequent, and all stem from the container volume and host path settings in the Docker setup.  I think it starts with the docker authors offering some 'suggestions' for their containers, which point towards setting up things like /tv or /downloads in the container volume, then mapping it to that specific part of the unRAID setup using the host path box.

 

People often setup things like [container volume] /tv pointing to [host path] /mnt/user/video/TV.  This results in the user picking /tv as the path in the docker setup, but only being able to see all the subdirectories they have under /mnt/user/video/TV in their inRAID setup.  With this config, they can't see anything in /mnt/user/video/Movies; for example.  To see items in this directory they need to set another, different container/host config in the docker setup.

 

I struggled with this also when I first got started with Dockers, then someone (can't remember who, sorry) suggested I just map  [container volume] /mnt/user pointing to [host path] /mnt/user.  This works perfect for me, and has for the last year or so.

 

The benefit of this method is that all your dockers will see your directory structure the exact same way, which is the same way you navigate it in unTAID itself.  You have full access to all of your user share directories in all of your containers, so it doesn't matter what folder you choose to have SABnzbd download into, you can get to that same folder from any/all other dockers.  If you decide to change the download folder (or anything) in one docker, it's easy to point to the new place in your other dockers, without having to change the config of the other dockers.

 

Some have suggested there is a security issue with this method because you're allowing your dockers access to folders they don't need access to, but really, as long as you use /mnt/user, you're only allowing them access to your user shares, not any important, unRAID stuff (flash is not accessible with this method), so I personally don't consider this a security issue.  Now, if you just mapped /mnt to /mnt, then you're giving direct access to the individual disks, which I would not suggest.

 

I personally wish dockers didn't offer /tv or /movies or /downloads in the default config, as it just leads to confusion and LOTS of the same questions by folks new to the docker system.  Once you've used it, and understand what these mappings do, it's easy to add a /tv to /mnt/user/video/TV mapping if you choose, but starting people unfamiliar down this path has led to more frustration than happiness, from what I've seen of the questions it brings.

 

ugh, using /mnt or /mnt/user leaves you at the mercy of the docker author, they mess something up in a script and you can end up with all your permissions changed or even worse stuff getting deleted, one of the good things about dockers and mapping is that you can limit what folders a container has access and mitigate any potential dangers, passing through /mnt or /mnt/user undoes that.

[JustinChase]

 

ugh, using /mnt or /mnt/user leaves you at the mercy of the docker author, they mess something up in a script and you can end up with all your permissions changed or even worse stuff getting deleted, one of the good things about dockers and mapping is that you can limit what folders a container has access and mitigate any potential dangers, passing through /mnt or /mnt/user undoes that.

 

maybe, but I've never had such an issue, and have passed /mnt/user since day 1, literally.

 

if an author messes up a script, and it deletes data, it would delete data in whatever got mapped, so it would still be a pretty big disaster, right?

 

I've seen dozens of posts in the last week about this mapping issue, and ALL of them would not have been asked it they had passed /mnt/user to /mnt/user.

 

maybe it is "dangerous", but actual use has not shown it to be problematic thus far.  The current method of passing limited folders has shown to be very problematic.

 

I'm not saying you're incorrect, just that the real world shows my method works great; so far

 

*also, as a person that has not authored a docker personally, how bad must a script be to actually delete user data on mapped drives?  is it really a likely possibility, or a very, very remote possibility?  Seriously, not rhetorical, I honestly don't know.

[sparklyballs]

 

ugh, using /mnt or /mnt/user leaves you at the mercy of the docker author, they mess something up in a script and you can end up with all your permissions changed or even worse stuff getting deleted, one of the good things about dockers and mapping is that you can limit what folders a container has access and mitigate any potential dangers, passing through /mnt or /mnt/user undoes that.

 

maybe, but I've never had such an issue, and have passed /mnt/user since day 1, literally.

 

if an author messes up a script, and it deletes data, it would delete data in whatever got mapped, so it would still be a pretty big disaster, right?

 

I've seen dozens of posts in the last week about this mapping issue, and ALL of them would not have been asked it they had passed /mnt/user to /mnt/user.

 

maybe it is "dangerous", but actual use has not shown it to be problematic thus far.  The current method of passing limited folders has shown to be very problematic.

 

I'm not saying you're incorrect, just that the real world shows my method works great; so far

 

*also, as a person that has not authored a docker personally, how bad must a script be to actually delete user data on mapped drives?  is it really a likely possibility, or a very, very remote possibility?  Seriously, not rhetorical, I honestly don't know.

 

want me to write a container that will demonstrate it , lol

[JustinChase]

no, i believe it's possible, but how likely is someone to do it by mistake?  I mean, is this a concern one should really worry about? 

 

I know the Russians can send nuclear bombs to my very small mountain town, but I'm not concerned about it, the likelihood seems very small to me.

[sparklyballs]

on sunday whilst testing a container (and sometimes to make it easier during testing, i pass through at /mnt/user level) i deleted the entire contents of /mnt/user/appdata because of a misplaced rm -rf in a firstrun file.

[Squid]

 

ugh, using /mnt or /mnt/user leaves you at the mercy of the docker author, they mess something up in a script and you can end up with all your permissions changed or even worse stuff getting deleted, one of the good things about dockers and mapping is that you can limit what folders a container has access and mitigate any potential dangers, passing through /mnt or /mnt/user undoes that.

if an author messes up a script, and it deletes data, it would delete data in whatever got mapped, so it would still be a pretty big disaster, right?

Difference being is that passing /mnt you're always going to pass it with read-write permissions.  /TV you wouldn't necessarily have to do that.

*also, as a person that has not authored a docker personally, how bad must a script be to actually delete user data on mapped drives?  is it really a likely possibility, or a very, very remote possibility?  Seriously, not rhetorical, I honestly don't know.

Not that its directly relevant, but just a few months ago a moderator here accidentally deleted his entire movie collection by making a simple typo in an rm command.

 

ugh, using /mnt or /mnt/user leaves you at the mercy of the docker author, they mess something up in a script and you can end up with all your permissions changed or even worse stuff getting deleted, one of the good things about dockers and mapping is that you can limit what folders a container has access and mitigate any potential dangers, passing through /mnt or /mnt/user undoes that.

And you're the one we trust to make docker apps??!? 

 

But all kidding aside, while I agree that ideally passing through only TV or Movies, etc is the best way to accomplish folder mappings, when push comes to shove /mnt to /mnt is far and away the easiest way to map folders over to containers.  I did my best to try and explain how this works a couple of posts above, but it is a confusing subject.  Its one of those subjects that "you're not going to be able to understand it until you understand it"  Like I said, some one needs to make a video with a whiteboard, hand gestures, and an English accent.

 

Until we can come up with a easy to understand method of explaining this concept, /mnt is the easiest way to do things.  Yes there are some risks.  Are they likely? Probably not.  Are they possible? Yes  In my case, I didn't want any of the plex users in the house to be able to delete any media from the collection.  So I made the collection read-only.

 

 

[JustinChase]

whoops!

 

if you had not mapped /mnt/user, and instead mapped /tv to /mnt/user/video/tv instead, wouldn't the same thing have happened (deleted the entire /tv directory)?

 

I mean, isn't the danger still there, just to a lesser degree by limiting the mapping?

 

Yeah, losing /mnt/user is MUCH worse than losing /mnt/user/video/tv, but still; either would be pretty bad if you'd released your mistake upon the world, right?

[sparklyballs]

whoops!

 

if you had not mapped /mnt/user, and instead mapped /tv to /mnt/user/video/tv instead, wouldn't the same thing have happened (deleted the entire /tv directory)?

 

I mean, isn't the danger still there, just to a lesser degree by limiting the mapping?

 

Yeah, losing /mnt/user is MUCH worse than losing /mnt/user/video/tv, but still; either would be pretty bad if you'd released your mistake upon the world, right?

 

not in my case, because i don't do any copy or moves in those kinds of folders (media, etc). but i've seen it in other containers.

 

one thing you absolutely have to bear in mind with pretty much most dockers is that they are root user, it's just not good in all kinds of ways to give a container that much access to /mnt/user

[Squid]

whoops!

 

if you had not mapped /mnt/user, and instead mapped /tv to /mnt/user/video/tv instead, wouldn't the same thing have happened (deleted the entire /tv directory)?

 

I mean, isn't the danger still there, just to a lesser degree by limiting the mapping?

 

Yeah, losing /mnt/user is MUCH worse than losing /mnt/user/video/tv, but still; either would be pretty bad if you'd released your mistake upon the world, right?

The difference is permissions.  EG On my system, plex only has RO permissions (it doesn't need to write) to the media, and it does NOT have access to any of those "special" pictures of my wife (wouldn't want someone to accidentally view them now would we).  SAB only has RW access to downloads.  CP has RO permissions to media on one server, and RW to the other.

 

The thing is that I would think that most users have gone to the trouble of securing their shares.  User A only has access to certain shares.  User B can read some shares, write to others, User C we just don't trust at all and can only read and write his own personal share.  Setting up /mnt with something like plex for instance will automatically grant the docker container (and by extension the user using plex at the HTPC) full RW access to all of your shares (including the "special" pictures folder).

 

What sparkly and I are saying is that individual mappings with appropriate permissions is the correct way to do things (in my FAQ posting above I refer to this as "best-practice".  However, I am in agreement with you that /mnt is the easiest way to accomplish this for new users.  But I will always cringe when I see it -> even though lately I've been advocating it for the new user.  But it is definitely not the "right" way to accomplish things.

 

It may sound like I'm arguing both sides of the coin, and I guess that I am. 

 

[aptalca]

My submission for a frequently asked question is:

 

Who is sparklyballs and how does he have time to create and maintain a million containers?

 

Possible answers are:

A) He's a vampire and he simply doesn't sleep

B) He's high on coke all the time

C) He has special powers and he can slow down time

D) He's from a galaxy far away

 

I haven't figured out the correct answer yet, but judging by his profile pic, any one of them could be true :-p

[Squid]

My submission for a frequently asked question is:

 

Who is sparklyballs and how does he have time to create and maintain a million containers?

 

Possible answers are:

A) He's a vampire and he simply doesn't sleep

B) He's high on coke all the time

C) He has special powers and he can slow down time

D) He's from a galaxy far away

 

I haven't figured out the correct answer yet, but judging by his profile pic, any one of them could be true :-p

I think you should create a poll for this one.  But I'd add "All of the above"

[smakovits]

Who maintains docker with unraid?  Does unraid need a update to get docker to 1.7 or can it be done independently?

[Squid]

Who maintains docker with unraid?  Does unraid need a update to get docker to 1.7 or can it be done independently?

Limetech.  Although I suppose you *could* build a custom kernel if you really wanted to do it yourself.

[smakovits]

UM,  no,  I'm just trying to figure out how to make my own container still.

[RobJ]

My apologies to everyone, but I decided to pull weight a bit, to keep the FAQ clean, and move all other commentary, relevant or not, to this thread.  The discussion is good, but this is a better place for it.  It's also available for FAQ requests and suggestions.  I will move further non-FAQ posts here too.  You can still quote posts from there, just use the Quote button, then copy the whole thing over here, create a new post here, and paste it in.

[Squid]

Probably a good move relocating the posts that are comments / questions out of the FAQ thread.  Should keep it a lot cleaner, although users looking at the FAQ should also read this thread for any differing opinions, comments, etc.

[NAS]

I am late to this party but we absolutely should not be advocating a default of passing /mnt/user RW into all docker running as root. Yes it is easier for the end user but one day it will cause someone to lose all their data, that is an absolute certainty (russian roulette with hardly any bulltets but  with thousands of users and random strangers loading the gun =  bad).

 

Even if no one ever makes a mistake there are plenty of applications out there that collect info on people. Why on earth would we let all apps see people documents and family photos.

 

Docker hub is the wild west and they intentionally have a very low skill barrier to post there. At the very minimum and ONLY if we must dumb this down to "share everything with everything" it should be RO but I vote as strongly as I can not to do this as it is essentially the mistake all the phone OS's made and look how much that ruined things.

 

 

[sparklyballs]

Docker hub is the wild west

 

even worse with containers from docker hub that are for general use rather than unraid aware containers is that there is no concept of a user share etc... so the likelihood of a rm -rf on a whole folder tree is higher...

[Squid]

I am late to this party but we absolutely should not be advocating a default of passing /mnt/user RW into all docker running as root. Yes it is easier for the end user but one day it will cause someone to lose all their data, that is an absolute certainty (russian roulette with hardly any bulltets but  with thousands of users and random strangers loading the gun =  bad).

 

Even if no one ever makes a mistake there are plenty of applications out there that collect info on people. Why on earth would we let all apps see people documents and family photos.

 

Docker hub is the wild west and they intentionally have a very low skill barrier to post there. At the very minimum and ONLY if we must dumb this down to "share everything with everything" it should be RO but I vote as strongly as I can not to do this as it is essentially the mistake all the phone OS's made and look how much that ruined things.

Then we need to figure out how to properly explain the concept.  I took my best shot in the FAQ, and several attempts in various threads.  Until that happens my time is worth more than the hour(s) it takes to walk people through a proper setup and hope that they just get it.  Why I've been arguing both sides of the coin.

[NAS]

I absolutely agree. Unfortunately  this is not a problem of our making but as you say its one we have to deal with. Essnetially you have to teach users a bit of docker technology for them to set this up right.

 

The way docker is being "sold" now in unRAID land is a point and click application store and in many ways it is.. unfortunately this problem breaks that model completely.

 

I suspect LT have some thoughts here.

[Squid]

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.

[sparklyballs]

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

[trurl]

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?

[sparklyballs]

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?

 

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.