KluthR

Same issue here. Unraid does not pick up the latest prefix from RA. This dynamic prefix shit for private customers is a pain...

„Group“ field inside container specific settings.

It seems that something is messing with the files. Some other „thing“ that would do that? Mover? best way is to share your debug log.

@Revan335 its all described inside restore page except for „one file“. Either all or nothing. Its not selectable to only restore one file.

The start order is used for stop, backup, start. If you put both in one group, both get stopped, then backed up and then started like the group order is. So: yes, that would be your solution

New observings: Its not happening with bridge network interface. See https://forums.docker.com/t/occasional-ping-issues-over-ipv6/140296/2?u=rkluth @ich777 You also have IPv6 experiences with Unraids docker. Did you ever came accros such issue?

The order is effective for both modes as the container lost gets „sorted“ once when starting the backup.

But the log above that field is visible? No recent reboot or anything?

now.

Yea. Just checked. The plugins chmod runs after post-run. Will change that in next release

Check settings. Whats inside allowed appdata source paths? Is the volume in question maybe "external" and therefore excluded? Some of your containers excluding /mnt which leads to empty zips..? Point to the backup and restore all XMLs and appdatas. Use Previous apps to install all containers. Currently you need some manual work. Another check here: I bet this container is inside of a group?

Could you please upload a debug log and share its ID?

Oops. Yes, not CA related Could someone move it for me?

Interesting. Is there something special about /mnt/user/unraid_backup ? Whats happening if you run "mkdir /mnt/user/unraid_backup/appdata_backup/test"?

Feels more and more like a general v6 docker issue. docker and IPv6 are not the best friends. There are several issues regrading v6.