KluthR

No one? @mgutt Do you have any ideas/experience in that case?

Ive released a small update which fixes the Abort button and accepts the "error" "Container already started" as ok. IN THAT case, the plugin logs two lines of JSON formatted debug information. I ask all users, having those "Already started" issue: Please post the backup log, including those 2 debug informations. As said: I dont really understand what is going on - example @blaine07: One container did stopped and while starting, it outputs "Already started" - so, either docker dont telling me the truth about stopping the container initially or something is starting the container in between again. We will see.

Wow. Many containers 😅 however: which ones are not running? Some are not started because they are already (do you habe auto docker update enabled?) which will be catched next update. and no: nothing confidential in those logs.

Already on the todo list 👍

You set all containers to „dont stop“? You can use the tar but the error comes from the fact that you backing up files which are still being accessed. A consistent backup requires a temporary container stop

I did. And he asked if I not just copy it and release it myself since he dont have time anymore for it. I agreed to take over the ownership with my dev profile which makes a reinstall mandatory. Currently known issues: * Cancelling is not working * If AutoUpdate of docker is active, the plugin outputs „xxx already started“ messages sometimes from docker and treats it like an error currently Thats all (did I forgot something?) Some are facing some tar messages „Contents differ“ which I still need to clarify. But mostly this applies: If you see errors within the new plugin it most likely had the issues before, because I check now results of every docker and tar action which was ignored before. I create a new thread soon for better tracking.

it was. Just hidden. Read the changelog. I dont make useless improvements. the next fee days I will take a closer look onto all issues. The docker stop/start related still give me headache bit Ill see. Yes! remove the current one and install this plg: https://raw.githubusercontent.com/Squidly271/ca.backup2/master/plugins/ca.backup2.plg (Dont bother the deprecated version warning) If you feel ready, you can always switch forward again.

What the…? [20.12.2022 06:00:50] Stopping unifi-controller... Error while stopping container! Code: Container already started It states: Container already started? When we stop it? Thats weird. Are you able to stop the container manually via docker overview?

Not sure, to be honest. I cant say what is causing the access. You already can disable verification afaik.

Thats not that simple to catch, since these messages come directly from tar. I could add an option to ignore verification errors (just log them but treat backup as successful)

Anything else that might access those plex paths? Something seem to access ot while backing up.

Will do that tomorrow.

No, I assume something is modifying things inside this plex folders. „Contents differ“ clearly states: the file changed between first saving and the recheck done later. Is Plex really shit down? I see „Not started“ messages in the log. It says plex was stopped 2 days ago?

Hi I have two IPv6 enabled containers. They are fixed. I initially entered the prefix noted next to the br0 static IP field and added my own suffix. That worked. Until today. I restarted unraud and noticed those 2 containers were down. Starting them resulsts into a 403. Starting via CLI shows an "Address already in use" error. After some minutes, I realized, that my prefix changed and did not match the container fixed IPv6 anymore. Question 1: Any idea how to only set the host address for the v6 for cotainers? Without need to change the prefix anymore (if it changes?). Correcting the IP did not brought the 2 cotainers back to life. I dont have any idea whats going on: docker start npm Error response from daemon: Address already in use Error: failed to start containers: npm But the addresses arent in use: ss -tulpn doesnt show anything. Question 2: How to get further? Any ideas how to bring my containers back to life? I already deleted the container and image - no change. Thanks in advance! nas-diagnostics-20221219-2120.zip

This isn’t true. The @KluthR version is not deprecated. I assume this is meant to be for the unraid version.

Maybe you're right. But in my opinion, a new thread would be sufficient. The main plugin is still the same, with some enhancements. No rewrite. Thats the reason the name did not changed. Idk whats the best option here, but starting a new thread with me as author, would also give me higher permissions for the thread itself - could be useful. No, not really. The Abort button is not working, yes - will be fixed - but the main part is still working. The problems encoutered come from the fixed tar error detection and/or the new check, if the container were stopped/satrted correctly. The old plugin did not mentioned those issues.

Ahh! Okay, that could be because you enabled auto update. Maybe it starts the containers. Your logs confirm my thoughts: Dec 18 06:02:24 Tower Docker Auto Update: Restarting Home-Assistant-Core Dec 18 06:02:25 Tower Docker Auto Update: Community Applications Docker Autoupdate finished So, I have to catch that case.

Oh, you can safely leave it turned on, the behavior should be the same. Theres just the new error which was silently discarded before.

Ahh! Okay, that could be because you enabled auto update. Maybe it starts the containers. the reason for the error then: squids version started containers without checking for success. I implemented checking and now the silent warning is being brought to attention. I should cover that case.

Do you both have IPv6 enabled? Please post your diagnostics. as said: the plugin just asks docker to start the specific container. I had issues with squids version: 3 specific containers wont run randomly. I changed the method for starting the containers to use the unraid style, that fixed my issue. Together with some waiting and the new „3 tries“ method I never had any issues. And yes: Stopping backup is currently broken and will be repaired soon. please post your backup logs and diagnostics.

No. This would need a 2nd complete configuration, if I got you right (which stops/start different containers etc). Thats not supported.

I dont think so. I ask docker to stop the container, the answer you see (Stopped x months ago) is the answer coming right out of docker. and those containers were running??

Thanks for the log! Your case is very interesting. I never saw the counter uses all 3 tries and still fails 😅 The thing: The plugin is telling docker simply „Start container please“, the rest is up to docker. I would prepare an update which shows more details in case of failure, but it will take a few days, Iam not home rn. I also have issues sometimes while starting containers within the plugin but with latest version (3 tries) it went away. Do you have IPv6 enabled and using for docker containers? EDIT: Could you provide your unraid diagnostics?

Yep, post the complete log please. A single verification error would trigger an error at the end.

Syntax is ok and no, you dont need quotes.