testdasi

Correction of terminology: "array" of spinning rust. Pool can refer to the cache pool so using pool interchangeably can be confusing. SSD does not need to be partitioned like that. Just put the SSD in the cache pool and put a vdisk for the Windows VM and the plex db (and docker image) on the cache pool. It essentially achieves the same thing (just set the vdisk to be half the size of the SSD if you want to use up to half the SSD for the Windows VM). The pro of using vdisk is that it is thinly provisioned. You can mount the SSD as unassigned device (there's a plugin for that), format it with 2 partitions (warning: command line) and set things up manually (warning: manually!) and achieve what you are after. However, the performance benefits you will get (or not get) is minute compared to the complexity.

Fan control with Unraid is typically done by the mobo BIOS. The plugin supposedly works but only for some specific hardware. When you pick Auto, the BIOS picks a certain curve. 41C is hardly hot enough for the fan speed diff to be audibly difference. To sort of "test" the fan, you have to put sufficient load. There is no downside to keeping fan running at 100% except for the noise. So if the noise is acceptable to you, just keep it at 100%.

Indeed the limit is for the kernel to know when to kill a docker. I don't think the docker itself is even aware of the limit (perhaps it can be aware but I don't think that piece of code implemented in all the dockers that I can tell). There's also a side effect for setting docker memory limit is that it is less likely to kill your VM if you actually run out of memory. So don't just go undo all your docker limit.

The 70% utilisation you see right now is after the offending process has been killed so it's likely a red herring. OOM error happens if (a) you actually run out of memory or (b) a docker runs over its memory limit or (c) unusual problem Did you set the dockers memory limits before or after mysql docker was killed? If before then you need to increase the limit for mysql as it was killed because of reason (b) above. And OOM is not an urgent issue to fix as long as it doesn't kill your running docker / VM. Side note: Reason (c) is really unusual and not something you need to worry about. For example, my TR4 server with F12 BIOS will have OOM error if I allocate more than 50% RAM all at once (e.g. start a VM) while having Global C State disabled (enable C state and no more error).

Perhaps grab another cheap Bluetooth dongle and try again. Maybe it's the dongle that doesn't like libvirt.

Not with Unraid array and cache. I believe ZFS has tier storage that may be the solution. There's a ZFS plugin for Unraid if you are comfortable with command line and ZFS.

Then the only potential fix is to pass through a USB controller to the VM. Some devices just don't work with the libvirt virtual USB device.

If you don't need GPU pass through then your choice of mobo is fine. Don't need to go over the top and get ECC RAM either - ECC is never a system requirement for Unraid. If you have ECC sticks, good. If you don't, no worries. You will need an SSD for your Plex db and docker container (and any other things you want to run once the server is set up). If you don't want to lose a SATA port then get it an NVMe M.2. Whatever SSD you get, avoid DRAM-less SSD like the plague. Don't forget to budget a cheap graphic card in case your mobo does not allow headless booting. It's virtually impossible to predict if a mobo will allow headless booting or not without owning the actual board. If you ever need SATA card, see post below for some suggestions. Generally though LSI HBA (commonly found on ebay) are the preferred option. Make sure they are HBA and not RAID card!!!

Your SSD + 3x 3TB HDD will all need to be formatted before they be used with Unraid. Don't shuck the WD Red first. Connect it to the system via USB to get the data out. You will almost certainly need to mount the WD as unassigned device to copy data over to 1 of the 2 Seagate so you can format the WD afterwards. As long as you don't use any super exotic file system, you should be fine. Reason to start with USB is that may need to mask the 3.3V pin (look on Youtube bytemybit channel for instruction), otherwise, the WD won't show up if shucked and connected through SATA. While the process is simple, the less you have at the back of your head during migration, the less stressful it would be. Make sure to preclear the 2x Seagate before using them. Once data migrated out of the WD Red, preclear it as well before adding to the array. Preclear is a useful tool to test drives to identify issues early (e.g. so you can RMA any failed drive before having actual data on it). These 4 plugins are basically the starter pack: Community Apps (it's basically the Unraid app store - use it to install everything including the other plugins below) Preclear (so you can preclear drives - see point above about testing drive before using / adding to array) Unassigned Device Unassigned Device Plus Any PCIe pass through? Based on your config I'm guessing not so you should be fine.

