KluthR

Shortcut? Where? What do you mean with manual move button?

Thanks. Why dont you use the grouping feature inside the plugin? However - your script says, it stopped nextcloud. But the status information afterwards show, that nextcloud is still running. Same for immich. Checking the code again shows me, that I get the container statuas AFTER the preun script. Can you verify your script really stopped the containers in question? It shows that it tried to - but did it succeeded? Is the docker stop exit code being checked? You could add a docker ps in your script for debug purpose to see which container is in which state.

Did you tried „Skip stopping of container“? Im not sure if this skips start as well.

@thatsthefrickenlightning Thats interesting, because: The status informations about all containers are checked AFTER the prerun script. So, if you are stopping any container, the script should be aware of it. The mentioned log-line contains messages directly from docker. The "Code: " is from me, anything betweenthat and " - trying docker stop method" is the result that docker said to me. Also, the stop routine checks, if the current container is Not Paused and Running and only issues a stop then. Can you verify, that your pre-run script really stops the container in question? If yes, please submit a full debug log. The debug log contains all container states after the pre-run script.

Try creating a folder via terminal (mkdir) there. Check the rights (ls -la /user/backups) for that folder.

This is no issue with the plugin. Somehow tar thinks the file shrank, so I assume some kind of access and/or filesystem issues. Could you do a filesystem check?

There is a new BETA. It includes fixes for TailScale and includes the settings-form-does-not-save fix. Please test and report back.

No. As it does not interact with the system on that level.

Hm. There is no such option, maybe I add it in future updates. Should be no big deal. but you can skip tar verify at global scope in global advanced options for now.

@Holle88 Ill check why the log is not included. Even if the backup fails, the log should be included. Hm

Then please disable VM XML backup setting

No. Those warnings do not let them fail the log should be copied over to those directories. Nothing in there? What is inside of those failed ones?

code-server is using servarr as volume path which contains many other container appdata. I think excluding it in its advanced container settings should do the trick.

Yes. Named volumes are not supported at this moment. Only bind-mounts. this issue must be there for more than two days. Except this machine learning is new.

Thats right. Personally I include the flash backup inside the normal backup folder. Retention deletes this flash backup as well. But custom locations are out of its scope.

Your docker service had an issue. Any stop or start command failed with: stream_socket_client(): Unable to connect to unix:///var/run/docker.sock (Connection refused) /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php:725 so a reboot should sort this out.

@Kilrah your post regarding misbehaved restore is gone? Did you found the issue?

Hm. What was the last log line before you first tried to cancel it?

For everyone using Tailscale: It seems, that the plugin gets irritaed by the hook-script which is inserted as volume. Can someone confirm the issue oin their side? Can someone confirm also, that adding "/usr/local/share/docker/tailscale_container_hook" to the global exclusion list fixes the issue? For reference: https://github.com/Commifreak/unraid-appdata.backup/issues/50#issuecomment-2843085311

On the way, so not able to check debug log. But if its just this message: Open the per container settings and read the info about external and internal volumes. Check if you want to include any external volume. Default is to NOT backup external volumes, hence this message (which is just an info)

No. Use post-run custom script to do such things.

Are you talking about appdata sources? Then The first both are sufficient. The best in this case would be: Let it run (if not already) and share a debug log.

You have to chosse the parent folder, which holds the ab_ folders. Do not select the ab_folder itself

Seems like something else is accessing files of this container. Is some other container using the same data?

Yes, only a reboot would reset that fix.