unRAID Server Release 6.0-rc6-x86_64 Available

[CHBMB]

Can you still export the share if it's set to hidden with .appdata?  I spend a fair amount of time browsing to appdata on my Windows machine, that would be a deal breaker for me..

A hidden folder won't even appear on your shares page for you to configure it for export.

 

That's pretty much what I thought.  Having said that, I could just go to my cache share and browse it from there..  I might well do that.  Also will make it harder for the Mrs to access it and do untold damage...

I don't think you will be able to see it to browse it. You should be able to enter the path and see its contents though.

 

Don't know about on Linux OSes or Mac but on Windows I can see folder starting with a period.  I may have hidden folders set as visible though.  I have a folder /mnt/cache/.unraid/ that I use to create the media build versions.

 

In fact, now I come to think of it, that isn't exported as a share.  Kind of answered my own question, what a pillock!

[limetech]

re: docker dns issue: Here is what we think is happening based on all the evidence and lots of testing:

 

With regard to dns, docker seems to operate in 1 of 2 modes:

Mode 1 = a --dns option is given, either on docker command line, OR in run command of a specific container

Mode 2 = no --dns option is given either when starting docker or initial run of a container.

 

Mode 1 seems to be bullet-proof, assuming you specify a valid name server IP address in the --dns option.

 

Mode 2 is how we operate by default.  Here’s our findings.  Upon docker initial run of a container, the /etc/resolv.conf of the container is established by looking at the contents of /etc/resolv.conf on host, and the container runs correctly.  Later, say after a reboot or array stop/start (where docker daemon is restarted), if the /etc/resolv.conf of the host no longer EXACTLY matches the /etc/resolv.conf of the container, well we see this 'dns' issue in various manifestations.  Our 'best guess' is that there's a bug in how docker handles this case [all expletives have been redacted].

 

Bottom line is this: we'll be generating a rc6a or maybe rc7 that will remove the code that tries to trigger docker's 'inotify watch' (it's this code in docker that we think is fubar'ed).  In addition we'll add a field to Docker Settings page that lets you add “additional options” which will be appended to DOCKER_OPTS taken from docker.cfg.  This way you can add the –dns=<ipaddr> of your nameserver(s) – not ideal but, makes it work.

 

Alternately you can put the option on each container.

 

Or you can leave as-is, as long as your resolv.conf is static, should work.

[danioj]

re: docker dns issue: Here is what we think is happening based on all the evidence and lots of testing:

 

With regard to dns, docker seems to operate in 1 of 2 modes:

Mode 1 = a --dns option is given, either on docker command line, OR in run command of a specific container

Mode 2 = no --dns option is given either when starting docker or initial run of a container.

 

Mode 1 seems to be bullet-proof, assuming you specify a valid name server IP address in the --dns option.

 

Mode 2 is how we operate by default.  Here’s our findings.  Upon docker initial run of a container, the /etc/resolv.conf of the container is established by looking at the contents of /etc/resolv.conf on host, and the container runs correctly.  Later, say after a reboot or array stop/start (where docker daemon is restarted), if the /etc/resolv.conf of the host no longer EXACTLY matches the /etc/resolv.conf of the container, well we see this 'dns' issue in various manifestations.  Our 'best guess' is that there's a bug in how docker handles this case [all expletives have been redacted].

 

Bottom line is this: we'll be generating a rc6a or maybe rc7 that will remove the code that tries to trigger docker's 'inotify watch' (it's this code in docker that we think is fubar'ed).  In addition we'll add a field to Docker Settings page that lets you add “additional options” which will be appended to DOCKER_OPTS taken from docker.cfg.  This way you can add the –dns=<ipaddr> of your nameserver(s) – not ideal but, makes it work.

 

Alternately you can put the option on each container.

 

Or you can leave as-is, as long as your resolv.conf is static, should work.

 

Thank you for the explanation!

[ogi]

re: docker dns issue: Here is what we think is happening based on all the evidence and lots of testing:

 

With regard to dns, docker seems to operate in 1 of 2 modes:

Mode 1 = a --dns option is given, either on docker command line, OR in run command of a specific container

Mode 2 = no --dns option is given either when starting docker or initial run of a container.

 

