After some time, all docker containers lose config some will not boot


Recommended Posts

Been having this issue for a week now and I just got around to posting about it.  My workaround has been to just re-install them all and re-configure and I am a PRO at it now.  :P  (Obviously not if I am having what I believe to be a config issue somewhere on my part.) 

 

Here is a screenshot of the overall status with two in red that I need to re-install because they will not launch:

 

http://puu.sh/gnvjr/b38c288cd3.png

 

Screenshot of the log from CP (pretty short):

http://puu.sh/gnvli/c5547b67e5.png

 

Please let me know what data you would like for me to fetch in order to help me troubleshoot this issue.  I appreciate your time!

Link to comment

Just curious if you are passing through network mounted shares on the host volume paths (you've mounted a share on unRaid that exists on another computer).

 

I do that, and if the network shares are not mounted, then I get similar results - Just have to remount the shares and restart the containers however.

 

 

Link to comment

Just curious if you are passing through network mounted shares on the host volume paths (you've mounted a share on unRaid that exists on another computer).

 

I do that, and if the network shares are not mounted, then I get similar results - Just have to remount the shares and restart the containers however.

 

I don't think I am, Squid.  I use the cache drive to store my configuration /config and I have /tv and /movies as mount points for the containers which translate to /mnt/user/main/shows and /mnt/user/main/movies.  I am using host networking for all of them.

Link to comment

Just a guess but is the mover script moving your docker data from the cache drive to the main array, preventing the Dockers from finding their data in the expected location? I had this problem until I found the 'cache only' setting on the shares page.

 

VnRNz

 

I am not using the cache disk except for storing my config on the docker containers.  IE: /config on CouchPotato is mapping to /mnt/cache/couchpotato.

Link to comment

But is the couchpotato share set to CACHE ONLY?

 

I am going to check to see if I can figure out what you are talking about.  I did notice that when I put directories in my cache drive (ie: /mnt/cache/couchpotato) it also creates one out on /mnt/user/couchpotato.  I thought that was odd but maybe that is expected behavior. 

 

I just checked the share for couchpotato and it is set to No for use cache drive.  I want to keep the configuration files of the docker apps on my cache drive because it is a SSD.  I also uncompress the files there.  I hope I am making sense.  Here is a screenshot of the share configuration:

 

http://puu.sh/gnzJ7/75614d8554.png

Link to comment

Does your config directory for CouchPotato on your cache drive e.g /mnt/cache/couchpotato exist in /mnt/user0 <-note the zero ?

 

If it does then your config files are being moved there by the mover script each night at 3am or whatever time you have it set it to.

 

To prevent this behaviour, and keep your couchpotato config directory on the cache drive you need to set it's share to 'cache only'.

Link to comment

Does your config directory for CouchPotato on your cache drive e.g /mnt/cache/couchpotato exist in /mnt/user0 <-note the zero ?

 

If it does then your config files are being moved there by the mover script each night at 3am or whatever time you have it set it to.

 

To prevent this behaviour, and keep your couchpotato config directory on the cache drive you need to set it's share to 'cache only'.

 

Thanks.  I just went in to all of them (couchpotato,nzbdrone,nzbget,plexmediaserver) and set the share to "Use cache disk: Only".  What is odd to me is that I had it set to "None" before.  Does that still move the config files at 3am?  I would think not.

Link to comment

Does your config directory for CouchPotato on your cache drive e.g /mnt/cache/couchpotato exist in /mnt/user0 <-note the zero ?

 

If it does then your config files are being moved there by the mover script each night at 3am or whatever time you have it set it to.

 

To prevent this behaviour, and keep your couchpotato config directory on the cache drive you need to set it's share to 'cache only'.

 

Thanks.  I just went in to all of them (couchpotato,nzbdrone,nzbget,plexmediaserver) and set the share to "Use cache disk: Only".  What is odd to me is that I had it set to "None" before.  Does that still move the config files at 3am?  I would think not.

It moves anything on the cache drive that is not set to cache-only. You should also go to each of your other disks and delete the folders that got moved there by mistake. If you go to the Shares page, you will see the folders that unRAID considers shares. Click on the "Compute" link for each share to see all of the disks the share is on. It will also show how much space the share is using on each disk. You may have to wait a little while for it to do the "Compute".
Link to comment

Now that I am going back through and setting everything back up.  I don't want the mover to kick in at 3:40am tomorrow morning.  I don't see the shares out there anymore.  How can I "head it off at the pass" so that none of my configuration files get moved out of /mnt/cache/<application> ?

 

Link to comment

Now that I am going back through and setting everything back up.  I don't want the mover to kick in at 3:40am tomorrow morning.  I don't see the shares out there anymore.  How can I "head it off at the pass" so that none of my configuration files get moved out of /mnt/cache/<application> ?

Any folder at the top level of cache or an array drive is automatically a user share. Instead of having a separate user share for each application, what is usually done is to create a user share, name it something like appdata, and set it to cache-only. Then you put your application configurations in /mnt/cache/appdata/<application>. If you will do it this way it will be much easier for you going forward. Then you will not have to worry about each application getting moved, because you will already have it set up so none of them get moved.

 

Also, the docker templates are generally setup this way anyway and if you insist on doing it differently you will just be making it more difficult for yourself.

 

I would tell you how to control the mover schedule, but you can find that in the webGUI if you look, and that is not really the correct way to address your problem anyway.

Link to comment

Now that I am going back through and setting everything back up.  I don't want the mover to kick in at 3:40am tomorrow morning.  I don't see the shares out there anymore.  How can I "head it off at the pass" so that none of my configuration files get moved out of /mnt/cache/<application> ?

Any folder at the top level of cache or an array drive is automatically a user share. Instead of having a separate user share for each application, what is usually done is to create a user share, name it something like appdata, and set it to cache-only. Then you put your application configurations in /mnt/cache/appdata/<application>. If you will do it this way it will be much easier for you going forward. Then you will not have to worry about each application getting moved, because you will already have it set up so none of them get moved.

 

Also, the docker templates are generally setup this way anyway and if you insist on doing it differently you will just be making it more difficult for yourself.

 

I would tell you how to control the mover schedule, but you can find that in the webGUI if you look, and that is not really the correct way to address your problem anyway.

 

I don't mind doing it that way but my end goal was to take advantage of my SSD that is used as my cache drive.  I am using it specifically for speed with uncompressing downloads.  If I change everything like you just mentioned, will I still be taking advantage of the SSD speed?  It sounds like that is correct.

Link to comment

I don't mind doing it that way but my end goal was to take advantage of my SSD that is used as my cache drive.  I am using it specifically for speed with uncompressing downloads.  If I change everything like you just mentioned, will I still be taking advantage of the SSD speed?  It sounds like that is correct.

Where your docker stores the things it downloads should be independent of where it keeps its configuration. Both of these things can be on your SSD though, so yes.
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.