Jump to content
JMacGill

Docker image file needs to be recreated due to an issue from a BETA?

10 posts in this topic Last Reply

Recommended Posts

Hello, this is my first post. I just bought unRAID exactly two weeks ago on the 14th and finally finished setting up my server hardware. I ran into a few problems and learned a few things but I was able to figure them out by using Google. My current problem is not unsolvable. I already found the topic covering it here http://lime-technology.com/forum/index.php?topic=38323.0.

 

What I would like to know is why this happened. I just bought, installed, and setup unRAID and in that time there was one update the very day after I bought my key. I never ever installed a BETA version of unRAID yet I'm getting this error at the top of my docker page:

 

Your existing Docker image file needs to be recreated due to an issue from an earlier beta of unRAID 6. Failure to do so may result in your docker image suffering corruption at a later time. Please do this NOW!

 

Why am I getting an error from a BETA that I never had? From some early Googling it looks like the error comes from moving the Docker image between the cache to the array, which I did do while upgrading my cache disks to larger sized SSDs. I turned off all my Docker containers before doing the move and restored the image to the cache before turning the containers back on but I see now that I did forget to turn off Docker before moving the image file. Would that have prevented this problem?

 

Also, if this was a problem in an earlier BETA version wouldn't it have been fixed before releasing a final version of the OS to the public. And if not then wouldn't this issue not be from an earlier BETA but from the very version of unRAID that I have installed?

Share this post


Link to post

Yeah I can't imagine moving the docker.img whilst the service was running would do it any good at all....

 

I suspect the error message was put in due to an event that could occur with a previous beta and you've just managed to recreate those conditions manually.

 

Go to settings then docker, turn off the docker service, then delete the existing docker.img.  Recreate it by specifying the size and location then restart the service.  You'll need to repull any containers but that's a quick easy job by going in the docker tab and selecting my-someapp.xml in the dropdown menu and clicking add as long as you haven't moved the appdata it should just work again.

Share this post


Link to post

I deleted the docker.img file and restarted docker, re-installed crashplanpro (the only container i'm trying to run). Same result, It won't start the crashplanengine unless the /mnt/user/appdata/CrashPlanPRO folder is removed and a new setup is completed, after which if the container is re-started it loops this message in the log: [CrashPlanEngine] starting...

Share this post


Link to post
I deleted the docker.img file and restarted docker, re-installed crashplanpro (the only container i'm trying to run). Same result, It won't start the crashplanengine unless the /mnt/user/appdata/CrashPlanPRO folder is removed and a new setup is completed, after which if the container is re-started it loops this message in the log: [CrashPlanEngine] starting...
Think you got the wrong thread

Share this post


Link to post

It is - in fact checking for the C or NOCOW flag. The problem is that you can't set the NOCOW flag for a file larger than 0 bytes. That is - already containing data. You can only set it for newly created 0 byte files which have not yet been written to. There is a workaround though:

 

1) Move your docker.img to a safe location on a different device.

2) Make sure the "live" image /mnt/cache/system/docker/docker.img is removed and that you only have an empty docker folder.

2) chattr +C /mnt/cache/system/docker (Yes, the folder, not the file). By setting the C or NOCOW flag on the folder, it will apply to all files inside of it!

3) Move your docker.img back to the btrfs filesystem. It will now have the C or NOCOW flag set because the flag is set on the folder, and you didn't lose any data!

Share this post


Link to post
1 hour ago, maciekish said:

3) Move your docker.img back to the btrfs filesystem. It will now have the C or NOCOW flag set because the flag is set on the folder, and you didn't lose any data!

If there is data stored in your docker image file, you are doing it wrong. A properly set up system can automatically recreate a working docker image file from nothing in a matter of a few minutes, depending on the speed of your internet connection.

Share this post


Link to post
16 minutes ago, jonathanm said:

If there is data stored in your docker image file, you are doing it wrong. A properly set up system can automatically recreate a working docker image file from nothing in a matter of a few minutes, depending on the speed of your internet connection.

Won’t recreating the image remove all dockers and force you to redownload the images and reconfigure them? Sure appdata wont be lost but if you have 20+ dockers this takes a lot longer than just copying the file twice?

 

Also my method doesn't introduce any issues does it?

Edited by maciekish

Share this post


Link to post
7 minutes ago, maciekish said:

Won’t recreating the image remove all dockers and force you to redownload the images and reconfigure them?

Apps tab, show previous apps, check off the ones you want and select install all. No reconfiguration necessary. Only takes a couple clicks and you are done, automated download and set up exactly as they were.

Share this post


Link to post
16 hours ago, jonathanm said:

Apps tab, show previous apps, check off the ones you want and select install all. No reconfiguration necessary. Only takes a couple clicks and you are done, automated download and set up exactly as they were.

Interesting, i thought you would have to reenter all shared folders, ip adresses and so on. Either way, moving back the original file with COW disabled won't hurt will it?

Share this post


Link to post

I figured I'd post my results here since this is the first result in google to come up for this issue.

 

If you have used "Community Applications" to install docker containers (ie: the Apps tab), it is safe to remove the docker image file.

 

After you have deleted the docker image file and create a new one and start your docker service back up, you can head back to the Apps tab and click on the list icon in the top-left to go to previous installed apps as jonathanm explains.

 

When these are installed, all settings as you had previously configured your containers will be restored. The only thing you may have to fix are custom made docker networks and properly configure the autostart for your containers, as these will all be turned on by default.

Other then that, you lose absolutely nothing.

EDIT:  Worth noting, it looks like it doesn't use the "Post Arguments" when building the container. For these to be applied you will have to edit the container, and just press "apply" again.

Edited by xorinzor

Share this post


Link to post

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.