JonathanM

There are so many other factors that could effect your situation, such as the overall health of the system, the reason(s) why the drive was disabled in the first place, etc, etc. If you don't feel competent to make the decision on your own after examining the diagnostics for issues, I suggest attaching the complete diagnostics zip file to your next post in this thread. Unraid disables a disk when a write to it fails. that means SOMETHING went wrong, and if the disk is perfectly healthy, simply rebuilding isn't going to fix that. Preclear may reveal issues with the disk, if it does, you need to use a different disk. If preclear DOESN'T find anything wrong, then whatever happened to cause the failed write is probably still lurking, waiting to cause issues with the rebuild. Either way, you need more information before you can make the correct decision.

You may be able to get it to function as a NAS only with 2GB, but version upgrades will have to be done manually, and I doubt you will be able to get the docker system running. VM's are a flat no. 4GB is a bare minimum for basic functionality, 8GB if you want to play with a VM.

How much RAM do you have? I can't seem to keep more than 1 or 2 subs unpaused simultaneously, so I'm stuck walking through the list 2 at a time, or manually checking on youtube for content and unpausing that channel to catch it. Leaving 3 or more channels running on auto causes crashes within minutes of the code starting to look for content. This server has 32GB of RAM, but I've got quite a few things running constantly, Unraid shows around 65% RAM committed on the dashboard normally, but it seems this container wants 8GB or more at times. Also, I'm currently running jti989 / robo3t-docker to deal with the mongodb when needed, several times I've had to stop the youtubedl container and change all the subs back to paused in order to get back in to the youtubedl GUI, otherwise the container would just keep crashing. The robo3t app works well enough, but I haven't figured out how to make the connection entry persistent. No big deal, just have to put the server IP in after accepting the license each time. You mentioned running a mongodb tool, which one are you using? I suppose I could just run the tool on my desktop, but having it as a container on the same server is much more convenient.

emby FTW

ark.intel.com

Always, always, ALWAYS check the intel ark site to see if the CPU you have in your cart to purchase has the feature set you are expecting. Voice of experience talking here. Sometimes vendor descriptions get copy and pasted without verifying the actual details.

Do you have a current list of the drive serial numbers and which slots they were assigned to?

No. Read the top pinned post in this subforum.

Why not?

I personally like the SE9 USB 2.0 version, but they are getting harder to find. https://amzn.com/dp/B01MRIEOHR/

Prepare a new flash drive as usual, then copy the config folder from your backup to the new drive overwriting all.

How long ago was this? Have you made any hardware changes since the backup was made?

Yes, contingent on parity being in sync. Given the totality of the shenanigans that went on to get you to this point, it would be prudent to do a parity check and verify it completes with ZERO errors before doing a drive replacement.

If you make a copy of the moved file back to a local machine, do they still play?

This plan will result in the complete loss of the data that was on the failed drive. Please don't do anything without explicit instructions.

Yes. I'm talking about physically changing the drives after setting the new config to clear the assignments, but not starting the array until all the drives are correctly in place. I'm afraid since he has valid dual parity that after replacing the drives he will trigger a rebuild on those drives, overwriting the good info instead of rebuilding parity with the old good drives. Perhaps I should be clearer with the physical vs. logical assignments, I read this and was afraid he would put the original drives in and immediately assign them to their intended slots, not realizing the need to create the new config before assigning the drives or starting the array.

Missed that. Good catch. We shall see.

Try making a full backup of the files on the key that's currently working and put them back on the original key that the license actually links to.

Just to make it perfectly clear, if you only have 1 container, the delay doesn't do anything. Container starts, waits X seconds as specified, moves to next container. I really wish it was the other way around, but I get around it by putting a container that doesn't need network in the first slot and giving it a long (300 seconds) wait to ensure the rest of the box is settled and ready to work.

Maybe safer to do the new config before putting the original drives in, that way Unraid can't try to write the corrupt data to those disks as well. Just be sure you have an accurate list of which drives are supposed to be in which slots and don't allow the array to start until everything is assigned correctly. Personally I would disable array autostart first thing.

Clearing cache fixed it on the windows box, haven't been able to try the mint yet. Very strange.

Well, I'm in the middle of trying to migrate, and it's crushing my server. The initial "Transfer DB" took only a few seconds, but it only imported half of my files. (I had 32K showing in the local DB, only 15K showing after the transfer said it was done.) When I restarted the ytdl container, it immediately started finding files and adding them to the DB (good!) But the server is groaning, very unresponsive (bad) Hopefully it recovers without crashing. Progress, sort of. It added about 7K more files to the DB, then "recovered", as in loaded the GUI and became responsive. I restarted the server using the button in settings, and once more it's crushing the server while it adds files to the DB. Hopefully I only have a few more cycles to go before it catches all 32K files.

If the only thing they did was look around and download files, there is no way I know of to tell after the fact. However, most intrusions aren't just for browsing, they are trying to make money. They do that by either encrypting your files and asking for ransom to decrypt them, or they try to install remote controlled software that mines cryptocoin, attacks other machines, or does whatever they tell it to do. So, no, odds are that they didn't gain full access, or didn't attack it properly and Unraid's unconventional architecture foiled their efforts.

Because of the way Unraid is built, typical hacks are undone every reboot. The go file is about the only place I've seen ongoing hacks planted. Other than that, if all your data is there and not deleted or corrupted, and there are no unexpected containers or VM's, then you are probably ok. There is no way I am aware of to see what was accessed.