trurl

You need to use the same flash drive but configure it for legacy. You can do that from the webUI, Main - Boot Device - Flash - Syslinux Configuration, uncheck UEFI.
 
Or just rename EFI folder on flash to EFI-

Because
 
 

Looks like you have a bad flash drive. Do you have a backup?

Put flash in PC, rename or delete config/network.cfg so it will use default settings.

Jan 29 10:39:42 shogun emhttpd: unclean shutdown detected ... Jan 29 10:40:03 shogun kernel: mdcmd (36): check nocorrect ... Jan 30 05:45:16 shogun kernel: md: sync done. time=68713sec Jan 30 05:45:16 shogun kernel: md: recovery thread: exit status: 0 Unclean shutdown automatic parity checks are non-correcting.
 
Then you manually ran a correcting parity check which corrected the errors the non-correcting parity check found.
Jan 30 12:44:39 shogun kernel: mdcmd (37): check Jan 30 12:44:39 shogun kernel: md: recovery thread: check P ... Jan 30 12:44:39 shogun kernel: md: recovery thread: P corrected, sector=0 ... Jan 30 20:07:40 shogun kernel: md: recovery thread: P corrected, sector=5438978488 Jan 30 20:07:40 shogun kernel: md: recovery thread: stopped logging ... Jan 31 08:00:55 shogun kernel: md: sync done. time=69376sec Jan 31 08:00:55 shogun kernel: md: recovery thread: exit status: 0 Run another non-correcting parity check to verify.
 
Do you know why you had unclean shutdown?

It doesn't redistribute the data, and you don't need it to. It will distribute the data as new data is written according to the settings for each share.
 
Highwater is the default allocation method, a good compromise between using all disks eventually, without constantly switching disks just because one disk temporarily has more free than another.

Since there is some doubt about your parity, rebuilding to a new disk might not produce a good result, but since you presumably don't need the data on the disk now, I guess that is as good a way of proceeding as any. Disk1 has to be rebuilt, or parity has to be rebuilt. Assuming no other problems during rebuild, either way would get the array back in sync, and you could just reformat disk1 after the rebuild since its data has been copied off.

Reseat controller(s). Check connections, both ends, SAS/SATA and power, including splitters.

Run repair without -n

Use the Download link at top of the forum, replace all bz* files in the top folder of flash with those from the download.

CRC errors are just connection problems recorded by the drive firmware, they won't reset to zero but a few occasionally are OK. If they are increasing you need to figure out what the connection problem is. Looks like that warning is referring to an Unassigned Device not seen in your screenshot, presumably the new drive.
 
I usually don't bother with preclear but you can if you want. Rebuilding to that new disk will be a good test anyway, and as long as you have the original should be little risk.
 
To rebuild to another disk, just assign it to the slot you are replacing and start the array.
 
 

Click on the drop down for the parity slot and select the disk you want to assign as parity. Similar for others. 
 
If that doesn't help post a screenshot of Main 

Not sure what you mean by system file. I was talking about the system share, which is a folder on one or more disks. Ideally it would all be on fast storage (cache).
 
If appdata and system are on the array, dockers/VMs won't perform as well due to slower array, and array disks can't spindown since these files are always open.
 
Nothing can move open files. You have to disable Docker and VM Manager in Settings before these can be moved.

Flash it to IT mode. Best if you don't try to use RAID controllers with Unraid.

run check again without -n

Until it is formatted, you have no storage to work with. Check the box to enable the Format button.

You could New Config the original back into the array and rebuild parity.

That looks OK but a medium error on that disk was logged earlier in syslog.
 
Disabled disk5 has to be rebuilt. Unraid disables a disk when a write to it fails for any reason. It has to because the failed write makes it out-of-sync. After disabling, the disk isn't used again. Instead, all access to the disk is emulated from the parity calculation by reading parity and all other disks. That initial failed write, and any subsequent writes, are emulated by updating parity, and can be recovered by rebuilding.
 
Emulated disk5 is mounted and is over half full, so looks like that is all working well.
 
It's always safer to rebuild to a spare, and so keep the original just as it is in case there is any problem rebuilding. But it's probably OK to rebuild to the same disk if you don't have a spare.
 
 

Those user share settings only apply to new files. If that share already had files in other places you will have to move them yourself.

Since v6.9+ allows multiple pools, each pool has its own settings. Click on the first disk of the pool.

yes

And parity resync would be a good test of your connections before attempting rebuild again.

sdf in those diagnostics was the first disk in a pool named torrent, formatted btrfs. sdg was the other disk in the pool, but it was listed in the smart folder as sdp so it must have disconnected.
 
And the errors in syslog are, in fact, for sdg
Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 872, rd 13057, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 873, rd 13057, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 873, rd 13058, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 874, rd 13058, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 874, rd 13059, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 875, rd 13059, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 875, rd 13060, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 876, rd 13060, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 876, rd 13061, flush 0, corrupt 0, gen 0 Jan 5 18:09:36 Brunnhilde kernel: BTRFS error (device sdf1): bdev /dev/sdg1 errs: wr 877, rd 13061, flush 0, corrupt 0, gen 0  

The answer in case anyone else is wondering, is that only root has access to the webUI and command line. The other user accounts are strictly for network file access.

Have you tried accessing it by IP?