trurl

It shouldn't be trying to move appdata at all if you followed my instructions. And it would be trying to move to cache, which is full.

A SMART warning for UDMA CRC error is also not a disk problem. It is a connection problem. Maybe it would cause a disk to get disabled, maybe not. I usually just acknowledge (click on the 👎) the occasional CRC, maybe replug the connector next time I'm in the case if I remember to. If it increases a lot you should investigate. UDMA CRC error means the disk has received inconsistent data. The disk firmware does a checksum on data received and if it doesn't pass, the UDMA count increments. The data is resent, so often there is no problem. And bad connections might not even cause UDMA, since the disk never received any data to checksum. An extended SMART self-test might be a good idea if you are concerned about the age. Do you have Notifications setup to alert you by email or other agent as soon as a problems is detected?

Not what I told you to do. Read the link

New Config won't really help until you get these I/O errors fixed.

Looks like your shares are configured OK. appdata has files on several array disks but can't get those moved to cache until cache has some space. Why do you have 100G docker.img? Default 20G is often enough, maybe a little more if you have a lot of dockers. But usage shouldn't grow. The main reason for filling docker.img is an application writing to a path that isn't mapped. You are going to have to recreate it now anyway since it is corrupt. We can get to that later after you make some space on cache. You have a couple of shares set to move to the array. Temporarily set appdata to Secondary storage:none so mover will skip it, then run mover to see if you can get those other shares moved to the array.

Done, and I will ping @JorgeB

If you formatted the disk in the array, the only thing it can rebuild is a formatted disk. Format is never part of rebuild. You should never format a disk that has data you want to keep. Disks 8 and 9 have little or no data. Did you format these? Maybe highwater allocation just hadn't gotten to them yet since they are so much smaller. All of your disks are mounted, disk8 is disabled. No xfs errors since reboot, but previous syslog showed problems with multiple disks, including the write errors which disabled disk8. This suggests controller or possibly power problems. And you have macvlan traces. https://docs.unraid.net/unraid-os/release-notes/6.12.8/#call-traces-and-crashes-related-to-macvlan

I thought we were going to do New Config. You should at least do a parity check, but that can wait. Post new diagnostics

No, Spencer is on the forum as SpencerJ. He often gets involved when someone is being an a-hole. 😁 Squid is in Canada.

A disk getting disabled may not be because of the disk. And waiting for them to get disabled might not be a good idea either. You should be considering SMART reports. Do any of your disks have SMART ( 👎 ) warnings on the Dashboard page?

I found all that very interesting, having lived through a lot of it. Joined the forum several months before you.

It is 2AM where he is. And you should start your own thread. I can split your posts here into another thread if you want.

If you have any questions, ask. After parity sync has been running for a while, post new diagnostics so we can take a look at how things are going.

Look in your diagnostics at shares/shareDisks.txt You will see a large number of entries for shares that do not exist. What that actually means is there are share configuration (.cfg) files that don't have any corresponding top level folders (user shares). That list is anonymized, but it looks like one of those might be named 'cache', so that might explain why it thinks you are trying to name a pool the same as one of your user shares. What do you get from command line with this? ls -lah /boot/config/shares

Link in my previous post.

You currently have pools named downloads new new_cache plexdata What do you want to do?

I did notice FSCK file on your flash drive, which means some filesystem corruption had been repaired. That is why I asked about flash backup. You should make a backup. You could try to boot a new install from another flash drive.

Try the BIOS update.

Not clear your title says you want to rename a pool but you are talking about renaming a folder. And you mention an error without specifying what it is. Attach Diagnostics to your NEXT post in this thread.

Probably nothing we can do except New Config and rebuild parity. And parity sync will be a good test of how things are working. It will read all data disks but not change them. And write both parity disks, which will be OK since parity has none of your data. That will mean no way to rebuild disk3 so whatever is on it is what you will have. If disk3 or any others are unmountable we can try to repair after parity sync. https://docs.unraid.net/unraid-os/manual/storage-management/#reset-the-array-configuration

Do you mean you were able to boot Unraid? Can you get Diagnostics and post them? You can always download a zipped backup of your flash drive from your Unraid webUI at Main - Boot Device - Flash - Flash Backup

Probably should update BIOS but don't know if it would fix this issue. Are there any release notes or other information about the update?