trurl

BIOS update?

Might also be useful to get Diagnostics from sometime after it has been running a while but before it crashes. That might tell us more than the syslog alone could.

Not only that but it is probably starting a parity check each time due to unclean shutdown. Did you ever correct your parity errors? Probably a hardware problem. Have you done memtest?

I wanted you to go to Apps and choose one of the Plex dockers, then click its Download button (the down arrow). That would have taken you to that Add Container page, but with a lot of things already filled in. Then we could consider what needed to be changed or added to that page before you actually pushed Apply. Remove your plex docker and try again, starting from the Apps page. Don't Apply but instead post a screenshot.

Correct. Just New Config, make the assignments you want, being very careful to not assign a data disk to the parity slot, and check the box saying parity is already valid before starting the array.

Just use the Previous Apps feature on the Apps page. It will automatically use the settings you had before. Since you apparently intend to change a mapping just edit that one before submitting it. Everything else will be just as before.

You jumped WAY ahead. Here is where I wanted you to go with that and no further:

I think there have been some critical updates to XFS repair since the version you are on, so you probably better update Unraid. And the jump from 6.4 to any of the currently available downloads may require a little extra work: https://forums.unraid.net/topic/66327-unraid-os-version-650-stable-release-update-notes/

As already stated.

The long time between 6.4 and 6.8 was very compressed as compared to some of the more "ancient" times.

I think of the archives on flash as the firmware. Then, as you say, there are additional settings stored on flash so they can be reapplied at boot. But those settings are themselves loaded into RAM for reading, and get written to flash if they are changed so they can be reapplied at boot, etc. Possibly there are some details that deviate from this model, and I know other things such as some plugins will write to flash. There has been ongoing discussions to limit writes to flash.

Most do not have these problems. I have been using the same Flash for 6 years. Are you using USB2 Flash and USB2 port?

Way better than any of my meager attempts at any other language. I can sometimes figure out some of the signage when I go to Europe.

Settings - Notifications

Cache is corrupt. Possibly you overfilled it but I can't tell how full it was since it doesn't mount. Click on it to get to its page and check its filesystem. Be sure to capture any output so you can post it. Also, your parity is invalid but I assume you know that. And you have several warnings from Fix Common Problems. You shouldn't ignore these unless you have some specific reason why they don't apply to your specific use. And they do apply because you are running a very old version of Unraid.

Maybe this question was answered pages ago, but I asked it again on the previous page so I didn't have to go looking through the whole thread to find out: Since we are talking about rebuilding to a new larger disk, it is worth noting that all bits of all disks must be reliably read to reliably rebuild a disk. So if you have any disks with problems they need to be considered before attempting to replace a disk. Also, have you setup Notifications to alert you immediately by email or other agent as soon as a problem is detected? (Sorry if I am repeating myself, I write so much on so many threads and can't always remember what has already been discussed on any particular thread.)

I'm going to do some explanation here but first I want to say that your use of the word "add" in this context is somewhat ambiguous, and it often pays to be precise when talking about your data. The only time Unraid requires a clear disk is when ADDING it to a NEW slot in an array that already has valid parity. This is because a clear disk is all zeros, and has no effect on parity. So adding a clear disk maintains parity. If you add a disk that has not been cleared, Unraid will clear it so parity is maintained. Old versions of Unraid would take the array offline while it cleared a disk, so pre-clear was invented to clear a disk before (pre) adding it. Current version of Unraid will clear a disk without taking the array offline, so it is OK to let Unraid do the clearing and preclear is not needed for this. In your case, you will not be adding a disk, you will be replacing a disk. Unraid does not require a clear disk in that case, since the entire disk is going to be overwritten from the parity calculation anyway. Some people still use preclear as a way to test disks and perhaps "burn-in" a new disk to get it past some of the "infant mortality". The disk will get some testing and burn-in anyway just as the result of the rebuild, and a non-correcting parity check is often recommended after to confirm the rebuild went well, so that would be even more testing and burn-in. As long as you keep the original disk with its data intact you shouldn't have any data loss even if there is a problem.