Bluetooth audio works but keyboard doesn't suggests it's something specific to the keyboard. I have lots of bluetooth stuff connected to my £5 USB Bluetooth dongle and no issue at all. The "stop typing for 3s" sounds like your keyboard goes into standby / power saving too early. (or it runs out of battery). Do you have a friend's PC / laptop to test your keyboard?

No SSD should be involved in booting Unraid. Are you able to boot from the USB stick?

Hardware-related instability can be hard to predict / understand. For example, with Precision Boost on (i.e. AMD-certified automatic overclock), my system is rock solid stable. Browsing, gaming, transcoding etc, all fine. The only exception is a very specific Lightroom job that does not even load up on the CPU (not even ONE core to 100%!) and it reliably crashes my whole server every single time despite being run in a VM. The point here is you can't really predict when an innate instability will rear its ugly head.

That was a typo. It's using mergerfs now. First line of the post.

Can you? Yes. Should you? No. The (multi-drive) cache pool is RAID-based (BTRFS RAID). So either you will have 250GB available space (RAID-1) or 500GB available space (RAID-0). I.e. no improvement. A better option is to mount the 250GB as unassigned and use it for write-heavy activities (e.g. temp download files). That will enhance the life span of both drives and still give you more storage space.

Microsoft Remote Desktop Adapter is the RDP display emulator. If you have a device in your Device Manager that is not in error state, forcefully removing it is rarely ever a good idea. Try connecting a display to the graphics card to see if you are able to change resolution. If you can then you probably need a dummy HDMI plug.

Access control is done per share so go to the share, change settings to Private, Apply then you will see the user-by-user access control at the bottom of the page

It's not unusual for things to happen out of the blue. For example, if you watercool, the gunk buildup (big hoohah with a popular AIO recently) will need some time to happen and eventually the pump can only put in so much continuous high load. Could be even as unlikely as bad TIM that dries up or RAM stick that just fails. Or even an overheated NIC that becomes unstable. Of course, if you recently make changes to the system (even software e.g. new docker / docker settings / VM etc.) then they do stand out as potential causes so you should provide details whatever that changed in tha last 3 days.

Ignore the tdsrc and tddst part. They are specific to the AutoReclone and not to the buzz script. Yes, add the email to the Team Drive (on the Gdrive GUI). Check the Gdrive GUI, go to the Team Drive and see the access permission list.

This one. (Note that there were quite a number of posts after this so you might want to read up in case there have been further development. I don't keep track of what happens in there since I don't need Vega patch).

What's your RAM speed? Are you using XMP? Also can you let us know the last time it crashed / unexpectedly reboot? Was it this morning? Your 23MB syslog spanned almost the whole April so it contains too much information (e.g. your intentional reboot is mixed up with the crash) so we need to narrow it down.

The Radeon VII is a Vega so chances are you will need both a vbios and the Vega patch. Preferably you should compile your own Unraid kernel with the patch but there's a forum member who kindly did it and share with everyone.

The hoo-hah with WD sending out SMR drives is that it was done quietly and less about the SMR drives themselves. SMR with HDD is quite similar to QLC to SSD. There's a fast write cache that once used up, the drive write speed plummets, which usually only happens with a large amount of random IO. I don't think you will get many direct answer with regards to the WD Red SMR performance since they are rather new. But if they behave anything like the Seagate Archive, they should be just like PMR 5400rpm drive to rebuild. (Typically only large random IO is slow. Rebuild is basically a super long sequential write.) Iron Wolfs are 7200rpm drives so they are faster to rebuild just because 7200rpm is typically faster.

The OP already wrote an excellent set of script to integrate rclone + mergerfs to Unraid. Have a look so you won't waste time.

File name does not matter. You can use whichever (and whatever) you want really.

If you use High Water allocation, there's basically no need to set split level (i.e. split everything) cuz it's exactly like what Frank said. If you use Most Free for media storage then you do need to pay attention to split level, otherwise almost all accompanying files (or at least a large proportion of them) will be on a different drive.