kingbuzz0

Thank you for the plugin! I am getting stated with TSDProxy, but instead of Tailscale service I am self hosting Headscale on my server. For this to work, TSDProxy requires the scheme to be set to HTTP only. Label Manager has this option in the advanced list, but it doesn't look like it does anything. When I change to HTTP (with tlsvalidate set to false), there is no tsdproxy.scheme label created. I assume this is a bug? Also would like to add my bambuddy container to my tailnet, but it is setup as a host network. How does the autoport detection work for containers on host networks? If I understand docker networking, setting to host opens up all ports for use for the container.

Something that I have learned recently is that 16GB is just not enough for me to run this plugin. I had tried a few times to run manual build on an 8TB drive only to find several hours later the unraid webgui completely stopped running. I could still SSH into the machine and my container based services were still running fine. But there was nothing I could do to revive the webgui. Eventually I tracked it down to running out of system memory during the file scanning phase of the integrity plug in. I stopped most of my containers to free up the maximum available memory, but it was still not enough. I upgraded to 32GB and the problem went away. So if you run into weird unraid gui behaviors (missing drive temp data, pools disappearing, general sluggishness) that ultimately leads to the webgui page refusing to load at all after starting a File Integrity build, it could very well be that you need more system memory for the plugin to operate.

I am not certain what urbackup temp files are used for, but in my case there were large files created that were related to active backup jobs. These easily ballooned to 16GB and pushed my docker image to 100%. It took a bit of digging around but I found the tmp dir was to blame. In addition to the 3 or 4 very large files there were also 30-40 other smaller files. I had problems with my scheduled backups running because I had run out of space on one of my shares and didn't notice for some time. So I think the root of my problem was because there were multiple failed backup jobs over that period and when I finally added more space the backlog of backup jobs resulted in huge temp files. In any case, if there are scenarios where urbackup will create huge files in /tmp, I think it's best to bring that mapping option to the container config and hopefully prevent this scenario for everyone else.

I was having an issue with this container blowing up my docker image size. It turns out urbackup was creating very large temp files in /tmp. I solved the docker image size issue by manually mapping /tmp to /mnt/user/appdata/urbackup/tmp. I would suggest adding /tmp as a standard config option in the container settings.

Can you please explain a little more the steps after the install? I am a little confused after installation on what you mean by updating a 'go' file. I am still pretty new to Unraid, so I am guessing this is an Unraid term? Here is what I have so far. From the cmd listed, I was able to successfully install Urbackup client (although not sure if I chose the right install options for my use case). I can see that the client is running and the Urbackup Server (which runs on the same Unraid machine as this client install) correctly sees the client on the network. The 'which' command yields; /usr/local/bin/urbackupclientctl $PATH includes /usr/local/bin/ So now is where I am stuck. Do I simply move urbackupclientctl to any drive location and update the $PATH? Or are you suggesting making a copy of the binary to a drive location and in a startup script (referred to as 'go' file?) have it copy the binary back to /usr/local/bin/ for each reboot? Thanks in advance.