Mode 1 seems to be bullet-proof, assuming you specify a valid name server IP address in the --dns option.

 

Mode 2 is how we operate by default.  Here’s our findings.  Upon docker initial run of a container, the /etc/resolv.conf of the container is established by looking at the contents of /etc/resolv.conf on host, and the container runs correctly.  Later, say after a reboot or array stop/start (where docker daemon is restarted), if the /etc/resolv.conf of the host no longer EXACTLY matches the /etc/resolv.conf of the container, well we see this 'dns' issue in various manifestations.  Our 'best guess' is that there's a bug in how docker handles this case [all expletives have been redacted].

 

Bottom line is this: we'll be generating a rc6a or maybe rc7 that will remove the code that tries to trigger docker's 'inotify watch' (it's this code in docker that we think is fubar'ed).  In addition we'll add a field to Docker Settings page that lets you add “additional options” which will be appended to DOCKER_OPTS taken from docker.cfg.  This way you can add the –dns=<ipaddr> of your nameserver(s) – not ideal but, makes it work.

 

Alternately you can put the option on each container.

 

Or you can leave as-is, as long as your resolv.conf is static, should work.

 

Tom,

 

Thanks for this post, I've been trying to follow this DNS issue from a distance and I am unsure how it would impact me when I upgrade to v6 here in the coming days.  This simplifies things tremendously, and may I suggest you copy/paste the contents to the OP?

[CHBMB]

re: docker dns issue: Here is what we think is happening based on all the evidence and lots of testing:

 

With regard to dns, docker seems to operate in 1 of 2 modes:

Mode 1 = a --dns option is given, either on docker command line, OR in run command of a specific container

Mode 2 = no --dns option is given either when starting docker or initial run of a container.

 

Mode 1 seems to be bullet-proof, assuming you specify a valid name server IP address in the --dns option.

 

Mode 2 is how we operate by default.  Here’s our findings.  Upon docker initial run of a container, the /etc/resolv.conf of the container is established by looking at the contents of /etc/resolv.conf on host, and the container runs correctly.  Later, say after a reboot or array stop/start (where docker daemon is restarted), if the /etc/resolv.conf of the host no longer EXACTLY matches the /etc/resolv.conf of the container, well we see this 'dns' issue in various manifestations.  Our 'best guess' is that there's a bug in how docker handles this case [all expletives have been redacted].

 

Bottom line is this: we'll be generating a rc6a or maybe rc7 that will remove the code that tries to trigger docker's 'inotify watch' (it's this code in docker that we think is fubar'ed).  In addition we'll add a field to Docker Settings page that lets you add “additional options” which will be appended to DOCKER_OPTS taken from docker.cfg.  This way you can add the –dns=<ipaddr> of your nameserver(s) – not ideal but, makes it work.

 

Alternately you can put the option on each container.

 

Or you can leave as-is, as long as your resolv.conf is static, should work.

 

Tom,

 

Thanks for this post, I've been trying to follow this DNS issue from a distance and I am unsure how it would impact me when I upgrade to v6 here in the coming days.  This simplifies things tremendously, and may I suggest you copy/paste the contents to the OP?

 

Good idea

+1

[bkastner]

re: docker dns issue: Here is what we think is happening based on all the evidence and lots of testing:

 

With regard to dns, docker seems to operate in 1 of 2 modes:

Mode 1 = a --dns option is given, either on docker command line, OR in run command of a specific container

Mode 2 = no --dns option is given either when starting docker or initial run of a container.

 

Mode 1 seems to be bullet-proof, assuming you specify a valid name server IP address in the --dns option.

 

Mode 2 is how we operate by default.  Here’s our findings.  Upon docker initial run of a container, the /etc/resolv.conf of the container is established by looking at the contents of /etc/resolv.conf on host, and the container runs correctly.  Later, say after a reboot or array stop/start (where docker daemon is restarted), if the /etc/resolv.conf of the host no longer EXACTLY matches the /etc/resolv.conf of the container, well we see this 'dns' issue in various manifestations.  Our 'best guess' is that there's a bug in how docker handles this case [all expletives have been redacted].

 

