Jacko_

OK thanks. I've done to swap so will keep my eye on the rebuild.

Also, any advantage/disadvantage of rebuilding parity from either of the parity disks? They were both added at the same time so they are probably a similar vintage. 34420 --- Power-on Hours so around 4 years old.

I did attach logs. No way around this Jorge?

I'm trying to add a new disk to an existing pool, but unable to due to the following message: If this is a new array, move the largest disk into the parity slot. If you are adding a new disk or replacing a disabled disk, try Parity-Swap. I've not encountered this issue before and I've not managed to find much information other than Jorge helping out here: I've downloaded and attached my logs and I've tried to have a dig through them to find where it might tell me what sector my parity starts but I've not had much look. Is this the same issue posted or something else? I would rather not have to rebuild parity on a new disk although I'm not against it. tower-diagnostics-20240908-2040.zip

I have narrowed the issue down to a docker container. It's either Binhex-Plex or Nexcloud. I turned both of these on at the same time so more testing required.

I have left it with just the VM running, all docker containers are turned off and the system is stable. I will now start turning VMs on two at a time to see if the problem returns.

I didn't get time to reboot in safe mode last night, but I did turn off all rocker images. With regard to the GUI, I normally always have this open in a tab and never seen out if control resource usage. I did fairly recently update the OS - maybe two weeks ago. This morning, Parity has competed without error and the system is still stable.with low resource usage and the state is still stable. I guess I could try turning each docker app on, doing 1 a day, to see if I can narrow the issue down. It will take a while to complete this as I have around 20 applications I will need to restart. Thanks Jorge for your help.

New logs attached. syslog-previous (1)

Hi Jorge, I stopped parity and the system was still up this morning but very slow to respond. When i did get to the GUI, CPU and RAM where both at 100%. I also got the same Samba message in the logs at around 04:30. The system has now crashed. Something is causing CPU and RAM usage to hang the system, but unsure what. I'll get logs again but not sure if it will yield much more than before.

Hi Jorge, Ok thanks for taking a look. I have not changed any hardware for over a year so it would be strange that all of a sudden i'm getting issues. Strangely it's always at night so i cant see it first hand. I use a VM on Unraid 8hrs of the day so i would know right away if it became unresponsive and be able to see what might have changed.

Not much to report in the above log, this is the system booting back up. This one attached runs until around 5am where the logs stop. Looks like its trying to spin down sd1 and is having issues with Samba. syslog-previous

Hi JorgeB, I have log file (attached) but it was generated this morning after having to ungracefully reboot the system so i don't know if this will be enough? The server crashed at around 5am this morning. I will take a look at the logs myself to see if anything looks untoward. syslog

Ok, i'll report back. Thanks.

Unraid has been stable, forever, until 2-3 days ago. Each morning i wake up to find my Omada software controller is offline and i know then i have an issue. I'm unable to access the CLI via putty in this case, and i'm unable to access the GUI and my Windows VM is not responsive either. I can access the CLI via a screen and keyboard and invoke a shutdown but while this starts it hangs and i have to ungracefully shutdown and reboot. Once rebooted Unraid is accessible, VM and Docker containers all come back up and parity starts automatically. Is my high disk usage the issue? Parity was at around 70% last night before i went to bed. I'm not sure what else could be the problem. tower-diagnostics-20240111-0851.zip

The bios can see it all. I haven't tried reseating it.