trurl

Most of your disks are very full, and some are still ReiserFS. Why are you logging Mover? Jan 15 03:53:42 Tower kernel: md: disk3 write error, sector=1953336760 Looks like disk3 got disabled Jan 15. Do you not have Notifications setup to alert you immediately by email or other agent as soon as a problem is detected? You also have problems communicating with cache and disk1. Are these all the same controller? Disk3 needs to be rebuilt of course, especially since it is out-of-sync more than a week. But I'm not confident about the rebuild with these other issues. Jan 8 19:31:51 Tower kernel: ata1.00: ATA-10: KINGSTON SA400S37480G, 50026B778227C383, SBFK71B1, max UDMA/133 Jan 8 19:32:09 Tower emhttpd: import 30 cache device: (sdi) KINGSTON_SA400S37480G_50026B778227C383 Jan 23 07:08:31 Tower kernel: ata1.00: exception Emask 0x10 SAct 0x1800000 SErr 0x280100 action 0x6 frozen Jan 23 07:08:31 Tower kernel: ata1: hard resetting link ... Jan 8 19:31:51 Tower kernel: ata2.00: ATA-9: HGST HDN726060ALE614, K8H5GNMD, APGNW7JH, max UDMA/133 Jan 8 19:32:08 Tower kernel: md: import disk1: (sdj) HGST_HDN726060ALE614_K8H5GNMD size: 5860522532 Jan 23 03:38:34 Tower kernel: ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x280100 action 0x6 frozen Jan 23 03:38:34 Tower kernel: ata2: hard resetting link Let's see if @johnnie.black is still awake and if he has anything to say about your controller or suggestions about how to proceed.

https://forums.unraid.net/topic/50866-help-please/?tab=comments#comment-501310

SMART for that disk looks OK. But you should always go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. Diagnostics include SMART for all disks, syslog that might give a better idea of what happened (if you haven't rebooted), and many other things that give a more complete understanding of your situation. I will wait on the diagnostics before making any recommendations about how to proceed.

How did you get those diagnostics? Do you mean you can log in to the webUI but not login to the command line? Or what do you mean? And why do those diagnostics not include the syslog like diagnostics normally do?

SSDs are not recommended in the array. They can only be written as fast as parity, they can't be trimmed, and there is some concern that some may invalidate parity. Put them in cache pool.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

It should be possible to just assign existing parity2 to the data slot you want to replace and let it rebuild, but I'm not sure if Unraid will allow that without New Config. And if New Config is necessary the invalidslot command would also be required. So I will punt to @johnnie.black on this one. While waiting, go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post.

Simplest way to get your log space cleared is to reboot.

Your system log is filling with errors on multiple disks. Check connections, controller.

Do you have a mapping to Unassigned Device paths for your Krusader docker?

I assume you don't actually have any of these drives assigned, but after you do it is best if you don't refer to parity as drive 1. Drive 1 is the first data slot. Fastest way to copy would be to use the Unassigned Devices plugin to mount the WD NAS on your new server and use one of several ways (command line, Midnight Commander, Krusader docker, etc.) Simplest way to copy would be to just use your PC with the WD NAS to copy its files over the network. I strongly recommend NOT caching the initial data load. Some even wait and add parity till after the initial data load so the write speed won't be impacted by parity.

Your symptoms suggest a flash problem so switching the port may be the solution. Your "system" shares, appdata, domains, system, have files on the array. You probably created dockers/VMs before installing cache so they got created on the array. Best if they are all on cache and set to stay on cache. Your system share specifically is set to get moved to the array. Mover can't move open files so Docker and VM Services would have to be disabled to get them moved. Do you understand the Use cache settings?

Are you saying you already added the new disks to new slots in the array? The correct method would be to simply replace each original disk one at a time with a new larger disk and let each rebuild. Then the new disks would have contained the data from the old disks. No copying needed. If you have already put the new disks into new slots in the array, and you don't intend to keep the original smaller disks in the array, then you have the additional problem of removing them even if you do copy the data to the new disks. So, what have you done? Are the new larger disks already added to the array? Go to Tools Diagnostics and attach the complete diagnostics zip file to your next post. And answer my question Then, don't do anything else without further advice.

Or maybe bad slot for the RAM. Definitely some kind of RAM problem if memtest is giving any errors. The method is to try each module by itself in each slot so you can tell which module or which slot is the source of the problem.

Just some advice on using the forum. Better to put new information in a new post so the thread is marked as unread and everyone can see there is some reason to look at the thread again.

After starting would have given more information. Are you booting from a USB2 port? You should.

Have you done memtest?

You should take that post by testdasi as a warning and not attempt to make any changes to your router without knowing exactly what to do. See this previous post in this same thread for more information:

Obviously Jan 21 10:55:29 Retronwarz sshd[3200]: Failed password for root from 111.229.57.47 port 50646 ssh2 CHINA ... Jan 21 10:55:41 Retronwarz sshd[3370]: Invalid user tester from 198.245.50.81 port 56916 CANADA ... Jan 21 10:55:49 Retronwarz sshd[3531]: Invalid user yaya from 47.17.177.110 port 57790 US ... Jan 21 10:56:07 Retronwarz sshd[3805]: Failed password for root from 157.245.62.79 port 58732 ssh2 SINGAPORE ... Jan 21 10:56:16 Retronwarz sshd[3971]: Failed password for root from 139.255.35.181 port 59750 ssh2 INDONESIA ... Jan 21 10:56:17 Retronwarz sshd[3977]: Invalid user damiano from 92.222.72.234 port 45280 FRANCE ... Jan 21 10:56:30 Retronwarz sshd[4181]: Invalid user wz from 138.68.168.137 port 46360 UK ... Jan 21 10:56:37 Retronwarz sshd[4316]: Invalid user deployer from 37.139.0.226 port 35390 NETHERLANDS ... Hundreds more

Since this has absolutely nothing to do with the Linuxserver.io - Plex Media Server (which you said you abandoned because you couldn't figure it out), I have split it into its own General Support thread. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. If you can't get the diagnostics that way see this "Need Help" wiki pinned near the top of this same subforum for more ideas on how to get us more information: https://forums.unraid.net/topic/37579-need-help-read-me-first/

Can you get diagnostics before it starts getting weird?

Not simply a matter of drive failure during rebuild. Bad disks can also give bad data that makes the rebuild no good.

I assume you are using these in cache pool. This is exactly what I have for mine. SSDs shouldn't be used in the parity array.

Some people put those things on an Unassigned Device, basically for the same reasons they go on cache, so performance won't be impacted by the slower writes to the parity array, and so they won't keep parity and array disks spinning. To me it just seems simpler to put them on cache, which is where they go by default and Unraid already manages the cache pool. There is no reason not to use Unassigned Devices plugin for this though, it is well maintained. Personally I think people worry too much about caching writes to user shares. Caching the initial data load is usually a bad idea, since cache won't have the capacity, and you can't get things moved from cache as fast as you can write to cache. Most of my writes are scheduled backups from other computers on my network, or queued downloads from my dockers. I am not waiting around for those to finish anyway, so they might as well go directly to the array. And there is Turbo Write which speeds up writes to the parity array anyway if you want to do it that way. https://forums.unraid.net/topic/50397-turbo-write/ I only use SSD cache for my dockers, for keeping a subset of my music and photos so they can be frequently accessed by other devices on my network without spinning any disks, and for DVR since there is some performance advantage when trying to watch one thing while recording another. Then on the rare occasion I want to keep a recording I manually move it to another share on the array. Other people will have other use cases and other opinions.