DrSpaldo

I would like to request a 'feature' request, more of a settings tweak request. That you can limit the error messages being sent to just 1 per backup. If I have new containers added that don't have a volume, I am getting 'error' messages for each one, so for example, recently I installed Nextcloud AIO, with its internal multiple container system. Today's backup, I got 6 notification messages sent to my phone. [10.05.2026 07:20:00][❌][nextcloud-aio-borgbackup] 'nextcloud_aio_backup_cache' does NOT exist! Please check your mappings! Skipping it for now. [10.05.2026 07:20:06][❌][nextcloud-aio-borgbackup] 'nextcloud_aio_mastercontainer' does NOT exist! Please check your mappings! Skipping it for now. [10.05.2026 07:20:12][❌][nextcloud-aio-borgbackup] 'nextcloud_aio_elasticsearch' does NOT exist! Please check your mappings! Skipping it for now. [10.05.2026 07:20:17][❌][nextcloud-aio-borgbackup] 'nextcloud_aio_redis' does NOT exist! Please check your mappings! Skipping it for now. [10.05.2026 07:20:30][❌][nextcloud-aio-clamav] 'nextcloud_aio_clamav' does NOT exist! Please check your mappings! Skipping it for now. [10.05.2026 07:20:37][❌][nextcloud-aio-onlyoffice] 'nextcloud_aio_onlyoffice' does NOT exist! Please check your mappings! Skipping it for now. Although I think they should probably be 'warnings' instead of errors, my request is that you only get 1 error notification message per backup, to reduce the spam. Thanks for the plugin.

I cannot believe that this isn't part of Unraid. Backups are vital and shouldn't need a degree!

Simple answer would be “I think so”. But with Unraid, who knows. The community support is pretty good but the actual devs don’t really do much here. If you search similar topics, there are so many and all you hear is crickets. My suggestion would be taking as much as possible off the fuse file system. So for example, in my Frigate docker, instead of having the storage as /mnt/user/share I now have /mnt/disk4/media/frigate The limitation is that then the storage has to be on that drive. I changed so many things, I can’t totally be sure if that’s what fixed it, but hence the “I think so” response. I’d try that first….

This is an old post and may be unrelated. But, if people google search like I did and come across this. Check to make sure if you are using rsync to transfer that you do not use the compress flag (-z) as this will cause this exact behaviour. I was getting unresponsive dockers, total CPU usage reported within the unraid gui but little usage in htop. Turned it after I stopped the rysnc transfer and resumed without the compression flag, it fixed the issue.

Turns out that crashing container was a relic from one of my stacks. It was one that was no longer used but had not been removed from the system. However, it appears just a bonus in the logs, it wasn't related to the crashing. At this early stage, I have the most uptime so far, and main change I made was removing nvidia hardware acceleration from Frigate. I swapped back to qsv/vaapi instead and the ram is holding steady. When the nvidia hardware acceleration was enabled, the ram continued to grow and grow until it overloaded the system. Despite there being a docker ram limit, it just went beyond the limit and consumed all system resources. I should know in the next few days if that was the issue, but for now it looks that way....

Thanks for the reply @Michael_P. I wish all of that mean't as much to me as it did to you. I think that Frigate is the cause. Now I just have to work with them I guess to find out what is going on, hopefully someone over there may be able to help. So far, it seems it may be related to having nvidia hardware acceleration turned on. It isn't anywhere near as bad leaking/using ram without that turned on. Regarding your second part of the post, I have even less idea what that means. What is the container that keeps going up & down? Currently it is this that keeps repeating itself in the logs: Jun 17 19:59:11 Home43 kernel: eth0: renamed from veth356a5b4 Jun 17 19:59:11 Home43 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6ce0dbf: link becomes ready Jun 17 19:59:11 Home43 kernel: br-191c7978c3a3: port 5(veth6ce0dbf) entered blocking state Jun 17 19:59:11 Home43 kernel: br-191c7978c3a3: port 5(veth6ce0dbf) entered forwarding state Jun 17 19:59:16 Home43 kernel: br-191c7978c3a3: port 5(veth6ce0dbf) entered disabled state Jun 17 19:59:16 Home43 kernel: veth356a5b4: renamed from eth0 Jun 17 19:59:16 Home43 kernel: br-191c7978c3a3: port 5(veth6ce0dbf) entered disabled state Jun 17 19:59:16 Home43 kernel: device veth6ce0dbf left promiscuous mode Jun 17 19:59:16 Home43 kernel: br-191c7978c3a3: port 5(veth6ce0dbf) entered disabled state Jun 17 20:00:16 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered blocking state Jun 17 20:00:16 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered disabled state Jun 17 20:00:16 Home43 kernel: device veth70cdb5a entered promiscuous mode Jun 17 20:00:16 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered blocking state Jun 17 20:00:16 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered forwarding state Jun 17 20:00:16 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered disabled state Jun 17 20:00:17 Home43 kernel: eth0: renamed from vethdb7f9e1 Jun 17 20:00:17 Home43 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth70cdb5a: link becomes ready Jun 17 20:00:17 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered blocking state Jun 17 20:00:17 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered forwarding state Jun 17 20:00:21 Home43 kernel: vethdb7f9e1: renamed from eth0 Jun 17 20:00:21 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered disabled state Jun 17 20:00:21 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered disabled state Jun 17 20:00:21 Home43 kernel: device veth70cdb5a left promiscuous mode Jun 17 20:00:21 Home43 kernel: br-191c7978c3a3: port 5(veth70cdb5a) entered disabled state

