JonathanM

Tools, New Config will allow you to assign the drives any way you want. Any disks you put in the parity slots will be completely overwritten.

Let me turn that around. Why does Unraid itself need to run through pihole? The issue that comes up over and over again is when people run pihole as an application on Unraid, normal and necessary communication is blocked during the startup process until the pihole app is running, and when the array is stopped, Unraid is no longer able to communicate. This isn't about whether pihole as a concept is capable of allowing Unraid to work through it, it's about running a necessary network service as an application on Unraid that doesn't run during initial startup or during normal shutdown.

https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/?do=findComment&comment=696184 @Squid, this container is "special". It doesn't like remapped ports.

You only changed the template, not the app itself.

Does the supervisord log show a successful connection to the VPN? Did you put your actual credentials in for the VPN instead of the placeholders shown in your screenshots?

forwarding is pretty much a necessity for successful torrenting

That is not a condition that is considered normal, it can result in things happening that seem strange. I.E. you delete a file, refresh, and the file is still there, because the second instance is now revealed. It's normally not something you do on purpose, typically it's considered an error. If you are interacting with the user share system normally it can never happen. The fuse system does work down the disks one at a time, the first instance of that file name will be the one presented in /mnt/user. I can't remember exactly what the order is though. Order is not configurable, beyond renaming devices. Bottom line, you are colouring outside the lines on this one, things may not work as desired.

BTW, I'm not sure that is a tested configuration. It may or may not work without modifying other parts of the container because of how locked down it is, @binhex would know.

AFAIK yes. Two different concepts. The VPN_INPUT and OUTPUT ports are to punch holes in the delugevpn containers internal firewall. The container is sealed up pretty tight to keep the VPN connection secure from accidental real WAN IP exposure.

Posting the diagnostics after the crash and before you reboot Unraid should help figure out what is happening.

You don't. That enclosure is going to be an issue for parity check or disk rebuilds, it will be speed limited. If you can internally change the wiring so you have 1 external SATA connection per drive it would be ok, or if you could switch out its backplane to one that supports SAS and connect it to a SAS HBA that would work too.

Do you have a spot to temporarily hook that old drive up and see if it will mount in Unassigned Devices?

Not really. Maybe specify the full path to curl? /bin/curl or wherever it happens to live inside the container.

High end and newer SSD's may not need trimming, as they have very good internal controller management. However, your "bunch" of small old SSD's probably would need trimming to stay at their best.

I think it would be much simpler to set up a backup client in the VM, that way no conflicts with open files and stuff. I use the UrBackup container to successfully automatically back up several machines, both linux and windows.

Trial license needs internet to start the array, not needed while it's running. Paid license does not need internet. Obviously updates and such need internet, but not full time.

Your title is misleading, as it's not Unraid that you need to be troubleshooting. Since the boot process never reaches the flash drive, the first suspect would be your BIOS "helpfully" seeing the new drive and assuming you want to boot from it instead of the flash drive.

blkdiscard for SSD devices is quicker.

Do you already have valid parity?

What exactly did you do? Were you able to continue to use your appdata and existing database, or did you start over?

Have you tried using CA appdata backup as the source for the restores? Or back up the appdata using an archive method that preserves links and permissions? Obviously the backup needs to be taken with the container in question exited normally.

It would be better if you could set things so it downloads directly to the array. As it is right now you are wasting writes for no good reason. Better to just write once directly to the array, then once your download pattern gets back to normal you can use the cache to keep the array spun down.

That would be my first priority, because parity by itself has no data, it requires all the remaining data drives to be in exactly the state they were when parity was last valid to reconstruct any data. All operations on the good drives must be strictly read only. However, if you can get the data drive recovered, you are golden, and no pressing need to keep all the other drives exactly as is.

That is the traditional way of doing things in Unraid. There is a reason for the new methods though, here is the main example. The single share subfolder methods take advantage of linked files to allow multiple apps to see the same file with multiple paths, for example when a torrent is done downloading, instead of copying it to the media destination and taking up double the space until the torrent is deleted, the same file can be linked to both torrent client and final consumption destination. Whether the space saving and extra complexity is worth it to you is a question I can't answer. If you only keep torrents until 1:1 or the equivalent, then it's probably not worth bothering. If you try to keep massive amounts of content seeding, then it's probably worth figuring out and maintaining the more complex setup.