ich777

I think you don't understand, each time you trigger a backup, every file is scanned for changes (including the already backuped ones, if a file changed on the source the whole file or a part of it will be replaced/updated. This was probably some kind of archive but here it is just a 1:1 copy from the source.

Maybe, I just heard that GMX uses now also app passwords. I'm really not sure, Google and Apple definitely use app passwords.

Are you sure that nothong on your network is blocking access to the GitHub API, pleas check especially if you have Unifi network gear on your network or any kond of AdBlocking. That's probably old information but even if you have this kind of issue please report that since such an issue needs to be fixed. However there is no such issue to my knowledge because other people would have reported that here too.

The driver is the same for 7.2.0 and 7.2.1 so I really don't know what's going on here, maybe the package went bad.

Can you please try to upgrade to 580.105.08 again and reboot, since it should also have the working container tools.

No, this is not a known bug. Do you notice the notifications about the drivers when upgrading to a new Unraid version, if yes, what do the notifications say? How are you installing the plugin, through CA or directly via a GitHub RAW link, a screenshot would also help. Troubleshooting without nothing more than "is not working" and "bash return 1" is really hard. :D However the notifications that you see should look something like that (you have to watch it to the end): https://github.com/ich777/unraid-plugin_update_helper?tab=readme-ov-file#update-notifications

Do you have Diagnostics or anything that can maybe help? Where does it say run bash failed? What does not work or better speaking what was not working before you uninstalled the plugin, was the card showing up or not, was it working in containers or not?

I really can't tell why it's not working since it should because nothing changed between 7.2.0 and 7.2.1 in terms of the driver. Can you please try to switch to another driver, maybe one version before the one you are currently on and reboot afterwards.

Did you read my comment:

RIP Ronald.

Please also don't forget to include your Diagnostics in this thread.

Usually the container tries to mount the remote regardless if you use webdav or webdavs Are you sure that your certificate is up to date? Please try to open a container terminal and do the following: su $USER sudo mount -t davfs -o noexec,username=<REMOTEUSERNAME>,rw,uid=99,gid=100 <YOURURL> /tmp/webdav/ and see what the output is? You have to of course replace REMOTEUSERNAME with the user name and YOURURL with the URL from the target.

Seems that this is an authentication issue, I heard from other people who where using GMX had issues, didn't they change something fairly recently so that you need to use app passwords? I assume that this is connected to these changes, however the issue is definitely the authentication, nothing changed in terms of the container in the last few months.

I really don't understand what you mean? luckyBackup is just a fancy GUI for rsync. When you start a backup task in rsync it compares all the files from the source with the target and when files in the source don't match the files in the target then it updates/replaces those files. You can do a dry run but that is just for displaying what files changed. How would you like to verify the backup then? Issue with all of that is that this is just a 1:1 copy from the source and there are no checksums or parity data or anything since this is just a simple 1:1 copy.

Definitely not since it runs as root. Wont help here. However maybe the script is now broken <- I wont fix that because of time constraints.

Please see this recommended post on top:

Sorry but you have too much customized things on your server: Nov 19 17:18:40 Tower emhttpd: /usr/local/emhttp/plugins/user.scripts/backgroundScript.sh "/tmp/user.scripts/tmpScripts/gpu_power_usage/script" >/dev/null 2>&1/usr/local/emhttp/plugins/user.scripts/backgroundScript.sh "/tmp/user.scripts/tmpScripts/patch nvidia/script" >/dev/null 2>&1 BTW, please don't enable both, you have the old way of enabling persistenced and also the new way of just issuing nvidia-persistenced from what I see from your Diagnostics, the latter is the only one that's needed usually. However I don't think that you can use peermem on your GPUs since you have a Consumer and a Datacenter card installed, peermem works only on Datacenter cards AFAIK and also I'm a bit surprised that it's in cluded in the default non Datacenter driver package. As said, I don't think you even can enable peermem when you have a Consumer card installed, please see here: https://docs.nvidia.com/cuda/gpudirect-rdma/

What card do you have? Without Diagnostics I can't say anything.

Das kannst auch mit DoH realisieren und hat nicht die Nachteile des höheren Stromverbrauchs von einer VPN.

@Mainfrezzer hat einen fertigen container.

Yes, but you have to install that in the container so to speak something like xvnc so to speak a virtual X server, alongside with noVNC and then you can connect to the container via noVNC or directly to the xvnc server via VNC. You could of course also use something like KASM or similar things to get a desktop or graphical environment in the container to display in a Browser. However that's all up to you, I can only give support for the plugin itself and this is very container specific.

First post in this thread at the very bottom, but the modes or how you apply these modes vary from card to card. You don't have to try the LibreELEC drivers since it seems the TBS ones work just fine for you, however I would recommend that you try TVHeadend, at least that's what I use and whats working perfectly fine.

The error from above mentions that it tried to login with an invalid Steam user which seems really strange to me if you don't add any credentials. However it could be the case that they changed something how the dedicated server works. I'll take a look at it. EDIT: I've updated the container to always default to "SkipNetworkAccessibilityTest": true which is basically not what I want but it seems to be needed for some users. Please double check your port forwarding in your router/firewall if all the ports and the corresponding protocol are forwarded correctly. Please note that you have to use those ports and please don't NAT them to another port because this can also cause issues. I would recommend that you start over by deleting the container, also deleting the folder for sonsoftheforest in your appdata directory and pull a fresh copy from CA.

Please don't change any of these files, these are managed by targetcli exclusively. Sorry but I can't help with that since this seems like a configuration issue.

I'm not 100% sure but if you clone the folder structure from a lxc container then it should work just fine: . ├── lxc ├── CONTAINERNAME │ ├── config │ └── rootfs │ ├── bin │ ├── boot ...