trurl

Filesystem corruption is independent of disk health. It is the data on the disk (actually, the filesystem metadata that keeps track of the other data) that is bad, not the disk. And that does look pretty bad. Looks like disk1 is connected to this controller 00:17.0 SATA controller [0106]: Intel Corporation Comet Lake SATA AHCI Controller [8086:06d2] DeviceName: Onboard - SATA Subsystem: Micro-Star International Co., Ltd. [MSI] Comet Lake SATA AHCI Controller [1462:7c79] Kernel driver in use: ahci Kernel modules: ahci So USB is not causing any problems with that disk. Post new diagnostics.

Do you have another copy of anything important and irreplaceable? If you insist on trying to get things all working again while still on USB, then I am going to recommend only attempting rebuild of disk1 to a new disk and leaving the original with its contents alone in case rebuild goes badly due to USB.

When a disk is disabled, it is no longer used. Instead, all other disks are read to get the data for the emulated disk from the parity calculation, and parity is updated to emulate writes to the disk so those can also be recovered by rebuild. The initial failed write, and any subsequent writes to the emulated disk, can be recovered by rebuild. Repairing the filesystem will involve writing the emulated disk. But, if you try to work with the emulated disk, you are relying on all the other disks working well to emulate the disk. If other disks disconnect as before, that won't work. And rebuild won't work either since it must write the emulated data to the rebuilding disk. This might be real corruption since I saw that in the logs after reboot, when presumably all enabled disks were still connected. And since that disk isn't being emulated, we could start with that one since repairing it would only involve disk1 and the remaining parity. Check filesystem on disk1 from the webUI. Capture the output and post it.

Have you examined it's data? No reason to do that. Most only do monthly or even less frequently.

Don't even think of that word. Format is NEVER part of rebuild. Format is a write operation. It writes an empty filesystem to the disk. If you format a disk in the array, Unraid treats that write operation just as it does any other, by updating parity. So after formatting a disk in the array, the only thing that can be rebuilt is an empty filesystem.

No. Several approaches possible. Usually repair the emulated filesystem. If the results look good, rebuild. Otherwise see if the physical disk contents look better and New Config it back into the array. Or some combination where you repair then rebuild to a new disk, and use the original to recover any files if necessary. Before doing anything, it would be best to get those disks connected without USB.

Reboot will never fix this. Fortunately, previous syslog was saved and is in those diagnostics. You were having connection problems with many disks. Those just happened to be the 2 disks that got disabled first because they couldn't be written and you can't have more than 2 disable disks. SMART for both disabled disks looks fine, a small number of reallocated on parity nothing to worry about. And as mentioned, not really disk problems. Disabled/emulated disk7 is unmountable though so that will have to be taken care of before rebuilding. Also looks like you have corruption on disk1, but perhaps that is because it can't really be read. Looks like you are trying to use USB for many of your disks. USB not recommended for assigned disks for many reasons, including the disconnections that caused all this.

You can't use the same IP address for your Unraid and for your Windows computer.

Do it again without -n. If it asks for it use -L. Post the results.

For completeness, you would also want to determine which file was "visible" when it existed on more pools than just the one named "cache".

Obviously that is not empty. Do you mean each of those folders are empty? You can't delete appdata until you delete each of those folders.

post docker run

You want the empty appdata folder removed from the pool named "board"? What do you get from command line with this? ls -lah /mnt/board/appdata

Does it also tell you that pool is read-only?

It doesn't give you any feedback like,are you sure you want to do this, or why you can't do this?

You must have rebooted after disk1 became disabled, so no way to see why that happened. SMART for disk1 looks OK so likely a connection problem. Emulated disk1 is mounted and has plenty of data. Should be OK to rebuild on top after checking connections. https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself

Sorry, another side track. When your server boots, it seems to think the date is Dec 31, then later figures out the correct date. This suggests your BIOS doesn't know what the data and time are, which suggests your CMOS battery is dead.

Not related, but I see you have your docker.img in /mnt/cache/docker. However, any folder at the top level of array or pools is automatically a user share. So that is part of a user share named "docker". Similarly for your default appdata folder. Your appdata share is correctly configured to stay on cache, so that's OK. But your docker share is configured to be moved to the array, and it has files on the array. We can look at that more closely after you get disk1 rebuilt. I will have more to say about that in my next post after I examine diagnostics more.

Do you mean you want to let Unraid access a share on your laptop? The usual way to mount a network share in Unraid is with the Unassigned Devices plugin. How are you trying to do it?

I didn't push the Delete button to see what would happen, but it looks like if you just browse to the top level of a pool it will let you select any folder and the Delete button is enabled. How did you try to do it?

Mini PCs in general are not good platforms for NAS functionality.

I don't know why that wouldn't work, must be some attempt to keep users from easily doing the wrong thing. I notice it won't let you create a folder at the top level of pool or array disk either, since that would create a user share and it's better to do that explicitly from the User Shares page. I guess you will have to go to the command line for that.

Probably a typo. Disk3 rebuild was compromised by bad parity. Check filesystem on disk3 from the webUI not the command line. Post the output.

Attach diagnostics to your NEXT post in this thread.