JonathanM

Server grade equipment typically includes remote management capabilities, HP calls it iLO, Supermicro calls it IPMI KVM. When properly configured and secured through a VPN hosted on your router, you can log in remotely and interact with the keyboard mouse and monitor just like you are right in front of it, including the ability to power on the server. If you don't have server grade equipment, there are products to add that ability. https://pikvm.org/ https://www.kvm-switches-online.com/kvm-over-ip-gateways.html You also need a secure connection to your LAN, one very good method is a router with VPN server built in, another with more moving parts would be an always on computer with commercial remote access software like teamviewer in host mode. In any of these cases you need to make sure that when the power returns your ISP and router plus all related equipment get power back, so you can log in to the remote KVM and perform a controlled bootup of the server. The tricky bit is dealing with power restoration, you need to make sure that if you tell the UPS to power down after the computer is shut down, it will turn back on by itself when power is returned.

Your router is "helping" you by repeatedly trying to hack in to all connected devices, ostensibly in the name of alerting you to devices with weak security. https://community.netgear.com/t5/NETGEAR-Armor/Armor-vulnerability-scan-triggers-temporary-blacklisting-on-my/td-p/1982465

The batteries in a typical UPS are SLA, which wear out much quicker if they are deeply discharged. So first benefit is longer lifespan of the batteries. They are wear items anyway, typically 3-5 years at best, so the nicer you can be to them, the better. Second benefit is how long before you can safely use your server again. Recharge rates are generally about 1 / 10 to 1 / 20 of the discharge time, so if you are running on batteries for 10 minutes, it's probably going to be 2 or 3 hours before they are full again. You really don't want to get in a corner where the power comes back on for a few minutes and you think the outage is over and turn on the server, only to have the power go out again and run completely out of battery. Sometimes you might get away with it, but uncontrolled power outs are notorious for causing file system corruption. You must always stop the array properly before removing power. That's the reason to have a UPS, to avoid losing power with the server still running. As it should be. The last thing you want is for everything to start back up without your permission and supervision, especially after a power loss. Who knows whether the power is going to be stable, they might have to cut it back off to complete repairs that they didn't get done or the grid might not be settled yet. Why? That would mean if someone stole your server, your encryption passphrase would be conveniently entered for them, and all your files would be exposed. Encryption is a powerful tool, but it adds complexity that may not be worth the hassle. For example, an encrypted filesystem is MUCH harder to repair if it gets corrupted, so having full backups is that much more important. If the UPS properly supports it, yes, providing the server is the only piece of equipment connected to the UPS. Many people choose to keep their internet modem, router, and switches on UPS as well, that way when the power goes out they may still have a few minutes of internet if the outage doesn't take out your ISP equipment as well.

This is the wrong approach IMHO. There are multiple reasons, but bottom line it's much better to shut down the server after the power has been out for a minute or two, and leave as much battery remaining as you can. Typical power outages fall into two categories, flickers and very short transitions lasting less than 30 seconds or so, and full blown outages lasting an hour or more. A normal UPS without external battery capabilities is not meant to keep things running through a long outage, it's meant to allow safe shutdown ASAP.

https://<IPADDRESS>/

Unraid, or any RAID for that matter, is not a backup, it's high availability that allows the reconstruction of failed drives up to the limit of redundancy. It cannot protect against data deletion or corruption, user error, malicious acts, etc. You must have backup of any data you don't want to lose. Moving data from drive to drive, and especially the kind of mass migration you are talking about, is especially risky because of the number of things that potentially can go wrong. I highly recommend using this as an opportunity to set up backups, so you can copy data and set up applications at your leisure instead of worrying about accidentally formatting the wrong drive or corrupting data with a bum cable that you don't find until after the source files are deleted.

Best method is to delete the image file and set up a new one. Only takes minutes. https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564363

You could email support and ask.

That's why. 4GB is pretty much minimum.

The boot device (USB stick) is mounted at /boot, which as you say, has plenty of free space. All the messages you quoted about being out of space are referencing RAM, nothing to do with the USB free space. As Squid said, something or someone copied GB's of data into /tmp, which filled up and caused the out of space errors. /tmp is in RAM, so rebooting deletes everything copied there. If you have Plex configured to transcode to RAM without limiting how much space it can use, it's possible that did it.

How much RAM?

See if this gets you any further. https://forums.unraid.net/topic/74419-tried-to-upgrade-from-653-to-66-and-wont-boot-up-after-reboot/?tab=comments#comment-710968

Possible. USB2.0 is preferred for durability and compatibility reasons.

Try doing the manual method, format fat32, label UNRAID, extract files to USB, run makebootable as admin.

Did you use the flash creator app or did you prepare the flash manually?

I wouldn't bother with 9p, just connect to the normal SMB shares using cifs. In my experience cifs is faster than 9p.

Sounds like it's 64 bit capable. Can't hurt to try.

All you really need is the *.key file, which in 4.5 was likely in the root of the USB stick, but needs to be put in the config folder of the new USB stick. Which motherboard and CPU? Also, how many drives, and do you have a HBA in addition to using the motherboards SATA ports?

Since you are moving from such an old version, this section is probably the most applicable. I wouldn't bother trying to revive a new drive with the old files, just set up a new key with the only file to be transferred is your license. https://wiki.unraid.net/Manual/Changing_The_Flash_Device#What_if_I_can.27t_backup_my_device.3F

Most likely your issue is the permissions assigned by sab or sonarr. If you click on the dashboard icon for sab or sonarr and select the support option, it will link to the support thread for the app, searching that thread for permissions should give you the info you need.

The xxxxxxx.unraid.net address hasn't been updated to your new Unraid IP. The mechanism that does the renewal is still a mystery to me, as I haven't been bothered to investigate it yet. I assume it has something to do with the GUI SSL page, and provisioning the certificate. What triggers the detection of a local IP change to initiate the reprovisioning is unknown to me. Best practice is to assign a fixed address for your server in your router's DHCP config, so the local IP doesn't change.

😁 You don't particularly want your personal unraid.net hash public, I deleted it.

Try https://IPADDRESS/

What is your memory clocked at compared to the maximum supported by your CPU for the given number of sticks? The limiting factor is not normally the rating on the RAM, and the system will be very unstable if you exceed the capabilities of your CPU.

I wouldn't advise plugging in just a subset of the array drives for testing. Either all or none. That way if you do have a failed / failing drive you stand a better chance of recovery.