JonathanM

Try updating the BIOS / IPMI firmware on your motherboard.

https://wiki.unraid.net/My_Servers#How_to_access_your_server_when_DNS_is_down

Moved to lounge since this isn't really an Unraid topic. Q1 yes, but doubtful they would even bother to look unless you were causing other issues Q2 maybe, depends on whether you violate any of their specific TOS unrelated to the content, such as total bandwidth used Q3 not worth it, unless the decrease in speed puts you below the ISP's threshold of whether they care. If the artificial speed cap keeps you under the radar, then I guess it could be worth it. The ISP doesn't really care what you download or upload unless you bother other customers in some way, or you cause a disturbance that gets you noticed and they receive a complaint about you. The larger the ISP, the less any single individual will matter. A mom'n'pop ISP serving a few thousand customers or less in a rural area might notice large amounts of data transferred by one particular node.

Doubtful. BTRFS corruption seems to be more linked to hardware robustness, in particular, RAM stability. XFS seems to either handle marginal systems better, or just not report corruption, it's hard to know which for sure. My opinion is the extra space would be better served as a backup destination rather than a redundant pool member.

Until you get all your initial data load done, I recommend setting the shares to cache:no so it goes directly to the array. Pretty sure you can change the min free when the array is stopped.

I think I remember some people having trouble getting ASM1166 cards to show up in newer motherboards until they updated the ASM card's firmware.

Yeah, probably because there really isn't any updated info, it is what it is. What I'd LIKE to see is a way to have the end user download the files, and copy them to the USB stick, with a custom boot option. A talented developer could probably come up with a plugin to do it, but since you can't run it without rebooting anyway, the extra steps of downloading the new version and making a memtest USB stick isn't really that huge of a deal. Developing and supporting a plugin that alters the Unraid USB stick like that is probably too much work and risk for too little benefit.

It already includes the latest version that is licensed for 3rd party redistribution. Newer versions must be directly downloaded from the original website.

Have you tried disabling the motherboard port in the BIOS? Sounds like Unraid is still trying to use it as the default, so either disable the motherboard port, or set the 10Gbe card as eth0 in Unraid.

I do the exact same thing (multiple remote users and access for myself while traveling) with Emby. Why do you say Plex does it better? Genuinely curious, because I've used Emby like that for over 8 years now, and never felt the need to try Plex. How much better can it be?

Your screenshot shows different settings.

I'm probably not going to be very helpful with details, but here is how I'd proceed. 1. Ensure the array doesn't auto start, if it was set that way edit the /config/disk.cfg file to set auto start off. 2. Boot up unraid, mount the data disks read only (maybe with Unassigned Devices?) and inspect what's there. Probably can't do that with the disks assigned as normal, so may need to blow away the disk assignments. Make good backups of the flash drive BEFORE making any changes so you can revert.

Looks perfect to me. I'd add another step, after everything is complete do a non-correcting parity check, and be sure to keep an eye on the SMART status for all the drives through the whole procedure.

Sounds like you still had internet, but your DNS was down. Use your DNS addresses as the trigger to roll over to the second connection.

I hope you copied the data elsewhere before removing the disk, because parity can't move data from disk to disk like that.

ddrescue appears to do the same thing as safecopy, and it's already available for Unraid in nerdtools.

Why don't you do a backup inside the VM, like you would if they were bare metal machines?

I'd go a step further, personally I stop the array before doing a shutdown if at all possible. If the array doesn't stop fairly quickly, it's likely that the shutdown process by itself won't complete cleanly.

Technically with single parity you are unprotected for the duration of the rebuild, if you do the rebuilds in maintenance mode you can always return to the state just before the rebuild started if necessary. I agree with rebuilding one at a time though, for one reason you will still have all the data on the removed drives if something goes wrong. If you move (not copy) data the chances of messing something up greatly increase. Yes, there may be faster ways to accomplish what you are asking, but the added complexity would probably add more of your interactive time where the rebuilds are largely fire and forget.

Are you sure the version of Ubuntu you are using includes the virtio-net driver? Have you tried other network model options?

When setting a static IP on Unraid you must set the DNS manually as well. When the pfSense VM is down, Unraid will only be accessible by IP, and the device trying to access it must still have a valid IP in the same subnet. If the device accessing is restarted, or the DHCP reservation times out you must have a static IP on that device as well as Unraid.

Do you have multiple key files in the config folder?

That's what I do. I've never had any issues with it. Not sure what you mean, I'm running pfSense as a VM in Unraid.

IMHO this is a situation where Unraid must have a static IP assigned, ideally you set a DHCP assignment for the server and also set the IP in Unraid. You can make a note in pfSense to remind yourself to update the static IP in Unraid if you ever change things around. I also script it so other VM's and containers wait until pfSense is responding before they start. It takes a few minutes to get things all spun up after a reboot, but that only happens every few months.

Good deal. I know you aren't expecting the 2 old WD's to die immediately, but running single parity means you have no margin for error when it comes to drive replacement. Running with any single drive that you can't trust through a rebuild means you are just asking for a sudden unannounced failure by a drive you had no clue was on the way out. All drives fail eventually, the tricky part is predicting when.