JonathanM

https://www.seafile.com/en/product/private_server/

Make a backup copy of both flash drives. Overwrite the config folder with the other drive. Put the license key file back with the drive it goes to. The license key needs to stay with the physical flash drive, the rest of the config folder gets moved over.

Are there any failsafes to keep folks from wiping mounted drives?

Have you unplugged and reseated all connections? Have you checked all the fans to make sure none are obstructed by cables that moved in transit? Is the CPU heatsink still seated properly?

Probably not, that's too fast for even a healthy drive, but it sounds like the drive has either died, or is close to dying. Can you get a SMART report?

That screenshot appears to show the root folder of the krusader container running on Unraid, not Unraid's OS folder. You need to use the console or ssh login to get to Unraid's root, type mc if you need a more graphical way to navigate around.

If it was healthy, yes. A failing drive can be painfully slow as the drive tries to access bad spots.

Try asking in the support thread for SWAG There is a link in the first post about migrating.

Try manually upgrading. https://docs.unraid.net/unraid-os/manual/upgrade-instructions/#manual-upgrade-or-downgrade

Because the template maintainer is no longer interested in keeping it maintained. The post directly before yours is an open invitation to anyone that wants to pick up the torch to go ahead. If you want to donate your time to bring it back and maintain it, I'm sure many would be grateful.

Yep, I totally missed they only had one data drive. Preclear will do it, just be sure you are operating on the correct drive.

Running Unraid as a VM is not officially supported. I moved your post to the correct area, hopefully someone familiar with running it in proxmox can help. If you can recreate the crashes running Unraid bare metal you can open a new topic in the general support forum.

Parity doesn't have a file system, or recognizable files. It's theoretically possible to run forensic data recovery software on it and possibly see fragments of content, but at a glance there would be nothing to even attempt to recover. If you really feel the need to remove any traces, you can unassign it from the array and and run a preclear on it, but unless you have a reason to believe you are targeted for an investigation I wouldn't bother.

Easiest method would be Dynamix File Manager. There is no automated process, you will need to manually move files from drive to drive.

Preclear is always optional, it's an addon that is used to zero and test a drive before it's put into a parity protected array. IF the drive being added to a parity protected array slot does NOT have a valid preclear signature, then the normal operation of clearing the drive by writing all zeros is started, and the drive is not available for formatting and use until that clearing has completed, so adding the drive doesn't invalidate parity. Preclear was developed to allow you to do that step BEFORE adding the drive to the array, so it could be formatted and used immediately. What JorgeB was saying, is that using the preclear utility on a solid state drive is not recommended for several reasons. If you are using SSD's in the parity protected array, clearing is still needed, but preclear isn't. Using SSD's in the parity protected array can reduce their performance, TRIM is not possible, and write speed will be limited by the parity drive.

Make a copy of the old usb key to another machine. Do this again, but use the old usb key instead of a new one. Copy just the config folder out of your backup to the old USB key.

No, but it is necessary to test it once it's in the Unraid server. Good memory can have errors if the BIOS settings are wrong or out of spec, or the motherboard isn't fully compatible. Your Unraid rig complete as you want to run it must pass a memtest with zero errors for as long as you can stand, preferably 24+ hours. Since Unraid installs and runs in RAM, it's extremely critical that the RAM operation must be flawless. Parity check is not a reliable test for good RAM. You could have a bad stick or some fault that doesn't effect the parity check that still causes other issues.

nomachine installed on both the VM and the machine you are using to view it.

It's the percentage of the docker.img file that is in use. If it starts growing rapidly that usually means a container is not configured properly. If it's been close to that figure for a while and is slowly increasing a little only when you add new containers, it's probably normal. With the docker service stopped you can increase the size of the image file, but don't just increase it if you can't point to a reason it's getting larger, if something is configured incorrectly just making the image bigger delays the inevitable troubleshooting. It's got absolutely nothing to do with RAM.

That is a USA 110v version, if you looked at the UPS he referenced, it is NOT a 110v. Power meters must match the regional requirements. What I linked to IS available if you live in Australia, to see that you must select an AUS delivery address.

No. You can power off and change sticks or whatever as soon as any errors show up. Don't attempt to run Unraid on a machine that has any memtest errors, you will likely corrupt your data. After you can complete many (preferably at least 12) hours of memtest with no errors shown then you can try to run Unraid. However, not all memory errors are caught by memtest, but it's a good start to weed out obvious problems.

Depends. If the error count stays the same, then you are probably fine. If it keeps increasing, I'd return the disk for a new one. Don't manufacturer warranty return it if possible, the drives you get back from a manufacturer warranty swap are typically refurbished. Return it for credit and get a new one if possible. If the count stays at 11 and never increases, I'd keep the drive. Regardless, you always need to be alerted to changes in disk health, you shouldn't need to wait until you log back in. Make sure notifications are set up and working. You should be getting a daily "everything is OK" notification so you know the server can contact you with errors.

That will work for some applications, but based on a brief search I don't think that will work with torrents. From what I read torrent clients embed the port they see in the traffic for returns, so if that port is remapped it won't connect. Hopefully there is some way around that.

This looks like the correct option to me, mainly because if the port changes, it's likely that the network is "down" anyway until the application reconnects. While you are playing with all this, I have a current scenario that you may be able to take into consideration. I run a couple downloaders through delugevpn, but when the vpn container restarts or is updated, the downloaders are unable to connect out until I restart them afterwards. I'm unsure whether that's a consequence of how docker networking works, or simply the change in IP not being detected properly. I know restarting and / or updating the master container is much different than it simply detecting a port change, but it's a scenario that would help automation if it were covered. With that in mind, do you have a method you are looking at to blindly reconnect when needed? Maybe the master vpn container could have variables defined with dependent container names to blindly restart when the connection changes? Can a container manipulate another container like that? Or would there need to be a "helper" script running on the host to monitor and restart things?