Hi all,

I just started to get this error on a couple of containers and cant figure out why?

Was working fine previously. Have tried to search but couldnt seem to see anything on this error.

Any help would be greatly appreciated

o

Heute (15.08.2026) teste ich die Backup-App.

Soweit scheint sie zu gehen, und axeptiert auch meine Backupordner.

Ich hatte eingestellt das ich keine ZIP haben möchte, leider wurde aber der Flash gezipt :( Wie kann ich dies ausschalten? Beim Dogger hat es geklappt ohne ZIPen.

Today (August 15, 2026), I’m testing the backup app.

It seems to be working so far and accepts my backup folders.

I had set it not to use ZIP compression, but unfortunately, the Flash content was zipped anyway :( How can I turn this off? It worked without zipping on the Dogger.

Flash backup is not handled by the plugin itself, it just calls Unraid's "generate backup" function and that makes a zip.

Hi,

Having the same issue as before again, where Plex won't update because it says the file has changed since it was read.

I can see here that Plex was already running when it tried to load it, but everything is set to stop, backup then start. All in a specific order.

As far as I am aware, this all looks right. Can anyone confirm or suggest a fix?

Maybe change backup type to stop all containers, instead of one at a time?

Thanks!

Flash backup hasn't worked for me since 7.4 beta-1.

This is the last line in the logs (regular and debug):

[07.09.2026 09:28:48][i][Main] Backing up the flash drive.

Beta, so not worth investigating, but thought I'd mention it in case the issue persists.

(I use internal boot but that wasn't a problem with 7.3, worked perfectly.)

Is there some documentation on the skip feature and some of these other ones? Coming from previous version when I had old version of Unraid. I only see "Skip" next to each container, but in the config file I see the following and it has me confused.

"skip": "yes",

"skipBackup": "no",

Advanced options.

22 hours ago, Kilrah said:

Advanced options.

Thanks. So is the regular skip referring to the stopping of the container?

Regular skip completely ignores the container as if it wasn't there.

Gotcha, so any other config of that container would be pointless if you had the regular skip checked. Got it, thanks.

Following up on my post above (18/19 August) - dug into this more and read back through the thread, and I think the answer is clear.

The ~45 min gap between "Backing up plex..." and the tar failure suggests it was slowly working through the whole appdata tree and something inside kept changing while it read it. Plex's Library/Application Support/Plex Media Server/Cache, Media and Metadata folders are huge and churn constantly (thumbnails, transcode temp, background analysis), and can keep being touched for a while even after the container is told to stop - "stopped" doesn't mean every background task quits instantly with a big library. Tar reads recursively, so one of those subfolders changing mid-read triggers "file changed as we read it," and the message just surfaces at the parent directory.

The first post's Hints section already recommends excluding those three folders since they "don't need to be saved" (regenerable cache/thumbnail data, not your actual config or watch history) - so that exclusion should fix it.

One gotcha I found further back in the thread (page 47): a user added that exact exclusion and it silently did nothing, because he'd set the path starting with /mnt/user/... while the backup was actually reading from /mnt/cache/... (or vice versa). The exclusion has to match the real path exactly or it's just ignored - easy to have it look configured but do nothing. Might be worth a note about that in the first post since it seems to trip people up.

Going to add those exclusions with the correct path and see how it goes. Thanks all.

Hi Robin,

I seem to be seeing the container stop issue that has already been reported here a few times.

In my case it occasionally happens with my BOINC container:

Stopping Boinc... Error while stopping container 'Boinc'! Code: - trying 'docker stop' method

That seemed to work.

The backup itself completes successfully afterwards, verification is successful and the container starts again.

I was curious why this happens and did some digging.

A normal manual stop of the container works fine:

time docker stop Boinc

Boinc

real 0m7.176s

My Unraid Docker timeout is set to 90 seconds:

DOCKER_TIMEOUT="90"

I then had a look at what Appdata Backup is doing. It first calls:

$dockerClient->stopContainer($container['Name']);

In Unraid's DockerClient.php this uses the configured DOCKER_TIMEOUT, so in my case it calls the Docker API with a 90 second timeout.

What I found interesting is that getDockerJSON() communicates with /var/run/docker.sock using stream_socket_client().

PHP on my system reports:

default_socket_timeout = 60

In the Appdata Backup log there are about 64 seconds between the initial stop attempt and the fallback message.

After that, Appdata Backup uses:

docker stop Boinc -t 30

and that works.

So I was wondering if this could be related to the PHP socket timing out after 60 seconds while DockerClient is actually waiting for a Docker stop timeout of up to 90 seconds.

I don't know if this is the actual cause, but the 60/90 second difference and the timing in the log looked interesting, so I thought I'd mention it.

Thanks!

Frank

Possible, 90 seconds docker timeout is really long though, should never really need to go past 60 and encounter that. I use 20.

Edited September 22Sep 22 by Kilrah

On 9/19/2026 at 1:06 PM, LFFPicard said:

Following up on my post above (18/19 August) - dug into this more and read back through the thread, and I think the answer is clear.

The ~45 min gap between "Backing up plex..." and the tar failure suggests it was slowly working through the whole appdata tree and something inside kept changing while it read it. Plex's Library/Application Support/Plex Media Server/Cache, Media and Metadata folders are huge and churn constantly (thumbnails, transcode temp, background analysis), and can keep being touched for a while even after the container is told to stop - "stopped" doesn't mean every background task quits instantly with a big library. Tar reads recursively, so one of those subfolders changing mid-read triggers "file changed as we read it," and the message just surfaces at the parent directory.

The first post's Hints section already recommends excluding those three folders since they "don't need to be saved" (regenerable cache/thumbnail data, not your actual config or watch history) - so that exclusion should fix it.

One gotcha I found further back in the thread (page 47): a user added that exact exclusion and it silently did nothing, because he'd set the path starting with /mnt/user/... while the backup was actually reading from /mnt/cache/... (or vice versa). The exclusion has to match the real path exactly or it's just ignored - easy to have it look configured but do nothing. Might be worth a note about that in the first post since it seems to trip people up.

Going to add those exclusions with the correct path and see how it goes. Thanks all.

Did you ever get this figured out; having same issue as you:


I even changed it to just not back up dawarich but it's like AppData backup tool isn't saving my configuration changes, either.

Edited September 25Sep 25 by blaine07

On 9/8/2026 at 5:20 AM, CS01-HS said:

Flash backup hasn't worked for me since 7.4 beta-1.

This is the last line in the logs (regular and debug):

[07.09.2026 09:28:48][i][Main] Backing up the flash drive.

Beta, so not worth investigating, but thought I'd mention it in case the issue persists.

(I use internal boot but that wasn't a problem with 7.3, worked perfectly.)

I am having the same issue, my symptom was that my post-run script never triggered. But the backups folder had stuff in it. Also wasn't getting notifications that the backup had completed. I asked Claude to SSH into my server to see what was going on. Here is what I found:

Every backup run crashes before it gets to deletion

The plugin works in this order: back up the containers, then back up the flash drive, then delete old backups, then run the post-run script. Every run is dying at the flash-drive step, so the last two steps never happen.

• The log stops mid-run. Today's log ends at Backing up the flash drive. with nothing after it.

• The system log shows a crash. It has crond: exit status 255 from ... backup.php at 03:37:26, which is PHP dying.

• The cause is the Unraid 7.4.0‑beta.3 update (installed 24 Sep). Unraid rewrote its built-in flash backup script so it now sends the whole zip as output instead of saving a file and returning its name. The plugin still expects a file name, so it tries to hold the entire ~1.4 GB zip in memory. PHP's memory limit on Nassy is 256 MB, so it runs out and crashes.

• Stop the crash: set "Backup the flash drive?" to No in the plugin settings, or update the plugin once it supports the new Unraid behaviour. Unraid Connect is already backing up your flash drive; the system log shows it queuing flash backup updates today.

I have sumbitted a support ticket to Unraid today sharing the same so they are aware of it. Posting here in case it helps the Plugin Developer.

Sharing in case this helps anyone else who runs into this issue :)

I did not expect a change for this until Unraid 8. However, I cant build a fix since I dont have any Unraid instance here. If someone can provide a PR I could release a small update.

The plugin is obsolete anyways. I dont add new things and since Unraid 8 brings new plugin and backup system the plugin will not be available for Unraid 8 at all.

On 9/27/2026 at 8:55 PM, KluthR said:

I did not expect a change for this until Unraid 8. However, I cant build a fix since I dont have any Unraid instance here. If someone can provide a PR I could release a small update.

The plugin is obsolete anyways. I dont add new things and since Unraid 8 brings new plugin and backup system the plugin will not be available for Unraid 8 at all.

Hi Kluthr,

No problem at all. I figured the same to be fair. A short term user level fix appears to be disabling the USB Backup. This is fine as Unraid backs it up anyway.

Can I also say thank you so much for all your efferts on this app in the past! Very grateful!

Have a nice day!

Edited September 28Sep 28 by nasbox

2 hours ago, nasbox said:

No problem at all. I figured the same to be fair. A short term user level fix appears to be disabling the USB Backup. This is fine as Unraid backs it up anyway.

Assuming one uses Connect. Which many chose not to do.

It's nice that Limetech is attempting to make many enhancements to Unraid, but I fear that they have taken on more than they can handle. The change in their licensing schema has them now supporting several paths of 7.x versions of Unraid. Unraid 8.0 will be a monumental change, one which they don't seem to have the resources to regression test nor user acceptance testing to perform.

This will become even more an issue with all of the community provided add-ons, which is one of Unraid's biggest features. Using this breaking change as an example, for whatever reason they decided to change the output of one of their functions which in turn caused the issue with this plugin. Developers generally follow the rule where you don't mess with the format of the input or output of a function - everything you do inside the function is fair game to mess with. Not LT - Not our code, not our problem.

Let's see how many community devs decide to rework their code with the rollout of Unraid 8.0. We are already seeing some either abandoning their projects and/or moving on to other platforms. I have to say, it is a bit concerning to me...

@tiffanyj @SpencerJ

23 hours ago, ConnerVT said:

This will become even more an issue with all of the community provided add-ons, which is one of Unraid's biggest features. Using this breaking change as an example, for whatever reason they decided to change the output of one of their functions which in turn caused the issue with this plugin. Developers generally follow the rule where you don't mess with the format of the input or output of a function - everything you do inside the function is fair game to mess with. Not LT - Not our code, not our problem.

Let's see how many community devs decide to rework their code with the rollout of Unraid 8.0. We are already seeing some either abandoning their projects and/or moving on to other platforms. I have to say, it is a bit concerning to me...

Thanks for your concern. We will be bringing in all plugin authors well ahead of time in a private release phase to allow ample time for feedback, concerns, help and a smooth transition. The community will always remain a core focus for us.

Cc: @ironicbadger

So I keep getting many tar verification failures, but it's all something very obvious..

Some containers, like Duplicacy I have a single volume mapped to /mnt/user as it needs to access many shared folders and the output folder as well..

The issue is in this plugin's setup, it knows /mnt/user is a mapped volume and therefore its excluded..

The issue is that it ends up with a recursive/circular contradiction..

ignore /mnt/user

backup /mnt/user/appdata/duplicacy

The ignore masks the app data folder..

Since this is no longer being developed, if I want to carry on using it, is the only method to map 12 volumes in duplicacy to avoid this? Or is there something I'm missing?

And its not the only container, some would need 20+ volumes mapped to get around similar issues.

Edited October 1Oct 1 by Snubbers