Hello, first of all excuse my English, I found a week ago that I was missing many files from the array (4TB to be exact) unraid in the last parity check I found some errors, 35, which I corrected.
In the list of disks, none of them marks any error for me, the smatr either, but when I access from the webgui using the folder icon to see what is inside each disk, I see that disk 5 does not show me anything.
I stopped the array, I turned it on again, I went in again and for a moment all the files are seen but after a few minutes they disappear again.
I changed cables and did not solve anything, now I decided to change the disk to a new one, it is doing the reconstruction but I see that the same thing happens to me they do not appear and for mc I can not access the data on disk 5 or with the new disk.
Within my tests I connect the unformatted vijo disk to a linux vm within the same unraid server and I can access the data.
Let's see if you can help me attached diagnosis and some capture

unraid-diagnostics-20220109-1135.zip

Log is spammed with USB related issues, reboot and post new diags after array start.

Tonight when I open the reconstruction, I remove the usb that gives problems, restart and I get a new diagnosis, thanks

Well tonight after rebuilding the data on the disk and rebooting unraid and for more than an hour I have been able to access the data normally but now I am back with the same error also I realized that when this happens apart from I can't see the data on disk 5 I can't write to any shared resources attached new diagnosis

unraid-diagnostics-20220111-2332.zip

Check filesystem on disk5.

I'm doing  xfs_repair -v /dev/sdl  do you know how long it can take on a 12tb disk with 4tb used? The strange thing is that this disk has the new partition and reconstruction from parity since it is a new disk and it dragged the same problems as with the previous disk

5 minutes ago, Albertpj said:

I'm doing  xfs_repair -v /dev/sdl  do you know how long it can take on a 12tb disk with 4tb used? The strange thing is that this disk has the new partition and reconstruction from parity since it is a new disk and it dragged the same problems as with the previous disk

That is the wrong command

 

if working with the /dev/sdX type devices then you need to include the partition number (e.g. /dev/sdl1).  However using the /dev/sdX devices is not recommended for array drives as it invalidates parity.    You need to use /dev/mdX (where X is the disk number on the Main tab) (e.g. /dev/md5) to keep parity valid.  In addition the mdX devices do not need the partition number.

well ... well I stopped and executed it as you told me to finish quickly for now I can access again and write in the shared folders to see if it now holds up since on other occasions after a while it removes the disk to see if now after this it is maintained, if it lasts 24 hours I will perform a parity check Thanks, I'm already commenting on how it goes