wmcneil

@JorgeB , thanks so much for the feedback, and for the pointer to the pool monitoring FAQ, I will implement the monitoring suggestion there.
 
I ran "/btrfs dev stats /mnt/cache" and I had one cache disk that is showing errors:
 
[/dev/sdd1].write_io_errs    176644
[/dev/sdd1].read_io_errs     111
[/dev/sdd1].flush_io_errs    20656
[/dev/sdd1].corruption_errs  277249
[/dev/sdd1].generation_errs  0
 
I tried a different cable, zeroed  the errors using "btrfs dev stats -z /mnt/cache", and new errors were still being generated. I tried moving the disk to a different sata slot (I have an open one), and was still getting errors from that same disk. So l installed a new cache disk, and btrfs is running now. The old cache disk is still in the machine, but it is not assigned to the pool, and I'm not getting any new errors. 
 

I figured this out. My windows hosts file was out of date (because I have moved and have a new subnet). For others looking to verify if this is their problem, the hosts file is a text file that may contain mappings from computer names to numeric IP addresses. For win11, it is located here:
C:\Windows\System32\drivers\etc\hosts
You will need admin authority to modify it.  Saving it from an editor may not work, in that case save the editor contents to a temporary location, and then move the file from the temporary location to the location noted above. You will prompted by windows that admin authority is required for the move, simply confirm the prompt (as long as your user has admin authority this will work)
 
I understand and appreciate the need to understand the security implications of enabling guest logons. That said, when windows is configured to allow them, and unRAID is configured to allow public access, there is NOT a requirement to configure windows credentials. I see a lot of discussion in these forums on this topic, and it does not serve the interests of the community to insist that windows credentials are required in a configuration where they are not.  In fact, even when more locked-down security is the end goal, it is extremely useful (and frequently necessary) to be able to get things working initially without it.
 

The ...vdisk1.img did have boot order 1, but the windows install *.iso did not have a boot order of 2. I also scrubbed through all of the settings in the forms view, and found a few things that were not the same as they previously were. I don't know if it is user error when I pasted in the prior xml, or if the mapping from xml to forms is not 100% complete or correct. In any case, windows is now booting.

I tried having unraid format the unmountable drives, and that was not successful. The system log is now complaining about both disks in the pool:
 
I powered down the machine, and the sata connector on the drive of interest was a little less than fully plugged in. After powering on, the format was successful. 
 
At this point, looks like the SATA cable connection was the problem.  @JorgeB, thanks for your help, appreciate it!