(Solved) unRaid 6: Lost dockers/vm's on reboot


Recommended Posts

My search foo isn't working this morning - seems like more an general config issue then docker specific - but feel free to move if it better belongs there. Posted over on r/unRaid, but figured I should ask the experts here as I didn't get any definitive answers.

 

Powered down (via the UI) and physically moved the box yesterday. On power-up, the sab, CP, radarr dockers, and ubuntu are no longer in the dashboard/docker/vm menu's (but a couple unifi, plex, emby remained), parity check ran and completed without error. Unraid 6.6.6, with all disks using encryption.

 

What happened?

 

 

Background/setup; Recently started using unRaid after a trial - and what I did was similar to the following - I can't remember the exact order of operations, but this is pretty close if my memory is accurate:

1) moved data from the windows box via network across 3 data drives,

2) next setup the unifi docker (which remained)

3) setup sab/CP/radarr dockers (this might have been after # - they all disappeared 4)

4) added the parity drive, let it calculate,

5) set up some the remaining dockers (syncthing, dupeguru, and a couple others - all of these disappeared too), and an ubuntu vm (this might have been after #6)

6) then added a 120g cache

 

I have a feeling it has to do with the order of setting them up, and the cache drive - I can browse the cache drive and see the docker folders there, why aren't they showing in the UI/where do I need to look to fix it?

 

I think it might be relevant: (they've been set this way for at least a few days before the reboot - but might not have been that way initially)

the \system share is set to high-water, auto split top level only, all disks included, no excluded disks, use cache=prefer

the \appdata share is set to high-water, auto split top level only, all disks included, no excluded disks, use cache=prefer

Link to comment

I don't see any obvious reason for your reported problems, but there are some things you should take care of since you added cache last. Your life would have been a lot less complicated if you had installed cache before enabling dockers and VMs. That way things that belong on cache would have been created there. As it is, you have some things that need to be moved.


Cache may be too small to do much if any caching of any user shares except those "system" shares that should live on cache (appdata, domains, system) for use by the docker and vm services. You have those shares already set to cache prefer, but they have contents on the array that should be moved to cache. You also have some other shares set as cache-prefer. Are you sure that is what you want?

 

Cache-prefer means try to keep everything on cache, and if it overflows to the array, move it back to cache. This is the usual setting for those "system" shares I mentioned, but typically other shares should be set cache-no or cache-yes. Cache-yes means write to cache but move to array. With that small cache, you should be very careful about caching anything other than those "system" shares.

 

Mover won't move any open files, so you would have to disable the Docker and VN services in Settings before it could move those "system" shares to cache.

 

All of this should be taken care of, but it isn't clear that any of this would actually address your problems.

 

Not sure what to do about the VMs, but for the dockers, I would just delete docker image, recreate it (and it would be recreated on cache since you have one now), and reinstall your dockers using Previous Apps on the Apps page.

 

I will write a step-by-step for all this.

 

Link to comment

Thanks for the reply trurl.

 

I read somewhere that adding the cache last would make moving things over a bit faster. But in hindsight it really makes sense - so for anyone else reading this, move things over, then add the cache, then lastly the dockers/vm's.

 

Went back through some of the shares, and changed most of them to cache=no, left the incoming/processing ones as preferred. (my thinking is that they are temp files, and don't really need the parity protection.)

 

So thought I'd dig in, shut down the two running dockers, went to settings --> docker --> enable docker, changed to No. Apply/done.

 

Launched an ssh through putty, opened up midnight commander (MC), then consolidated the systems folders you mentioned above, off the spinning drivers and onto the cache. While I was in there also consolidated a couple of user shares too (which were split due to the order that I added drives initially.)

 

Back to settings --> docker --> enable docker, changed to Yes. Apply/done. Reboot. Entered encryption key, and all of the dockers came up automatically on the boot. (was ready to use the previous apps, but didn't need to.)

 

Edit: This approach mucked up the ubuntu vm, reset the vm through the gui - settings --> vm manager --> changed enable vm's = No, deleted the Libvirt file (via checkbox). Re-enabled, and we are working again. 

 

Running through the fix common problems on the CA, it found a couple of things that should have been changed too - I appreciate the help today, thanks!

Edited by seestray
Link to comment
  • seestray changed the title to (Solved) unRaid 6: Lost dockers/vm's on reboot

Great to see you worked this out for yourself. Another way to get things moved to/from cache is to use Mover with the appropriate use cache setting for each user share. That setting is a source of confusion for many, and has some nuances that may not be obvious on first reading of the Help on the page. Here is a more detailed analysis:

 

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?page=2#comment-537383

 

Many new users are not able to work with the command line or even mc as you did so I usually go the Mover route when helping them with this.

 

9 hours ago, seestray said:

adding the cache last would make moving things over a bit faster.

There are a couple of things that you may have seen about that:

  • Adding parity after the initial data load is done will make that faster, since parity slows down writes to the array.
  • Caching user shares during the initial data load often just gets in the way because cache doesn't have the capacity.

But adding cache before enabling Dockers and VMs will create those things on cache where they belong.

 

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.