Michael_P

+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

You'll still need to reboot or FCP will warn you since it's in the log

Yep, it's hitting the limit on the container Memory cgroup out of memory: Killed process 2086114 (Plex Media Serv)

You might try a different PSU, too, just to rule out flaky power

Clipable - still a bad idea tho if you want to open it up to the general public

Map the /tmp directory to a disk to see what it's storing there, maybe that'll help you figure out whatever it's doing. The other option is to limit the RAM available to the container

Rule out the bad RAM first or it will just keep sending bad data

Anything after 2021 will have the 170TB endurance "limit"

I get ya, but with passing memtest and if it's 'out of the blue', the drive wear looks like a definite point of interest. No shade at PNY, but I consider them to be a tier 2 OEM, and if the drive says its reached 100% of its lifespan I'd say it's time to replace - and the 33% drive might have the OG TBW factor instead of their 'updated' one for that series, it's likely really at 100% too

nvme0 is Data Units Read: 1,624,580,180 [831 TB] Data Units Written: 284,023,005 [145 TB] nvme1 is Data Units Read: 492,647,517 [252 TB] Data Units Written: 234,470,619 [120 TB] Rated writes for those are ~170 or so according to my google-fu, could be getting flaky

Maybe, but those drives have a ton of writes and are both probably end of life