JonathanM

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.

If you are willing to do the work, it's not super complicated to get the basic functionality you want. Here is the rough outline of one way to accomplish it. virsh commands can be used to start and stop VM's scripts can watch for the presence of files in a share. public or user password protected. when a script detects a named file or deletion of said file, it does an action So, your user would connect to a share, touch a file, and the VM would start. When the vm is stopped from within the guest, the script could delete that file, or immediately start the vm again, depending on what the script writer desires. Standard unraid users could be defined to restrict access to the controlling folders. You could have a share per vm that the script would watch, and only users granted access to that share could create the magic file. Yes, I agree it would be nice to have user level permissions in the management GUI, but that requires Limetech to make significant changes. My suggestion can be implemented NOW with a little scripting.

If all the files are readable I advise copying the content to an XFS formatted drive, then reformat the problem drive with XFS and use it for the destination of your next ReiserFS drive. I do not recommend nursing along ReiserFS drives.

Use

So a user share, not an unassigned device or other source.

Tools, diagnostics. Attach the zip file to your reply to this message.