Totally locked up / crashed again this morning. I physically pulled out the USB and just took the log from it. Couldn't connect via web/ssh or even ping the server this time. Prior to this, I increased the Frigate container ram limit to 16gb, increased the shm size from 512meg to 1gb. See attached log. I am currently running memtest86 to see if there are any ram issues. If that is fine, the next step is to remove the hardware acceleration from Frigate's config and then I will also try putting that tmpfs to disk. 2024-06-17 syslog.zip

Ah ok, so not in the extra args part. Thanks

Yep, there are quite a few that I’ve searched for, most are slightly different and without any definitive answer unfortunately. I’m happy to give anything a go though, I can’t have the machine crashing every day. how exactly would I change that extra args to be on the drive instead of ram?

Interesting. If it were using 12 gigs, that’s way more than it should be. Currently it’s sitting at about 5 gigs on the docker page, earlier today it was closer to 4 gigs. Using 12 gigs though, should still have 30+ free in the system. So do you think regardless I should change that tmpfs map to a drive and not ram?

Thanks for the reply @Michael_P. I think that’s 1 gig of RAM for the temp cache, I’m happy to use a gig on that to reduce the HDD wear. I’ve currently got 64 gigs with the system using 33%. So plenty free?

Thanks for the reply @JorgeB, unfortunately that container/app is Frigate, which is my CCTV system and I can't turn it off.... Would you have any suggestions of what I can try that would allow me to keep it running? Below is the extra args I have for that: --shm-size=512mb --mount type=tmpfs,target=/tmp/cache,tmpfs-size=1000000000 --restart unless-stopped --gpus=all --memory=8G I've got the media (saved files) going directly to the disk & not using fuse; /mnt/disk4/media/frigate

Hi, I have recently updated a friends server from 6.9.2 to 6.12.10 and have started getting full system hangs, around once per day since. Yesterday I made many changes to the system as per this thread. Overnight, instead of totally hanging, the server survived (partially) and I only had one app that wasn't functioning correctly (Frigate due to the TPU drivers not being loaded). I've checked the logs and it looks like there are multiple OOM errors, unfortunately I just cannot read/understand them. I was hoping someone may be able to help interpret them? home43-diagnostics-20240616-1008.zip

For those that also may come and find this thread. I have just upgraded a friends server from 6.9.2 to 6.12.10 and now having crashing issues. It is lasting max of 1 day then the server goes totally unresponsive, even on SSH. It does ping back though. At this stage, I am trying all the suggestions above, however, I cannot take Frigate off this server. So it will be interesting to find out if there is a way to keep Unraid running with Frigate as well. I try to keep updating this thread with the outcome/progress

Hi @MrK, yes, I do think that was either the primary cause or a big part of it. Although I have no concrete proof. I know originally when I was deep into the issue, I found out that the --memory line doesn't always work with Unraid. I did a quick search earlier and didn't find the exact post where I remember seeing it though... Here are a few to look through that may help - Unraid OOM Issues · blakeblackshear/frigate Edit: check this post to see if you are using the fuse file system for your Unraid Frigate container - FUSE post - Frigate Github