TheOgre
Members
-
Joined
-
Last visited
-
Hello! I have added a github issue regarding adding new Local backups on at least version 7.1.4+. You are unable to directly add a local backup, and instead have to make the configuration as Remote, apply, then change to local, apply again, and then you have to manually create the dataset for it to work. I have detailed the full issue in my github issue. Otherwise it works fine once using the workaround! Secondly, whenever I load the BuddyBackup page, or apply a config change to a local backup, the load/reload takes forever, I am not sure why that is, as it's the only place in my server that does so. The ZFS Master plugin loads just fine, even on the /Main page, just this plugin. It works fine on my other server though. Maybe it's the dataset sizes? Idk. This leads me to the next feature request lol Thirdly, is there anyway to maybe have a combined Apply button at the bottom of each section? It's mostly a non issue once setup, but that initial setup for a bunch of datasets is bothersome when you have to, configure one, apply it, wait for it to apply and the page to reload, then rinse and repeat for X datasets. I see you can click add as many times as you'd like, and the UI populates, but there is only Apply buttons for each individual configuration, and that only saves the config for the one it's relevant too. An "Apply All" button would be fantastic! Otherwise, absolutely love this plugin and think it's crazy functionality like this isn't native! Thanks for your work!
-
I was wondering if there was a way to make this plugin use nice and ionice to run the rsync commands so that a disk being saturated doesn't cause lots of CPU wait time and IOWAIT? Would love for this to be configurable, by either allowing a user editable prepend to the rsync scripts, or just a checkbox to "lower priority for better system stability". As of now, when I need to unbalance something (which is rather rare but it does happen) I have to alias rsync with a wrapper so it behaves like I need it to.
-
Would just like to add that I am experiencing the same issue on 6.12.15, if RAM, disk usage (such as docker) is almost full, disk throughput is very high, webui and ssh become accessible, but all other features including docker, and vm's work fine. The only way to recover is wait for whatever process to finish or timeout, or hard reboot the server if the RAM, or when disk usage drops, or to force shutdown the server via button or power switch. From what I've noticed, about 50/50 success of pressing the shutdown button once and it shutting itself down. I particularly experienced this when Plex was transcoding into the docker image (separate issue that I've resolved), the docker image hit 100%, then webui and ssh access was lost. Will also try updating to 7 at some point (had major networking issues with 7.0.1 last time I tried)
-
So I just updated to Unraid 7 from 6.12.11 and it seems to have broken my subnet routing with tailscale. It seems I can still ping the devices across the tailscale subnet route, but can't access any services there like I was in 6.12. 2 things I have noticed that cause this problem. If I disable the docker service and/or disable "Host access to custom networks" the subnets are still accessible but then host access is lost to dockers (which is a problem for me). Secondarily, If i leave everything as is with docker, and then start ANY VM with networking, the problem is resolved? For example. All VM's stopped, and docker service running (even with all docker containers stopped), results in no access to other subnets except for pings. If I start up a Windows VM, then everything functions as it did in 6.12.11. If I stop the VM, the issue re-occurs immediately. Nothing changed settings wise for me since upgrading, this issue happened right away, and rebooting and changing settings doesn't seem to help. I have checked IP routes and they are the exact same as they were before. I have another unraid server that is more critical still on 6.12.11 and the configuration there, being the same on this server, works just fine, so the issue is linked to some breaking changes in 7.0.0. I am unable to recreate this bug in 6.12.11. I would like to note I am making no use of the new tailscale docker integrations and have been using the Tailscale plugin. I have checked that all plugins are up to date. I have also tried changing route metrics, and while changing the metric of shim-br0 can bring it back up, that consequently brings back down subnet access. Tailscale logs show no error, just reconfiguration when a new interface is brought up (either with docker coming up, or the vnet adapter with VM's). I have also tried enabling and disabling settings in the tailscale config such as ip forwarding, use tailscale subnets, use tailscale DNS, and none of those seem to make any difference. I am using docker custom network br0 for my containers to assign them IP's in my subnet. These static IP's are reserved for these containers so no IP overlaps are occurring. I am also not using the docker DHCP service. The subnet CIDR I am using is 10.2.0.0/24. If anyone has experienced this or has any insight to what is happening/diagnostics to try, please let me know. I will upload a diagnostics file if necessary. My setup is fairly simple and is just a tailscale link between my primary server in a different location on 10.0.0.0/24 and my subnet here at 10.2.0.0/24. No otherwise advanced configuration. Thanks!
-
So I just updated to Unraid 7 from 6.12.11 and it seems to have broken my subnet routing with tailscale. With the array stopped, it works fine, but after the array is started and services come up, about 5 minutes after, the subnets no longer route. In the tailscale logs I have: "2025/01/18 04:53:54 Rebind; defIf="shim-br0", ips=[10.2.0.3/24] 2025/01/18 04:53:54 onPortUpdate(port=44559, network=udp4) 2025/01/18 04:53:54 onPortUpdate(port=50180, network=udp6) 2025/01/18 04:53:54 wgengine: set DNS config again after major link change" which seems to indicate docker is the issue, and sure enough, setting "Enable Docker" to "No" resolves the issue. What is going on here? I read about possible issues with CIDR but mine is 10.2.0.0/24. I have combed through every setting I can imagine and even rebooted multiple times and can't seem to resolve it. Any help? It seems I can still ping the devices across the tailscale subnet route, but can't access any services there like I was in 6.12 or when docker is disabled Update: So after much back and forth with discord user hff and some others about this issue, messing with ip routes, analyzing ip tables, I have sorta figured out the issue? Starting up my virtual machine fixes it? I have a Windows 10 VM using virtio with br0 as source, if this VM is stopped, the tailscale subnet is inaccessible, but as soon as I start the VM, it comes back up? No changes to the ip route, but somehow has an effect? How do I even go about fixing this? I am running the Tailscale plugin and have no issues if the docker service is stopped, even if the VM is stopped, however, if the docker service is enabled and no VM is started, the route is broken. Ping still works, but that's it. Starting up the VM which does not have any tailscale configuration or anything on it, brings back the entire route. Stopping it instantly breaks the connection again. Something to do with virtio? Any help would be appreciated.
-
Okay so, after working on a completely separate project involving a docker networking setting, I ran across something that helped me to resolve this. TURNS OUT, back in version 6.9.x, there was a docker issue I was having relating to networking, and I had placed a USER SCRIPT to manually add the docker network at boot time. Well, this configuration used a completely different IP range than what the server is using now. I completely forgot about this script existing or to even check for it, so my ENTIRE issue was caused by this rouge script I had placed. After disabling/deleting the script and rebooting, all docker containers boot up perfectly fine! Turns out, the reason toggling host access and restarting docker worked, it was just deleting the docker network, and recreating it as it was supposed to be. I feel silly but, HEY, IT'S FIXED!
-
Sorry for the late reply. Uninstalling Tailscale did not fix the issue. To add to the information, I just updated to 6.12.10 and the issue persists, same workaround is necessary each reboot still.
-
Any idea? This is happening every single reboot. Just happened today, only workaround that works is Docker service > Disable, host access > disable, host access> enable, docker > enable. This is severely frustrating to have to do every single reboot. Please help lol
-
Hello all, been suffering with a really weird issue and can't seem to uncover what is going on. Each time I reboot my server, only SOME of my docker containers will start, it seems those using br0 all fail with Mar 28 12:44:13 Server rc.docker: nextcloud: Error response from daemon: failed to create the ipvlan port: device or resource busy Mar 28 12:44:13 Server rc.docker: Error: failed to start containers: nextcloud Mar 28 12:45:04 Server kernel: br0: Device is already in use. The only fix that works for me is, to disable the docker service, disable "Host access to custom networks", Apply, then enable "Host access to custom networks" and start the docker service, and then the containers start fine. I am using IPVLAN. Not sure where to go from here as there are no other log entries for it and googling produces no results. Any help? It's very frustrating having to do this on EVERY reboot of the server, and it seems like such a simple problem. ogreserv-diagnostics-20240328-2036.zip
-
Just wanting to tag onto this thread, even after switching to ipvlan, the plugin is still detecting macvlan traces. Any way to diagnose why or anything else I need to do?
-
So one issue I am running into is exclusions, I got the exclusions for each docker container figured out, but one big issue for me is the exclusion of the /.Recycle Bin/ folder from the Recycle Bin plugin. I find this plugin necessary for accidental deletion of files/folders and had it excluded in the old CA backup. I see under each docker container configuration there is an exclusion list and I can select basically any folder on the system from there, but will that actually propagate to the main backup? Seems a bit confusing as is. Any advice would be appreciated, thanks!
-
So I am actually running into a very similar problem. It seems that having more than just a few dockers running will crash my ISP modem. What's weird is that this hasn't been an issue for almost 3 months, where it last popped up then mysteriously disappeared. I have a few dockers running and everything is stable, but starting anymore than this will cause the modem to crash. Everything else in the network stays functional, all the Ubiquiti gear, routers, switches, but it's the ISP modem that is crashing. Following this thread to see if there's any helpful advice given here.
-
Was searching for the solution to this as well. The threshold is actually under Settings > Disk Settings > Default warning disk utilization threshold (%) Unfortunately this applied to every disk connected to the server, so your array and unassigned drives will be affected.
-
The docker image changes only if dockers add or update new images to it, this does not happen during normal operations. A memory leak will only cause RAM to increase, not the docker image.
-
This isn't related to memory usage but the size of your docker image. What's most likely happening is a docker is updating, at which point it expands the size of the docker image, then once completely updated, it clears the unnecessary parts of the image. Can resolve this by increasing the size of the docker image.
