trurl

Unmount that Unassigned Device. Stop the array. Go to Tools - New Config and keep all assignments. Before starting the array, reassign disk11. Make sure you do NOT check the box saying parity is valid, because it needs to be rebuilt. It may only be a little out-of-sync but it should be rebuilt anyway. Then Start the array to begin parity sync. If there are any problems during parity sync, post your diagnostics but let it continue pending further advice. What you should see during parity sync is a lot of Reads on all data disks, a lot of Writes to parity, and zeros in the Errors column. Parity sync errors are expected, be interesting to see how many.

No that is correct, just being cautious. Go ahead and start the array. Disk 11 should be missing, disabled, and unmountable but you should be able to look at the Unassigned disk on the network.

Probably should have been posted to General Support instead of Bug Report. I may copy it there eventually.

Just to make sure. On Main - Array Devices, does it show disk 11 as No Device or similar? I guess you will have to start the array to get SMB started so you can look at that UD on the network. Or you could examine the files from the server itself if you know how to use Midnight Commander (mc from the command line) or just how to work from the command line.

The slider under "Share" will let you share it on the network so you can look at it from your PC. Maybe you will have to unmount it before it will let you change that, I'm not sure.

Post a screenshot of Main - Unassigned Devices

Just thought I should warn you that you don't want to reassign that disk without doing New Config first. Reassigning a disk is the way you get it to rebuild, and you don't want to rebuild it.

That looks good. Have you checked the files on the disk with it mounted Unassigned?

It is good because you still have the files. It is bad because we don't know the cause of the disk becoming disabled nor the reason the emulated disk was unmountable. Since you rebooted after you began to have problems, syslog from your diagnostics don't tell us anything about what may have happened. Do you have any ideas about this? Do you have any reason to think your parity was invalid? Your screenshot didn't show all disks. Were any of them showing anything other than zero in the Errors column? To get that disk back into the array will require New Config / Parity Sync. But before we proceed with that lets see if we can figure out what went wrong, or at least make sure there isn't something currently wrong that would prevent parity rebuild. You have a lot of disks, and I haven't examined SMART for each of them. Do any of the disks show SMART warnings on the Dashboard? Post a screenshot of the Array section on the Dashboard page.

I will probably copy this to General Support after we get the syslog and diagnostics since this thread doesn't really conform to Report Guidelines:

I will probably copy this to General Support after we get the syslog and diagnostics since this thread doesn't really conform to Report Guidelines:

I am just now looking at your diagnostics and the repair log. My main point was to make sure nobody thought formatting was a good idea. That repair log looked very bad. How exactly did you do that repair? Did you do it from the webUI or from the command line? If from the command line, what was the exact command you used? No, thankfully it won't just begin a rebuild all by itself, and you don't want to rebuild from where you are because all you will get is the same unmountable disk you have now, except it won't be disabled anymore. Stop the array and unassign that disk, then see if you can mount it read-only with Unassigned Devices. Maybe the actual disk isn't unmountable but the emulated disk is because of other problems such as invalid parity. Do you have backups of anything important and irreplaceable? Also, the way you have docker configured is far from ideal, but we can deal with that later.

Post diagnostics.

FYI for anyone. This is NEVER the right answer. Format, like any write operation, updates parity. So after the format, parity agrees the disk has been formatted. Then, rebuilding from parity just results in a formatted disk. @GTP Posting new diagnostics will give us the answer to But you can also just look at Main - Array Devices

probably should have started with a thread in General Support since you admit you don't know if it's related to this beta or not.

probably should have started with a thread in General Support since you admit you don't know if it's related to this beta or not.

Yes this would be the usual way. You don't mention any disks for Unraid. Unraid is a NAS OS after all. What are your plans for Unraid?

I noticed in earlier diagnostics you had allocated 80G for docker.img Have you had problems filling it? 20G should be more than enough and making it larger won't fix anything, it will just make it take longer to fill. I am running 17 dockers and they are using less than half of 20G. The usual reason for filling docker.img is an application writing to a path that doesn't correspond to a container path in the mappings. Common mistakes are not using the same upper/lower case as in the mappings, or using a relative path.

Like the rest of the OS, syslog is in RAM so resets on reboot. Not a big deal if the next parity check finds zero sync errors.

https://support.google.com/accounts/answer/185833?hl=en

As explained in the wiki here: https://wiki.unraid.net/UnRAID_6/Getting_Started#Manual_Method_.28Legacy.29

Correct

Start the array and post new diagnostics.

Sometimes people will try to make things neat by running cables together. You can get "crosstalk" if the cables aren't shielded, which SATA cables typically aren't.

Check connections, SATA and power, both ends, including any splitters. Don't bundle SATA cables. Make sure connectors sit squarely on connections with enough slack so they stay that way.