Michael_P

Yep, and that's why it was killed, it blew past the limit Mar 31 02:09:14 Orion kernel: Memory cgroup out of memory: Killed process 1611155 (Tdarr_Node) total-vm:24564080kB, anon-rss:12980236kB, file-rss:13308kB, shmem-rss:0kB, UID:0 pgtables:316432kB oom_score_adj:0 Mar 31 02:09:17 Orion kernel: oom_reaper: reaped process 1611155 (Tdarr_Node), now anon-rss:76kB, file-rss:2432kB, shmem-rss:0kB You need to map /temp to a disk share in the tdarr_node container, or preferably an old SSD you don't mind abusing.

Maybe, but it was tdarr that hit its limit and ran OOM and was killed. Change the config so it's work area is on a disk. Reboot to clear the log so FCP stops warning you

Yeah, stress ran the host OOM, reboot to clear the log so FCP stops warning you

Try re-uploading your diagnostics, there's nothing in it

Looks like frigate was transcoding a bunch of streams back on the 28th of Feb and ran the host OOM. You can re-boot to clear the log so FCP stops warning you, and if it happens again you can fix the config so that it's transcoding to disk instead

Didn't read the wall of text, but it's clear you're over thinking it :) Just use NginxProxyManager, it'll let you host your services and provide the SSL certs if you need them (you probably don't). The only time you REALLY need to use a VPN is to access the local network. Make sure your services stay up-to-date, and you won't have much to be worried about.

Update the nvidia driver and/or your motherboard bios

With 16G of RAM you shouldn't be using it as cache, it's actually recommended to use an old SSD for cache as the file sizes can be pretty large if you're working with blurays and such. Map the cache location to a disk.

While power issues are a concern, I would direct your attention to the controller falling over and the critical btrfs errors @JorgeB what do you think?

+1

+1 for the I like spaces in my folder and file names camp. And capital letters. There, I said it.

In the meantime, you can just create the share by making a folder in /mnt/user - then it'll show up the same as any other share and you can configure it from the gui

Doesn't look like anything to worry about, but you have what appears to be a container causing GPFs pretty regularly, try updating your nvidia drivers Feb 16 06:01:58 Sunflower kernel: traps: bun[4080350] general protection fault ip:147fdccff50f sp:7fff5869ce10 error:0 in libc.so.6[2650f,147fdccff000+155000]

a2718e102eaf is the container ID, you can verify on with the advanced view toggled on the docker page

Your video card is falling over, try updating the driver, and/or your motherboard bios. FCP just sees "out of memory" in the log so that's what it's warning you about, it doesn't actually have anything to do with your RAM or available memory in this case. Reboot to clear the log so it stops warning you

To fix the actual problem you asked about, Tdarr ran the host OOM so make sure its work space is a disk instead of RAM. Reboot to clear the log so FCP stops warning you.

Post diagnostics next time it happens

Looks like yesterday twice at around 1100 and 1145 duplicati tripped the host out of available memory - if you were doing something with it, there's your problem. It's not related to bad RAM, if that was your concern. If you've already rebooted to clear the log, FCP should stop warning you, and if it happens again you can configure the container so it's not storing so much in RAM.

No, not likely. In every instance I've seen of that error it's the driver or the motherboard BIOS if it's choking at the higher PCIE gen

Welcome Your video card is falling over, update the drivers and/or motherboard BIOS. Then you can reboot to clear the log so FCP stops warning you (it's just responding to seeing 'out of memory' in the log and assuming the host ran out of RAM).

Looks like one of your services tipped the host over and it killed the VM back on 5th and again on the 8th. If it happens again, you will need to add more RAM or put your VM on a diet if you plan on running other services like that regularly. Reboot to clear the log so FCP stops warning you

I'd give the PSU a shot first

Haven't tried it, but clients can backup to two different servers provided the keys match Here's the relavent bit from the manual in 4.3: If you want to have several servers to be able to do backups of a client you have two options. Either you manually supply the server credentials to the client (by copying them into ’server_idents.txt’) or you give all servers the same credentials by copying the same ’server_ident.key’, ’server_ident_ecdsa409k1.p riv’ and ’server_ident_ecdsa409k1.pub’ to all servers A quick AI generated instruction later and we have this: Install UrBackup on the second server. Copy Security Files: From the first server, copy server_idents.txt, server_ident_ecdsa409k1.key, etc., to the second server's data directory (usually /var/urbackup/). Configure Clients: Add the second server's identity string to the first server's server_idents.txt file (or add the first server's to the second's), or add both server identities to your client configurations. Start Services: Restart UrBackup services on all servers/clients. Result: Clients will now find and back up to both servers, creating identical backups on each. YMMV

You can run Urbackup server and client on both Unraid and QNAP