trurl

Assuming you ran the filesystem check in the webUI then the md device would have been fixed and so parity will have been updated and kept in sync with the fixes. Not really following the reasoning there. A parity check wouldn't hurt, but if there are parity errors you will have to correct them. What did you think you would do instead?

I have never used the script, but I think some have reported problems with it. For example start here in the user scripts thread: https://forums.unraid.net/topic/48707-additional-scripts-for-userscripts-plugin/?do=findComment&comment=850534 You might just try rebooting, New Config without that disk, trust parity, then do a parity check.

Those diagnostics are just a continuation of the previous. You need to shut down and check the connections, reboot and post new diagnostics.

Syslog seemed to say the disk is busy. Could the clear script still be running?

Are you sure you did steps 10,11,12, including checking the box and clicking Apply in step 12?

Unraid requires at least one data disk in the array (parity is not required) before you can start services, and a boot flash drive with a unique GUID for the license.

Perhaps ask on the Unassigned Devices support thread and post your diagnostics.

What do you want Unraid to provide in your scenario?

Also looks like emulated disk1 is unmountable. Don't do anything else without further advice.

Let's see if @johnnie.black has anything.

Looks like disk1 has completely disconnected. Check all connections, both ends, SATA and power, including splitters. Then post new diagnostics.

Whether or not you have parity you still need backups of anything important and irreplaceable.

Do you have an adblocker or anything else that might block web content? Whitelist your server.

yes

I guess you could just use cache as a separate storage pool by making some cache-only user shares for it.

If you don't have parity, any files in the array are unprotected, and unless you have a redundant cache pool any files on cache are unprotected. The shares in your screenshot all exist, most with files on cache, some on disk1. There are other share .cfg files in your diagnostics but they don't exist on any drive. Can you tell us more about how you did this? Did you ever run the Clean Up Appdata plugin or the Backup Appdata plugin?

Here is the wiki Overview: https://wiki.unraid.net/UnRAID_6/Overview Not sure there is much point to cache when your are bypassing all the "Unraid stuff" with RAID6.

It should have never been open. You must use a VPN to access your server outside your LAN. Unraid has the WireGuard VPN builtin.

Not sure I understand what you are trying to do with this: If you are giving Windows access to /mnt/user, then you are bypassing the security of individual Unraid user shares and just giving it all of the user shares as one share, so no separate user share security. You should map each share separately, or better yet, don't map anything. I never "map drives" to network resources anymore, since it is simpler to just browse the network, and most applications can browse the network too so no need for "mapped drives".

👍

super.dat is a file, not a folder. It is the file where your disk assignments are stored. If you delete it Unraid will not remember your disk assignments, and you will have to assign them all again. Which I guess is what is happening anyway. Here are the syslog lines that get repeated every time you start the array or assign disks: Jul 2 13:15:44 Tower emhttpd: shcmd (1587): modprobe md-mod super=/boot/config/super.dat Jul 2 13:15:44 Tower kernel: md: unRAID driver 2.9.13 installed Jul 2 13:15:44 Tower kernel: read_file: read error 21 Jul 2 13:15:44 Tower kernel: md: could not read superblock from /boot/config/super.dat Jul 2 13:15:44 Tower kernel: md: initializing superblock Jul 2 13:15:44 Tower kernel: mdcmd (1): label 0951-1665-E51B-FE31E9768465 Jul 2 13:15:44 Tower kernel: write_file: error 21 opening /boot/config/super.dat Jul 2 13:15:44 Tower kernel: md: could not write superblock file: /boot/config/super.dat I don't know if that label is referring to the volume label or if it is maybe the GUID of your flash or what. In any case, since it can't write super.dat it can't record your disk assignments. Is this the same flash drive you have been using? I don't know what else to suggest except recreating it and restoring the config folder from your backup.

When you stop the array it tries to update config/super.dat to record the started/stopped status of the array. That is how it detects unclean shutdowns. Ironically, you may be forced into unclean shutdown, though it isn't clear whether config/super.dat will show the array was stopped or started when you reboot.

Looks like maybe your flash drive isn't labelled UNRAID as required.