Bottom line is this: we'll be generating a rc6a or maybe rc7 that will remove the code that tries to trigger docker's 'inotify watch' (it's this code in docker that we think is fubar'ed).  In addition we'll add a field to Docker Settings page that lets you add “additional options” which will be appended to DOCKER_OPTS taken from docker.cfg.  This way you can add the –dns=<ipaddr> of your nameserver(s) – not ideal but, makes it work.

 

Alternately you can put the option on each container.

 

Or you can leave as-is, as long as your resolv.conf is static, should work.

 

So, my question would be this:

 

I have a static IP address on UnRAID and have Active Directory running, so have my UnRAID point to it for DNS. It's been the same DNS servers for longer than I've had UnRaid, which is 3-4 years now. My resolv.conf wouldn't have changed in all this time.

 

I have not had any of these DNS issues until RC6 where SickBeard suddenly started manifesting this. I did have bridge mode configured, and changed to host mode, and I appear fine (though I have not rebooted again to see what happens).

 

Does this scenario match your assumptions? I don't see how in my scenario the resolv.conf would fall out of alignment.

[BRiT]

re: docker dns issue: Here is what we think is happening based on all the evidence and lots of testing:

 

With regard to dns, docker seems to operate in 1 of 2 modes:

Mode 1 = a --dns option is given, either on docker command line, OR in run command of a specific container

Mode 2 = no --dns option is given either when starting docker or initial run of a container.

 

Mode 1 seems to be bullet-proof, assuming you specify a valid name server IP address in the --dns option.

 

Mode 2 is how we operate by default.  Here’s our findings.  Upon docker initial run of a container, the /etc/resolv.conf of the container is established by looking at the contents of /etc/resolv.conf on host, and the container runs correctly.  Later, say after a reboot or array stop/start (where docker daemon is restarted), if the /etc/resolv.conf of the host no longer EXACTLY matches the /etc/resolv.conf of the container, well we see this 'dns' issue in various manifestations.  Our 'best guess' is that there's a bug in how docker handles this case [all expletives have been redacted].

 

Bottom line is this: we'll be generating a rc6a or maybe rc7 that will remove the code that tries to trigger docker's 'inotify watch' (it's this code in docker that we think is fubar'ed).  In addition we'll add a field to Docker Settings page that lets you add “additional options” which will be appended to DOCKER_OPTS taken from docker.cfg.  This way you can add the –dns=<ipaddr> of your nameserver(s) – not ideal but, makes it work.

 

Alternately you can put the option on each container.

 

Or you can leave as-is, as long as your resolv.conf is static, should work.

 

So, my question would be this:

 

I have a static IP address on UnRAID and have Active Directory running, so have my UnRAID point to it for DNS. It's been the same DNS servers for longer than I've had UnRaid, which is 3-4 years now. My resolv.conf wouldn't have changed in all this time.

 

I have not had any of these DNS issues until RC6 where SickBeard suddenly started manifesting this. I did have bridge mode configured, and changed to host mode, and I appear fine (though I have not rebooted again to see what happens).

 

Does this scenario match your assumptions? I don't see how in my scenario the resolv.conf would fall out of alignment.

 

Your /etc/resolv.conf gets auto-generated on each and every boot up. The default /etc/resolv.conf is a 0 bytes file. So until unRAID sets up networking, it was always possible for Docker to start with no entries in the mapped resolv.conf, which would go into a special situation where it would use default values which happen to be Google DNS entires (8.8.8.8 and 8.8.4.4).

 

