JonathanM

Do you have any status emails from unraid? Diagnostics or syslog?

Discussed many, many times. Here's one discussion on error recovery. Search this site for red ball, disk disabled, etc. https://forums.unraid.net/topic/58028-parity-check-finished-with-errors-not-sure-how-to-proceed/?do=findComment&comment=569114 Typically CRC errors aren't bad drives, more often they are bad cables. If you have notifications set up, Unraid will tell you when one of the monitored smart attributes changes.

Then either a. You are running the wrong container, this one is specifically set up for VPN b. You posted in the wrong support thread. c. You want to run a VPN for torrents but are having issues?

This.

ssh into the Unraid, use virsh commands. This assumes your container has ssh, or ssh can be installed in it. or, ping the VM's IP to see if it responds. I can think of numerous ways to get info, but without a specific use case it's tough to suggest what the best method would be.

Unraid doesn't work well with RAID cards, it's much better to use plain HBA IT mode if your controller supports it. Unraid is built around having direct access to the drives without the RAID intermediate layer.

Except that every feature added directly to the OS consumes RAM, whether you use it or not. Unraid isn't like pretty much any other OS that runs from a drive, everything is installed into fresh into RAM at boot time. That's why Unraid doesn't include drivers for everything normally supported in linux, because all that space in RAM would be wasted for 90% of users. Every feature that is included in the stock base of Unraid must be carefully evaluated whether or not the increase in RAM required to store the files used is worth it. It's kind of a double whammy, the files consume space on the RAM drive, whether or not you use them. When you run it, it uses RAM as well, but as you said, that part is optional, you don't have to run it. Features added using the docker container system DON'T take up RAM, as those reside on the regular storage drives, and only use RAM when run. As Unraid has added more features, the RAM requirements have increased significantly. As a NAS only, 1GB of RAM was plenty. Currently, even if somebody only needs the NAS functionality, the bare minimum is 4GB, and even that is too tight for some operations. That's because all of the added features take up RAM, even though they aren't used. As time goes on, and the normal amount of RAM in older systems that people want to repurpose as NAS devices increases, then adding features becomes less of an issue. Right now though, we still regularly see people trying to get Unraid to run on 2GB of RAM.

If /mnt/user/cache exists, something is wrong already. There should NOT be a user share named cache. It should only exist as a disk share.

I'm not, directly anyway. I keep database backups, which I should be able to apply to a fresh instance. I have all my relevant unifi ports exposed on a subdomain, so it's easy to spin up another unifi controller on whatever is handy and point the port forwards to the appropriate ip and internal ports.

Success, so far, I'm running 5.14.23-ls76 now. So, to summarize, to those who wish to move from LTS (5.6.42) to 5.14.23-ls76, you must first use 5.10.24-ls21 to upgrade the database. At no point did I change anything in the template EXCEPT the repository tag. Everything seems to be working seamlessly. I do keep backups, so I wasn't too stressed about breaking things beyond repair. I suppose I may start rolling upgrades to some of my sites after business hours. People get irritated when I take down wifi unnecessarily. 🤣

Looks promising. Database update in progress. This may take several minutes.

Yeah, that's the tag page I've been working off of. I'll give 5.10.24 a shot. Any guesses on which tag I should try first? 5.10.24-ls21 5.10.24-ls20 5.10.24-ls19

5.9 gives this message We do not support upgrading from 5.6.42. 5.7 same message.

Not with any authority. Good motherboard manufacturers issue firmware updates to keep abreast of IPMI security issues, for example my Supermicro X10SL7-F which is several years old got an update that added HTML5 instead of older java builds. So, it depends on the specific board and the firmware versions available and currently loaded.

Yeah, that's why I recommend rolling your own autostart script with easily edited conditionals. The brute force autostart that is built in has severe limitations IMHO, Squid's plugin container autostart with network and timing conditionals should be the model for Unraid's built in autostart for both VM's and containers. It seems like we took a step back when order and timing were added to Unraid, prompting the deprecation of Squid's plugin.

Personally I don't rely on Unraid's built in VM autostart, as I have some external conditions that need to be met before some of my VM's come up. Scripting VM startup is very easy, virsh commands are well documented. Since you have a use case for starting your VM regardless of array autostart, I suggest using a simple script to start the VM. However, as JorgeB noted, I would recommend a conditional in the script to allow you to easily disable the auto start if needed for troubleshooting. It's very frustrating to get into a loop that requires you to manually edit files on Unraid's USB to recover.

If CPU were the only load involved, yes. However, in a NAS, typically hard drives are a much bigger factor in cooling, so the faster you can get your tasks finished and the drives spun down, the better. Unraid typically needs the most power / cooling during parity checks or disk rebuilds, and if your case ventilation can properly handle that, your CPU TDP is unlikely to be a factor. Choose the CPU with the maximum passmark / cost or other benchmark in a particular die generation, the idle power of most similar generation chips is pretty much identical. It's only full throttle that makes a big difference. When you move to a new die type, that's when things change.

Why? Picking the lowest TDP among chips with the same die layout is likely to increase overall power consumption for a given workload, so I wanted to make sure you really need low TDP, i.e., you are dealing with a heatsink / fan / airflow restrictions.

Since you have been keeping up with the various versions, do you have a recommended path to get from LTS (5.6.42) to 5.14.23? It's not possible to go directly there, I tried. The mongodb engine complains about upgrading the data files, even though the log says LTS is running mongodb 3.4.24 <attempt to start 5.14.23> ** IMPORTANT: UPGRADE PROBLEM: The data files need to be fully upgraded to version 3.4 before attempting an upgrade to 3.6; see http://dochub.mongodb.org/core/3.6-upgrade-fcv for more details. <massive snip after reverting to LTS> MongoDB starting : pid=1100 port=27117 dbpath=/usr/lib/unifi/data/db 64-bit host=f73901575e14 db version v3.4.24

What about the internal motherboard header ports?

These are the ones I use and recommend.

The image shows the internal and external ports reversed.

Do you have a UPS that's working well?

Yes, please. Most motherboards with this function can toggle it on and off in the BIOS, perhaps investigate this option as well.