trurl

Can you put a picture of your dashboard page, it isn't clear to me what exactly is missing. Sure - it's just not populating statistics for anything. I suspect there is some conflict situation preventing the dashboard to display properly. I advice you to do the following: 1. Make a copy of the content of your flash drive, in case you need to preserve the content 2. Delete the following directories (if existing): - /boot/config/plugins - /boot/plugins - /boot/extra 3. Remove extra installations - if any - from the go file, just have emhttp started. 4. Reboot your system, and it will come up with no plugins 5. Make checks 6. Install optional plugins one-by-one and verify afterwards Done - no change. and clear your browser cache.

Unless those docker/VM's are actively accessing array drives during the parity check, which would not be uncommon. A Plex docker, for example, could be streaming a movie from an array drive while the parity check is running.

Maybe a connection problem. Known ATA S.M.A.R.T. attributes

I'm not 100% certain but i don't think you should be adding :latest to import an image, it probably can't find it. I think that's probably what's happening. Just try it with sparklyballs/asset-upnp and leave off the :latest. The screenshot you are showing just means that the docker command wasn't used correctly in some way.

Did you do a docker commit and docker push to a repository? If not, then you need to do that. You also need to add the docker through the ui so you create a my-templatefor it. Otherwise you will have to redo all the steps again. Thos steps are all mumbo-jumbo to me. When I click add container I see a my-template entry though. How do I do this committing and pushing? My docker page is attached. are you talking about asset-upnp ? Yes Sparkly. Then you're already using sparkly's repository, as shown in your screenshot. You should be good.

Hm, maybe it'll help to know that these disks are mounted in the hot-swap drive cage of a Lian Li PC-Q25B case which is connected to an ASUS H87I-PLUS motherboard. So these are using mobo ports then? I have that hardware and no problems. I'm sure others do as well.

This is true, but I wouldn't be surprised if most unRAID users do not understand how parity works and don't care. The user interface should not allow this to happen. When replacing a disk, there should not be any opportunity for the user to format a disk. If someone really needs to format a replacement instead of rebuilding, they can do a new config.

This is not the first case of this happening. Something really needs to be done about the interface to keep people from doing this to themselves.

BAD!

I think you would be the first to try it.

From the main page, click on the disk to get to its settings page

Stop the array, then I think you should get a dropdown next to the disk to allow you to select the file system. Haven't tried it recently, something like that.

Not entirely sure I understand what you have said. When unRAID formats a drive in a parity-protected array, the parity disk is automatically updated. It is fairly quick when this happens because the entire drive is not erased when you format a drive. Many people seem to think formatting a drive means erasing it. What formatting really means is creating an empty filesystem. This is true in any OS. For example, when Windows does a quick format, all it is really doing is setting up some "data" on the disk that the OS uses to start building the directories from.

You can add the "nct6791" name in the driver field and then save. It allows you to load the module manually in the next step. Btw did you use a newer version of sensors-detect previously, because that script hasn't changed (plugin relies on the version installed together with unRAID). I am using the sensors-detect.sh from here, so not the one built-in to unRAID.

Looks like it is only detecting "coretemp" for me. There was some recent change in the detect script that finally made it work to find "nct6791" on my MB, but looks like it is not working with this. So I will not "Save" since I do have readings now and I expect if I save I will be back to having only coretemp.

Is this in the wrong thread? I went back a few pages and couldn't figure out who you intended this for.

You didn't answer the question about what unRAID version. The current version of preclear is 1.15. Version 1.15 fixed a problem with running preclear on 64bit unRAID.

What version of unRAID and what version of preclear? Also, was this disk used previously in another system? From your posting history, it looks like this may be the first 2TB+ drive you have tried to use. Are you sure your hardware supports it?

Thanks for these recent updates. One suggestion and I don't know how hard it would be to implement. Since we are now getting notifications when there are updates, why do we have to press the check for updates button to see them? Couldn't it just go ahead and show us the updates it has already notified us about? Also, another thing I noticed about notifications today with my monthly parity check. I got emails about the check starting, but only after accessing the webGUI, several hours after the check actually started. And again when the check finished, I got an email that it had finished, but only after accessing the webGUI, several hours after the check actually finished. Not a big deal, but not ideal.

Are you using a VPN? It is not recommended to make your unRAID accessible on the internet without good security.

If you use your Windows machine to do a preclear it might be good to disconnect any drive that you don't intend to preclear.

Can your BIOS see the drive? If not then probably a connection problem.

And there's also disc rot to consider.

I rsync my flash periodically as there are some configuration files, plugins, extras, etc, etc. In addition it has the superblock which is the layout of the array itself. Keep in mind it might be out of date from when you've last made a change to the array, so you'll want to do the rsync/backup anytime you change the array. Also, unRAID keeps the array run status in the superblock (super.dat) so if you copy it with the array running and then start from that copy unRAID will assume an unclean shutdown and force a correcting parity check. So, doing the copy with the array stopped is probably a good idea. Ideally an unneeded parity check should not be a problem but sometimes things are not ideal. The most important thing is to not restore a super.dat that is not of the current array configuration. Another user did that after reusing his parity drive as a data drive, and unRAID started writing parity to that data drive.

Having chimed in on this, I'm not sure an automatic checkdisk on bootup is the right solution to this. Maybe alert the user instead of having to discover this if you happen to look at the syslog.