JonathanM

Yes. The more wire you can feed to your drives, the better. Trying to feed all the drives through 1 lead is possibly going to cause voltage sags when all drives are asked to spin up at once, for example when you tell the server to shut down after it's been dormant with all drives spun down, or a scheduled parity check. If possible, also limit the number of splitters, each one is another point of failure. If this model of PSU is modular, I'd recommend contacting the manufacturer to see about getting more cables with SATA power, so you can eliminate all splitters and adapters.

Try this. After you unassign the physical cache devices, try creating a /mnt/cache folder, like what would happen if a container were mis-configured to use the disk path instead of /mnt/user I suspect the OP was filling up RAM with some misconfiguration, causing the crash.

I'm not aware of an easy way. My best guess at the most straight forward way to deal with this is a linux VM and pass through both disks using the /by-id/ location. I'm pretty sure unraid replaces the mdadm system internally, making it impossible to directly mount them.

Only if you care about the uptime on your server. If the memory errors are ever not correctable it will lock solid or restart to attempt to avoid further corruption. It's also possible the memory is fine, just being pushed past its limits. I'd play with slowing the memory down or maybe increasing the voltage just a tiny bit and see of the errors change.

Yes. As long as you have the license file that corresponds to the GUID of the stick, it will stay activated.

If that works, this version should work as well, apparently it uses the same chip, I assume this is what you were referring to when you referenced M.2 https://www.amazon.com/Internal-Non-Raid-Adapter-Desktop-Support/dp/B07T3RMFFT/ref=pd_sbs_147_3/140-7161017-3944644?_encoding=UTF8&pd_rd_i=B07T3RMFFT&pd_rd_r=84f3688b-e0bf-4c6f-9c4e-8c39590991fd&pd_rd_w=zNcnt&pd_rd_wg=8Z9Fk&pf_rd_p=7c0dad87-8a25-4c4f-9349-026039ea6cb3&pf_rd_r=RAV90H0GGEAF6CSFGNTS&psc=1&refRID=RAV90H0GGEAF6CSFGNTS I can see a using one of these in certain circumstances. Heh. I see one the reviews for this specifically mentions Unraid.

What LAN addresses are you assigned on those remote WAN's?

Recreate the issue, then download the diagnostics zip file and attach the entire file to your next post in this thread. Don't edit your current post, it won't show up as new and we won't know you added anything. Since the issue happens after a reboot, you probably need to collect a zip file from right before you reboot, and a new zip file after the share shows back up.

Does the issue occur when the array is properly shut down from the GUI and then booted back up?

Earlier you said you figured out the issue.

It's possible that has more to do with the SATA 3.3V reset issue than the controller.

Add a user script to copy some file to null every few minutes.

Kodi assumes you are going to play video, it doesn't know you only want to do database maintenance. Maybe this would work? https://forum.kodi.tv/showthread.php?tid=59800

Are you sure about that? VERY few motherboards actually have hardware RAID controllers, most use software RAID that must have typically windows drivers loaded in order to see the volumes.

Not relevant. Parity can stay valid during a format without an issue. All you needed to do was click on the empty disk and change the desired file system type, format it, and copy the data from the already occupied disk over to the freshly formatted one, then after that one is empty, change the file system on that one. Formatting only takes a couple minutes and doesn't effect parity. If both disks already have data, you would need to copy the data from one to the other, until you have one empty disk. There are several methods to do that.

I want my stream fixed. I'm partial to my low number. I like /discover/15/ What stream number are you using that works?

Possible, yes. But if you do a live snapshot, the result will be equivalent to what would happen if you did an unclean powerdown. Depending on the specific guest OS in combination with virtio tools and how it handles open files, journaling, etc, the resulting backup may or may not be useable. If the guest is powered off, the snapshot is guaranteed to be clean.

Have you applied the MSI audio fix?

Yep. Multiple OS's, browsers, all doing it. Forum function broke. Annoying.

Unraid doesn't work like that. A file is either on the cache or on the array, never both at once unless something went wrong, and if that happens it would require manual intervention to fix.

If they are, they are either only exposing specific containers, or they aren't following recommended practices. For now, NONE of the base services except wireguard on Unraid should be forwarded to the internet. Wireguard is built in now, and there are multiple other ways to get secure access in to manage your server, but Unraid SSH itself should not be exposed. Unraid is not a general purpose slackware box, it's just not meant to be used that way right now. We are slowly progressing towards being able to secure Unraid, but for now, keep it fully behind a proper firewall.

UEFI has changed that somewhat. I have seen anecdotal evidence that some motherboards can parse through some addon USB controller cards to boot UEFI. It would be a matter of trial and error. Lots of error. Maybe a success here and there. Getting it to work reliably with Unraid? Probably not.

You missed the part where he said he is not using unraid's IP, he set a different IP for this container. Which is fine, as long as you know how to fix all the stuff that breaks when you do that. Probably not a good idea to start changing to container specific IP's without a thorough knowledge of docker network behaviour. I have a pretty complex network, and I have yet to see a need to give any containers their own IP. Much easier to use reverse proxy to give them easily remembered domain addresses than trying to remember which service is on which IP.

You shouldn't don't need a video card at all for your primary stated goal, VNC should work just fine.

@Josh.5, could you please give a brief overview of what operations you do on /tmp/unmanic inside the container? I was experimenting with allowing my second server to help with the load, and I ran into some permission issues, it seemed to indicate it couldn't move the file from /tmp/unmanic to the final destination. So, I mapped /tmp/unmanic to a spot on the same mount point, and it appears to have recursively deleted my media files out of the folders in that mount, leaving the folders empty. I assumed with a description of "encoding cache directory" that I could safely map that anywhere I wanted. That appears not to be the case.