KluthR

Always full paths. Use the file selector to see example.

Need to check after my vacation.

@Apollopayne35 Please share the debug log with an affected run. Wither as attachment or (if you have privacy concerns) attached as PM.

This one has one as well as the new appdata.backup.

Hmm, I'll check it later.

Your docker.img is being backed up which is not right. Please move the docker.img to its original place or at least outside the appdata dir. you could also exclude it.

You wont find it until you use Unraid 6.12. the new plugin is for 6.12+.

Exactly. I plan to let the plugin do the container creation. But doing it the way you did (I believe the restore page is noting that) is the right way.

This is not critical and I dont fix it. I will check it for the new appdata.backup plugin. Please test it after Unraid 6.12 release there.

The new appdata.backup lets you decide the start/stop order. I observed the same issue with ca.backup2 but I dont fix anything non-critical anymore.

Sidenote: The dev from the software from which I noticed the docker behavior commented: https://github.com/john30/ebusd/issues/751#issuecomment-1570529173

For anybody to test, Ive created a small docker image which outputs a test. It starts a openssl s_client -6 connect test (forces v6!). Running with: docker run --rm -e TESTURL=google.com:443 rkluth/ipv6test:latest uses default host network - all is working! But as soon as br0 comes in, the first connect try fails! docker run --rm --net=br0 -e TESTURL=google.com:443 rkluth/ipv6test:latest The output with my issue looks like: Welcome! Run 1... 22497312937280:error:02002071:system library:connect:No route to host:../crypto/bio/b_sock2.c:110: 22497312937280:error:2008A067:BIO routines:BIO_connect:connect error:../crypto/bio/b_sock2.c:111: connect:errno=113 Run 1 failed Run2... depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1 verify error:num=20:unable to get local issuer certificate verify return:1 depth=1 C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 verify return:1 depth=0 CN = *.google.com verify return:1 DONE Succeeded! The test requires a IPv6 enabled br0 interface. Can anyone give it a try if the "issue" or whatever this is, exists on other setups too? Any docker pro who can explain this? EDIT: If you are curious, this is the entryscript: https://pastebin.com/NLFJNveF Thanks!

Iam on 6.11.5 for my prod system and experienced a strange issue. I use br0 with fixed ip. My br0 looks like (btw: the code block is missing JSON as format): [ { "Name": "br0", "Id": "5ec57e4baea4b76618a625d494cd6269967f5cde931e18b0d7d0a728264dfb1f", "Created": "2023-05-10T07:17:50.118211813+02:00", "Scope": "local", "Driver": "macvlan", "EnableIPv6": true, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.178.0/24", "Gateway": "192.168.178.1", "AuxiliaryAddresses": { "server": "192.168.178.3" } }, { "Subnet": "**masked**", "Gateway": "**masked**", "AuxiliaryAddresses": { "server6": "**masked**" } } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { mycontainers }, "Options": { "parent": "br0" }, "Labels": {} } ] If I run containers like bullseye or jammy like: docker run --name='test' --net='br0' --ip='192.168.178.16' -it ubuntu:jammy /bin/bash then the first IPv6 request (tested with openbssl s_client) fails with "no route to host". Any attempt afterwards works. I never noticed such things since all containers are v6 enabled and they are running. even apt is not throwing errors, but maybe they work another way? I first noticed it by an app which uses libssl and throwing connect errors. digging deeper with openssl s_client showed the above issue. Any experiences with this? Maybe a docker bug which got fixed within new rleases? Did not tested it with latest unraid rc. I dont know if this is a very specific issue, maybe it is. EDIT: Also happending with latest rc6 and docker 23.0.6: root@4213d6b86d58:/# openssl s_client -6 -connect testsite:443 40879E9DE9140000:error:80000071:system library:BIO_connect:No route to host:../crypto/bio/bio_sock2.c:125:calling connect() 40879E9DE9140000:error:10000067:BIO routines:BIO_connect:connect error:../crypto/bio/bio_sock2.c:127: connect:errno=113 root@4213d6b86d58:/# openssl s_client -6 -connect testsite:443 CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify error:num=20:unable to get local issuer certificate verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = testsite verify return:1 ...

1. Normally, nothing gets deleted, but some users have "special" setups. To be honest: I would disable USB backup for now, wait for Unraid 6.12 stable and migrate to I just made the errors popping up correctly, the rest is the same. The new plugin is a complete rewrite. The ca.backup plugin will stop working with Unraid 6.12 (It still works for Unraid up to 6.11.5 though)

Yea, thats a UI bug. Same reason. I will fix that as well soon.

Please retest with the new plugin (see first post) after Unraid 6.12 is released.

No, the pre run script should be executed before the source check. That seems to be a bug. Or rather a misplacement. I wonder why it is checking retention after those error. I check this as well.

Please post or PM debug log

It does not terminate it, the config seems wrong. the source path (for internal volume mapping) points to a UD disk? please share your whole debug log (or PM me).

Well, there are info banners within Squids and my version. The deprecation info existed before 6.12 already. Some users had special setups. This resulted in weird results within the new plugin, yes. But nothing unfixable. This was one big wish from many users to make container based backups. Thus it behaves different. But you can decide how to stop the containers. Please share the debug log as attachment or as PM to me if you want me to get tips.

Well, okay. For explanation, you could PM it to me.

Please share the whole debug log. the new plugin backs up what is in use by containers. It reads all mappings per container. Please also read the help block within the source option. the weekday for daily is not properly disabled, but being ignored for „daily“. the idea to backup remaining folders not in use of any container sounds nice.

Then use „compression: Yes, Multicore“. That uses zstd.

😂 I will see what I can do 👍

It has the option, yes.