JonathanM

So having the file extension test, results in all video files being added to be processed, regardless of whether they meet the conditions of the other tests. If I parsed this correctly, what we really should be doing is putting the video test at the top and removing the file extension filter? I was working under the assumption that all conditions must be met, logic AND, and you are saying the tests are logic OR? Sorry, I'm having a hard time wrapping my head around the logic here, I assumed we wanted to first determine whether the file was a video file, then whether it needed to be video converted, if so add it to the queue. What I'm getting is that the file extension filter shouldn't even be in the list of tests, because we only want to check video status to add it to the list. Maybe I'm just thick, but this is doing my head in. I wanted to avoid running the video test on all the other metadata, image, and subtitle files, and only run the video check on likely candidates.

In the library management file test workflow block, are all conditions checked before the file is added, or does it add the file when the first matching condition is met? Is it possible that adding a plugin to that list in the wrong order could cause files to be added that should be excluded by other plugins in the list? I hope I'm being clear enough, I can't seem to construct a sentence that conveys what I'm trying to ask without confusing myself.

I spent 5 minutes looking over the support links you have posted, including poking around and finding https://hotio.dev/containers/plex/ which mentions the environment variable in question, but doesn't spell out the explicit need for it to be populated correctly so the app will work in bridge mode. Perhaps adding a line or two explaining how to fill it in properly on that page would help, at least it would help those who try to help themselves by reading the docs.

Each parity disk must be the same size OR LARGER than any data disk. Each parity disk operates independently. Each parity disk combined with all the remaining data disks can rebuild one failed disk. Parity disks are replaceable at any time, and can be replaced with a disk the same size as the largest data disk or larger.

That may not be the best idea, it seems that BTRFS is indeed more fragile, and XFS doesn't react as poorly to hardware issues, but that doesn't mean the hardware issues are gone. Properly behaved hardware doesn't have issues with either filesystem, so it's best to solve the hardware issues instead of masking it with a more forgiving filesystem.

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