Shant1993

I mean in terms of CRC errors for SAS. I remember reading that SAS is more resilient, but I don't have first hand experience with it. I'm using those bundled sata cables, where it's 6-8 sata cables in one shielding so it's neat. Surprisingly these gave me less errors than individual ones. I suppose my chassis is too tight and crammed, but good advise on cross talk issues. I should really buy that Jonsbo N5...

This is great. I'll be sure to pay attention to friction and shroud the next time I have to touch those cables. Does SAS have similar issues?

I promise I have tried a dozen sata cables, they all end up with this isue... I have changed my motherboard one time, have bought new hdds at other times, i have tried new cables... It always happens on both new and old drives over time. Some cables take more time, some less. I am guessing maybe something to do with my chasis vibrating from fans. So far no errors yet.

Completely forgot to post diagnostics, here it is. These diagnostics are -after- i did everything i mention in this reply. Since I wrote this, I did the following, i'm not sure if it was a mistake or the right call. I had the array in maintenance mode, so no disks mounted, and I ran the following in terminal as a read only test to see if any of the disks, be it disabled, emulated, or healthy, would throw off crc errors. I ran it on all of them with different terminal instances dd if=/dev/sdg of=/dev/null bs=4M iflag=direct status=progress Then I monitored syslogs to see if it will throw any errors tail -f /var/log/syslog As well as monitored the web ui errors tab (not sure if errors would reflect here when running the read test through terminal) Overall, I got zero CRC errors on all the drives, but i didn't do a 100% read, only a few hundred GB (I know, I probably should have done a full test) So I stopped array again, unassigned parity 1 which is disabled anyway, to no disk, and started array in maintenance mode again, and clicked sync parity. Right now it's rebuilding Disk 1, so far no CRC or other errors. Hoping for the best. Eager to hear opinions nevertheless if I should have done something else or taken more precaution. tower-diagnostics-20260320-1534.zip

I have an issue where SATA cables occasionally come loose, causing drives to be disabled and throw CRC errors. I’ve replaced cables, changed the motherboard, and even used new HDDs, but the problem still happens. It might be due to case vibration or fans. Setup: Parity 1 Parity 2 Disk 1 Disk 2 Disk 3 Recently, I moved the NAS for cleaning and Disk 1 started showing CRC errors and was disabled. I left it that way for 2 days. Today, I replugged the cable and followed the usual process: stopped the array, unassigned Disk 1, started in maintenance mode, stopped again, reassigned Disk 1, and started the array in normal mode. Unraid automatically began rebuilding Disk 1. Then Parity 1 started throwing CRC errors, likely because I accidentally bumped its SATA cable while fixing Disk 1. When I tried to shut down, Unraid became unresponsive (no web UI, HDMI, or SSH), so I had to force an unclean shutdown. After booting again, Unraid reported the unclean shutdown and started the array unmounted. I repeated the same process for Disk 1 (maintenance mode, reassign, etc.), but this time it did not automatically start rebuilding. Current state: Parity 1 has a red X (disabled) Disk 1 shows as emulated (yellow warning) There is a “Sync” button that says it will rebuild data, but not much detail if it's going to write to all drives or just disk 1. So my concerns, What exactly will the Sync button do? Will it rebuild only Disk 1, or something else? Do I go ahead and click sync? I feel like it's going to try and build the parity instead. Why didn’t Disk 1 rebuild automatically this time? Is it safe to use new Config on Parity 1 to re enable it without rebuilding, assuming Disk 1 rebuilds successfully and there are no more errors? Keeping in mind, data was likely written during the 2 days Disk 1 was emulated (while parity was healthy), and later Parity 1 developed errors while the array was running in normal mode rather quickly within minutes. I don't think any of my dockers wrote anything that quickly, but i can't be sure. That said, I can't confirm any other cables going bad and another disk getting disabled, i did my best to be careful, my cables do have latches and I did try a variety of sata cables, all end up with same issue. To verify, is there a way I can do a read only test to see if any of the sata cables throw errors before i attempt anything further and get unraid to disable another disk again? maybe there's a way through terminal?

That was so flawless. All working! Reinstalled the docker image file, then re installed the docker applications from previous apps, and all my docker data was preserved. Thanks!

I don't know if this is relevant, but fix common problems was complaining about leftover files on cache drive, so I followed the guide linked with it and manually moved the files from cache_ssd/system/docker/docker.img cache_ssd/system/libvirt/libvirt.img to database_ssd/system/docker/docker.img database_ssd/system/libvirt/libvirt.img I didn't replace anything on the database_ssd side, the folders were empty before moving. I also deleted folders chache_ssd/appdata & cache_ssd/domains which were both empty. I have the following folders on an ssd (database_ssd) as a pool drive, and not on the array: appdata domains isos System I also updated to 7.0.0 first before updating to 7.0.1, but I didn't check if docker was working on 7.0.0. Thanks. tower-diagnostics-20250307-1933.zip