JonathanM

When a drive fails a read request, all the rest of the drives are read, the failed read request is fulfilled from the resulting parity calculation, and that data is written back to the drive that failed the read request. If that write fails, then the drive is marked as invalid (red X) and the parity calculations are used for all further I/O to that drive slot, the physical drive is no longer accessed. That is the total extent of what Unraid does by default, anything beyond that would need to be handled by recovery from backups.

You should attach the photo and your diagnostics zip file to your next post in this thread. No need to link to outside sites.

No.

Yes, I exploit this for a bit of security through obscurity. I have multiple file management containers with different levels of array access, all running on the same port. The least dangerous container is set to auto start. None of the more dangerous containers will start while the neutered one is running, so gaining full access with Krusader means shutting down one container and manually starting the other. They all answer on the same port, so it all looks the same from the client end.

Exactly. Look at the container paths in this screenshot. /tv and /downloads are where /mnt/user/Media and /mnt/cache/Downloads will appear respectively. Docker containers are like miniature computers all isolated from the host. They only have access to what you tell them.

If it's a member of the parity protected array, every bit of it is used to calculate parity. File system or not, usable data or corrupt data, all bits of all drives in the main array are part of parity. Formating and the resulting empty file system are all bits that must be emulated if the drive fails, so nothing is left out.

The dialog you are showing is for 1 off downloads, the subscription / playlist dialog has other options.

??

Have you tried https://github.com/Tzahi12345/YoutubeDL-Material

Create a shortcut / bookmark?

Which browser?

Have you stopped and restarted the array? It's possible a reboot may be needed, but I don't think so.

Blank on all three machines. No, but I am VPN'd through pfSense to the second subnet, so the gateway for the pair of machines that flip flops access depending on which subnet I access it from is different from the gateway at one end of the VPN. Rereading that sentence, it's very hard to parse, let me know if I need to clarify. It doesn't show any, and it requires SSL to set to yes, which I am not about to do. I don't do exposed remote access to any Unraid machines, strictly over router hosted VPN's only. What would the issue be of changing the local unsecured access link to be the current IP? That way DNS can't effect access. Also, you could offer the https://<LAN IP> link with a tip about browser insecure access warnings for people who's LAN IP doesn't resolve to the correct SSL link for whatever reason. Seems like we see at least one or two people a week complaining about losing access to the management GUI when their unraid.net link doesn't resolve to the correct local IP.

Unraid parity is realtime, so any writes update the parity drive(s). Writing is limited to the slowest participant, even more so when simultaneous writes to different data drives are done. It's already been said, even though Unraid will allow you to configure USB drives in the parity array, it's far from ideal. Feel free to experiment, the worst that can happen is lost data, so as long as you keep good backups all you will be out is time. The good backups thing is just general advice, regular RAID or Unraid is high availability when a disk fails, there are MANY more ways to lose data that don't involve drive failure. Accidental or malicious deletion or corruption must be restored from backups. Also, the second parity slot is very unique, the math used to calculate it is more complex than the simple sums used on parity slot 1, so it takes more CPU to compute. It's perfectly ok to only have one parity disk in slot 2, but that disk is not valid in slot 1, if you remove it from slot 2 and assign it to slot 1 parity will have to be recomputed from scratch.

Sounds like you solved it.

System logs, on a RAM drive.

That is a fairly complex task, as Unraid requires a physical USB drive to start the boot process, store persistent settings, and validate your license. Do you have full IPMI or similar access, and can you physically lay hands on the machine if needed?

XFS RAID not possible at this moment, BTRFS only. RAID5 is available but not widely used.

https://wiki.unraid.net/Manual/Storage_Management#Multiple_Pools

You can have multiple pools, each with their own BTRFS RAID profile. The main array is restricted to Unraid's special arrangement of single or dual parity with each data drive having an independent file system.

I do not have remote access enabled, and the my servers page generates a red unlocked access link. However, the link it generates does not resolve. It points to http://servername.local ping servername works fine, ping servername.local doesn't resolve. Is there a setting somewhere to change the format of FQDN that is generated, or simply use the IP? As an aside, ping servername.my.domain.com does resolve internally. Also, I still have the issue where one of two servers on the same subnet always shows access unavailable, even though both show online, and both are available with the local IP and servername. The strange part is that which one of the two generates an access link and which one shows access unavailable switches depending on the local subnet I'm accessing the page from.

If you can't get the flash working again, transferring the license will involve talking directly to Limetech instead of using the automated process. Not a big deal, they are quite helpful. Do, however, try to time your failures so they occur during normal west coast USA working hours for fastest response. 🤣 https://wiki.unraid.net/Manual/Changing_The_Flash_Device#Notes_about_replacing_your_registration_key

Pretty sure he meant reflash without the BIOS.

Until you know, you really can't size a UPS accurately. In a nutshell, once you pick a load value to shoot for, you find the number of minutes needed to shut down your system from a worst case scenario, i.e. all your containers and VM's busy, and look at load charts for various UPS models. Cross from the number watts to double the number of minutes, so hopefully your system will be fully shut down before the batteries are 50% depleted. https://www.apcguard.com/Smart-UPS-Runtime-Chart.asp That's an example of the type of data you are looking for. Say your load peak is 400W, and it takes 5 minutes to shut down. The smallest UPS I would recommend would be one of the 1000VA models. This assumes that your shutdown will be started within a minute or so of the power outage. Keep in mind that a battery backup is meant to provide a safe controlled shutdown ASAP when the power goes out. It is NOT meant to power your equipment through an outage, unless you upgrade to the multi kilobuck models that have extended battery modules. Also make sure that any necessary network infrastructure like switches and modems are accounted for in your load calculations. Depending on how you use your server, you may also need to have battery backup on desktops that use the server so they close out properly and don't leave the server with open sessions and file handles. In general power outages aren't planned, so assume it will happen at the worst possible moment and calculate from there.