jonathanm

This. USB is the worst possible choice for external drive connections. SAS and eSATA are the only consistently reliable ways to connect to hard drives in a separate enclosure.

It's not unraid, it's the spec for the processor / motherboard.

Updated the latest nightly, and again, all subs are gone after the update. Which db file in the appdata is supposed to hold sub data? The db.json file has this "subscriptions": [], I've attached the dropdown on one of the videos, no "go to subscription" present. The info gives what looks to me a normal result The subscription page

Read this thread.

Sorry for the misunderstanding, I thought I was in the undervolting power save thread.

Possible reduced stability. It's almost like the inverse of overclocking. Circuits are designed and tested to run at spec, deviate and you risk bit errors. Depending on the quality of your specific silicon you might be fine, but you don't know for sure. How valuable is your data integrity? See @mgutt's reply, I was referencing undervolting, wrong thread.

Read this thread for more about why that's possibly a bad idea.

Sorry, I have no experience with proxmox.

That's not entirely true. The GUI editor only sees img, but you can manually specify the name of the vmdk in the XML. Just don't make any changes in the GUI editor, it'll blow away your manual edits.

Unraid is a cut down version of slackware, specifically stripped of everything that's not needed, because it loads into and runs entirely in RAM. We don't have the luxury of just slapping every single driver and support package into it, you would end up with a minimum 16GB or 32GB RAM spec. Before VM and docker container support was added, you could have all the NAS functionality with 1GB of RAM. Now, 4GB is the practical bare minimum for NAS, even if you don't use VM's and containers, and 8GB is still cramped. Adding support for a single adapter that works well in slackware, providing the manufacturer keeps up with linux kernel development shouldn't be an issue. That way we can tell people if you want wifi, here is a list of cards using that driver that are supported. It's the blanket statement of "lets support wifi" that doesn't work. BTW, even if we do get that golden ticket wifi chip support from the manufacturer and Unraid supports it perfectly, the forums will still be bombarded with performance issues because either their router sucks or their machine isn't in the zone of decent coverage, or their neighbours cause interference at certain times of day, etc. Bottom line, wifi on a server just isn't ready for primetime yet. Desktop daily drivers, fine. 24/7/365 servers with constant activity from friends and family, no. It's much easier support wise to require wired. If the application truly has to have wireless, there are plenty of ways to bridge a wireless signal and convert it to wired. A pair of commercial wifi access points with a dedicated backhaul channel works fine, that's what I use in a couple locations.

Exactly. Name each instance so it's easy for you to figure out which database serves what. That way when something gets ornery, you can deal with only the one app. Use the docker folders app to keep things tidy if having many container icons showing causes you OCD pain.

Never, ever. Not even for a moment.

I doubt that you will see a speed decrease, in fact I suspect things will work much faster with the memory working in sync with the processor. Pushing speeds past spec causes multiple retries for data that is corrupted but correctable and crashes when the corruption is uncorrectable, which should be eliminated when things are running in spec.

They can, but the fact that you are asking means that you shouldn't, at least until you understand the consequences of sharing the same engine for multiple apps. The short and sweet of it is, if you mess up the database for one app, and don't have the technical knowledge to manually fix it, you will be stuck losing ALL your databases to recover the one rogue app. Containers share resources, disk space, cpu and ram. Whether you spin up 2 db containers or one, the server usage is the same, each additional copy of the container only consumes the space and other resources used by the additional data of the apps using the database, just like a single container would. The only downside to multiple containers is keeping track of the port numbers, but there are 10s of thousands of port numbers at your disposal. If you want to educate yourself on database management, on the surface it's not that bad, but it's a deep field of knowledge. Much easier to use docker containers the way they were meant to be used, as individual building blocks that can be discarded and replaced as needed without effecting other containers.

Be VERY careful when implementing something like this script. I would add a kill feature of some sort, where the script looks for the existence of an arbitrary file on the flash drive before starting the VM, that way you could disable the auto start for troubleshooting. Blindly force starting a VM on a schedule is a bad idea for multiple reasons.