What was changed in RC6 is when /etc/resolv.conf gets updated on the host when networking is started up, unRAID would trigger the Docker Notify code to let it now the file and DNS settings had changed. There seems to be a bug in that code [Docker's code to be specific], which is causing an issue for more users than it's solving the issue for.

[CHBMB]

Thanks BRiT now I get it.  As well as someone like me can get it anyways...

[danioj]

Thanks BRiT now I get it.  As well as someone like me can get it anyways...

 

Me too. Glad I stayed with RC4 at the moment.

[CHBMB]

After a reboot instead of edit/save, if you type:

 

docker restart <container>

 

Does it then work?

 

Yep, docker restart sorts the problem for me,

 

What's the significance of that?  And why does restarting a container fix it, but restarting the docker service doesn't?

 

EDIT: Actually going back and reading the various explanations I think I understand why, wouldn't be able to explain it to anyone else though!

 

EDIT2: I have the DNS addition in my docker.cfg so that doesn't work for everyone.

 

DOCKER_OPTS="--storage-driver=btrfs --dns=8.8.8.8"
DOCKER_IMAGE_FILE="/mnt/disks/virtualisation/docker.img"
DOCKER_IMAGE_SIZE="20"
DOCKER_ENABLED="yes"

[bkastner]

Your /etc/resolv.conf gets auto-generated on each and every boot up. The default /etc/resolv.conf is a 0 bytes file. So until unRAID sets up networking, it was always possible for Docker to start with no entries in the mapped resolv.conf, which would go into a special situation where it would use default values which happen to be Google DNS entires (8.8.8.8 and 8.8.4.4).

 

What was changed in RC6 is when /etc/resolv.conf gets updated on the host when networking is started up, unRAID would trigger the Docker Notify code to let it now the file and DNS settings had changed. There seems to be a bug in that code [Docker's code to be specific], which is causing an issue for more users than it's solving the issue for.

 

Thanks for that clarification. It makes sense and was not how I was interpreting things, so I appreciate you spelling it out.

[BRiT]

After a reboot instead of edit/save, if you type:

 

docker restart <container>

 

Does it then work?

 

Yep, docker restart sorts the problem for me,

 

What's the significance of that?  And why does restarting a container fix it, but restarting the docker service doesn't?

 

EDIT: Actually going back and reading the various explanations I think I understand why, wouldn't be able to explain it to anyone else though!

 

EDIT2: I have the DNS addition in my docker.cfg so that doesn't work for everyone.

 

DOCKER_OPTS="--storage-driver=btrfs --dns=8.8.8.8"
DOCKER_IMAGE_FILE="/mnt/disks/virtualisation/docker.img"
DOCKER_IMAGE_SIZE="20"
DOCKER_ENABLED="yes"

 

Now this is my guess here, but the DOCKER_OPTS solution will work for everyone, but only after the call to buggy Docker Notify code is removed.

 

When the host's networking is brought up, the /etc/resolv.conf file is modified, unRAID does an explicit step to trigger Docker's notify events that should handle this. However, there seems to be some bugs in this Docker code, and when it's trigger it's essentially undoing what the '--dns' option does. Hence, why it doesn't work for everyone when it exactly should.

[Frank1940]

As a piece of information to those who are a bit confused about the '--dns=8.8.8.8'  option.  Hopefully, everyone understand that the 8.8.8.8 is an IP address of a DNS server out on the Internet.  In fact, it happens to be the one of  the two public DNS  servers that google.com provides.  (The other one has an IP address of 8.8.4.4)  You can actually use any DNS server that you want.  There is nothing magical about the 8.8.8.8 address! 

 

There have been a number of folks who express some concern over using this service provided by Google.  I can understand some of their concerns as many of you may be located outside of NA and the ping times may be excessive for you. 

 

However, you can use ANY DNS Server's IP address.  All you have to do is find one.  You should be able to get the addresses for the DNS server that your ISP provider recommends by looking on their website.  I am on Time Warner cable and I went looking for it.  And I can tell you, they have hid it quite well!  I ended up googling for it and the search yielded a post in a thread on the user forum.  You could also call your provider's Tech support line and someone there should be able to give the address.  There should be two of them.  One is primary and the second one is a backup in case the first one is unavailable. 

[sparklyballs]

As a piece of information to those who are a bit confused about the '--dns=8.8.8.8'  option.  Hopefully, everyone understand that the 8.8.8.8 is an IP address of a DNS server out on the Internet.  In fact, it happens to be the one of  the two public DNS  servers that google.com provides.  (The other one has an IP address of 8.8.4.4)  You can actually use any DNS server that you want.  There is nothing magical about the 8.8.8.8 address! 

 

There have been a number of folks who express some concern over using this service provided by Google.  I can understand some of their concerns as many of you may be located outside of NA and the ping times may be excessive for you. 

 

However, you can use ANY DNS Server's IP address.  All you have to do is find one.  You should be able to get the addresses for the DNS server that your ISP provider recommends by looking on their website.  I am on Time Warner cable and I went looking for it.  And I can tell you, they have hid it quite well!  I ended up googling for it and the search yielded a post in a thread on the user forum.  You could also call your provider's Tech support line and someone there should be able to give the address.  There should be two of them.  One is primary and the second one is a backup in case the first one is unavailable.

 

or you can use the ip of your router and let it sort out where the DNS is.......

[BRiT]

The other IP you could use is your internet router if you enable the DNS feature.

 

I have my router setup for dhcp and dns, so all my local network devices use it, 10.0.0.128. I then have my router configured to usethe DNS servers of my choice. I find this much easier to manage at 1 location than at each individual device level.

[Frank1940]

The other IP you could use is your internet router if you enable the DNS feature.

 

I have my router setup for dhcp and dns, so all my local network devices use it, 10.0.0.128. I then have my router configured to usethe DNS servers of my choice. I find this much easier to manage at 1 location than at each individual device level.

 

And

 

or you can use the ip of your router and let it sort out where the DNS is.......

 

Another great suggestion.  That will get the addresses that your ISP is using.  The biggest issue is finding the IP address of your router.  Each manufacturer has a default address and you have to know what it is.  Looking in the manual will usually tell you.  It should be the address that you use to access your router to change its settings.  (At least, that is what it has always been on the CHEAP home routers that I have used!)   

[bkastner]

The other IP you could use is your internet router if you enable the DNS feature.

 

I have my router setup for dhcp and dns, so all my local network devices use it, 10.0.0.128. I then have my router configured to usethe DNS servers of my choice. I find this much easier to manage at 1 location than at each individual device level.

 

And

 

or you can use the ip of your router and let it sort out where the DNS is.......

 

Another great suggestion.  That will get the addresses that your ISP is using.  The biggest issue is finding the IP address of your router.  Each manufacturer has a default address and you have to know what it is.  Looking in the manual will usually tell you.  It should be the address that you use to access your router to change its settings.  (At least, that is what it has always been on the CHEAP home routers that I have used!)   

 

That should be pretty easy to determine though, shouldn't it? Just go to a DOS prompt on a Windows machine and type 'ipconfig /all' it will show you your gateway address, which will be the router. If it isn't for some reason, then you likely have something highly tailored in your environment, and likely don't need the help to begin with.

[trurl]

The other IP you could use is your internet router if you enable the DNS feature.

 

I have my router setup for dhcp and dns, so all my local network devices use it, 10.0.0.128. I then have my router configured to usethe DNS servers of my choice. I find this much easier to manage at 1 location than at each individual device level.

 

And

 

or you can use the ip of your router and let it sort out where the DNS is.......

 

Another great suggestion.  That will get the addresses that your ISP is using.  The biggest issue is finding the IP address of your router.  Each manufacturer has a default address and you have to know what it is.  Looking in the manual will usually tell you.  It should be the address that you use to access your router to change its settings.  (At least, that is what it has always been on the CHEAP home routers that I have used!)   

 

That should be pretty easy to determine though, shouldn't it? Just go to a DOS prompt on a Windows machine and type 'ipconfig /all' it will show you your gateway address, which will be the router. If it isn't for some reason, then you likely have something highly tailored in your environment, and likely don't need the help to begin with.

Everyone discussing this can certainly handle it just fine. I am concerned about support of other users though. There have been many times a user says the webGUI isn't working and the actual problem is something about their network and they have no clue how to diagnose themselves.

[garycase]

.. Everyone discussing this can certainly handle it just fine. I am concerned about support of other users though. There have been many times a user says the webGUI isn't working and the actual problem is something about their network and they have no clue how to diagnose themselves.

 

Agree.  The vast majority of the active participants in these discussions are very knowledgeable folks who really don't need much (if any) help handling these issues.  But once the release is designated as "Stable" there will likely be a number of folks who decide to move to v6 who won't be nearly as comfortable with these issues.  And once folks move to v6 there will be a large increase in the number of Docker users, which could notably increase the number of posts r.e. this issue.

 

RC6 certainly seems "good enough" to be v6.0 at this point ... certainly as a NAS with far better features than the previous versions (notifications and UPS support are key enhancements).    But clearly it'd be nicer if the Docker issue was resolved with the actual release instead of being a footnote in the release notes.  It's clearly still an issue -- as evidenced by 12 pages in this thread only one day after RC6 was released.  I don't know if Eric has a full head of hair or not, but if so he'll likely be as bald as JonP when he gets done with this issue    [i wonder if JonP had a full head of hair when he started working on v6  ]

 

 

[Frank1940]

The other IP you could use is your internet router if you enable the DNS feature.

 

I have my router setup for dhcp and dns, so all my local network devices use it, 10.0.0.128. I then have my router configured to usethe DNS servers of my choice. I find this much easier to manage at 1 location than at each individual device level.

 

And

 

or you can use the ip of your router and let it sort out where the DNS is.......

 

Another great suggestion.  That will get the addresses that your ISP is using.  The biggest issue is finding the IP address of your router.  Each manufacturer has a default address and you have to know what it is.  Looking in the manual will usually tell you.  It should be the address that you use to access your router to change its settings.  (At least, that is what it has always been on the CHEAP home routers that I have used!)   

 

That should be pretty easy to determine though, shouldn't it? Just go to a DOS prompt on a Windows machine and type 'ipconfig /all' it will show you your gateway address, which will be the router. If it isn't for some reason, then you likely have something highly tailored in your environment, and likely don't need the help to begin with.

Everyone discussing this can certainly handle it just fine. I am concerned about support of other users though. There have been many times a user says the webGUI isn't working and the actual problem is something about their network and they have no clue how to diagnose themselves.

 

You are absolutely correct!!!  But, hopefully, someone is putting together a set of instructions on how to setup Dockers on a server will look over these suggestions and incorporate the various options into that instruction set so that the user can decide which IP address scheme he would like to use and how to implement that choice. 

[RobJ]

Everyone discussing this can certainly handle it just fine. I am concerned about support of other users though. There have been many times a user says the webGUI isn't working and the actual problem is something about their network and they have no clue how to diagnose themselves.

 

A nice segue to letting me express my appreciation to bonienl for the added information in the Diagnostics zip file.  He's added Docker and VM logs and related files in the logs and qemu folders, and system and network info in the system folder.  Very useful!

[trurl]

... the various options...

I haven't upgraded yet because I have been preclearing and now upsizing a data disk.

 

Since I have never experienced the issue, I'm not sure I really understand what the various options are. It would be best if we could just have one solution. Is the docker.cfg file the solution we are going with or what?

[CHBMB]

... the various options...

I haven't upgraded yet because I have been preclearing and now upsizing a data disk.

 

Since I have never experienced the issue, I'm not sure I really understand what the various options are. It would be best if we could just have one solution. Is the docker.cfg file the solution we are going with or what?

 

That isn't always a perfect solution trurl, for instance, it doesn't work for everyone, Sparklyballs and myself being case in point.  Tom has stated there will be a RC6a or RC7 and in all honesty, if I were you, I'd probably wait for that.

[BRiT]

... the various options...

I haven't upgraded yet because I have been preclearing and now upsizing a data disk.

 

Since I have never experienced the issue, I'm not sure I really understand what the various options are. It would be best if we could just have one solution. Is the docker.cfg file the solution we are going with or what?

 

That isn't always a perfect solution trurl, for instance, it doesn't work for everyone, Sparklyballs and myself being case in point.  Tom has stated there will be a RC6a or RC7 and in all honesty, if I were you, I'd probably wait for that.

 

I think it does work for everyone but the other docker behavior is ruining it. So you have to stop that other behavior. 

[eschultz]

... the various options...

I haven't upgraded yet because I have been preclearing and now upsizing a data disk.

 

Since I have never experienced the issue, I'm not sure I really understand what the various options are. It would be best if we could just have one solution. Is the docker.cfg file the solution we are going with or what?

 

That isn't always a perfect solution trurl, for instance, it doesn't work for everyone, Sparklyballs and myself being case in point.  Tom has stated there will be a RC6a or RC7 and in all honesty, if I were you, I'd probably wait for that.

It might be a simple permission issue at this point.  If you take out all your --dns parameters and just run this from the console/shell once to fix permissions:

 

find /var/lib/docker/containers/ -name resolv.conf -maxdepth 2 -exec chmod 644 {} +

 

Restart Docker or stop/start array after this.