You should close all those ports, that is the main thing. The docker and Unraid installs are very unlikely to be a problem. In any case, dockers are easily reinstalled using the Previous Apps feature on the Apps page. As for Unraid, it installs itself into RAM fresh from the archives on flash each time it boots.

The diagnostics you gave us only include a few seconds after reboot, and without the array started. You have to setup Syslog Server if you want to keep syslogs from earlier. https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

And other people will have other opinions about this that make more sense to them. Some people think it makes more sense to spread their baby pictures across multiple disks, so that in the event a specific disk can't be recovered, then they will not lose all of the baby pictures. I always say it just depends on how you want to gamble. You can spread them out over 5 disks and then if one of them can't be recovered, you have a 100% chance of losing 20% of them. Or, you can put them all on 1 of the 5 disks, and if one of those 5 disks can't be recovered, then you have a 20% chance of losing all of them. And really, the chance of not being able to recover a disk isn't all that much if you do things right since recovering a disk is what parity is all about. And, you should always have another copy of anything important and irreplaceable (like baby pictures). Parity is not a substitute for backups. You get to decide what qualifies as important and irreplaceable. Personally I don't bother to backup a lot of my stuff since it doesn't qualify for me. And those things that do qualify I have 2 copies offsite.

As you can see from your pdf, most of your shares are spread across most of your disks. Also notice there is a total amount used by each share shown on the line with the share name at the top of each share listing. A few of your shares are too large to fit on a single disk. As for how they perform, I would need to know more about how you use them to give any specific recommendations. Newer larger faster (RPM) disks will likely perform better than older smaller slower disks, but whether or not that difference will be noticeable in real use is another question. How many simultaneous streams do you expect from Plex, for example? I rarely have more than one, and have never had more than two. Other people expect to have more. I have also used plex to record one program while also playing back a recording already made. I do my plex DVR on cache SSD for that reason. Another possible scenario. If you want most disks to spin down while you are binge watching a TV series, and get no delays while a disk spins up when you go to the next episode, then it would make sense to have that series all on the same disk. That is the point of the Split Level setting. That might also be important to you if you listen to music the old fashioned way, where you expect to play a whole "album" together in the intended order. Keeping albums together on the same disk makes this a little smoother since it won't have a pause while another disk spins up if the whole album is together. The way I handle things personally is to just restrict certain shares to certain disks using the Include setting. I have some shares that are too large for a single disk so those include more than one disk. I have other shares that are small enough that they can go together with other shares on the same disk. I just use the default Highwater allocation to let things get distributed if a share needs more than one disk, and don't bother with Split Level since Highwater will usually keep things together anyway if they get written together. And I don't worry about spinup delay if they don't happen to wind up on the same disk. And as mentioned Minimum Free is important so Unraid will choose another of the Included disks (or all disks if you don't restrict a share to certain disks) when a disk gets too full.

See this thread for the sort of thing we're talking about: https://forums.unraid.net/topic/86061-unraid-dropping-wan-connections That user thought they had found their problem before we had a chance to respond. So they were going to keep doing what they were doing. They never came back to find out what we had to say about what was happening and what they were doing wrong, so probably they are still getting hacked.

Not the problem you're asking about, but you are having issues with multiple disks, likely a controller problem or possibly power. Dec 18 10:55:54 media1 kernel: sas: ata5: end_device-1:0:18: cmd error handler Dec 18 10:55:54 media1 kernel: sas: ata5: end_device-1:0:18: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata6: end_device-1:0:19: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata7: end_device-1:0:20: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata8: end_device-1:0:21: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata9: end_device-1:0:22: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata10: end_device-1:0:23: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata11: end_device-1:0:24: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata12: end_device-1:0:27: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata13: end_device-1:0:28: dev error handler Dec 18 10:55:54 media1 kernel: sas: ata14: end_device-1:0:29: dev error handler

Just close the ports and see if the problem goes away

For future reference, you should not edit a previous post and expect anyone to notice your edit. Make a new post for posting your diagnostics. Not only will they be easier to find, but the thread will show that there is new content for us to look at.