itimpi

A disk being encrypted should not affect ability to rebuild as the rebuild occurs at a lower level (sector level) than the encryption. Are you sure you did not mean something else.

A power cycle means removing the power and then reapplying it to boot again. This can reset the hardware which a simple reboot might not do. Normally you would power off using the Shutdown button on the GUI.

Chances are you messed up the permissions on the files. Run Tools->New Permissions against the share in question and it should fix any permissions issues.

Not sure there is a perfect answer Quite a few disk controllers suspend any other I/O while spinning up a drive which can cause temporary freezing in video streaming so you have to balance this against power savings of more frequent spindowns.

It all depends on whether you made a mistake and assigned the wrong drive to parity (which would mean that the contents are now overwritten). If you did NOT assign the wrong disk to parity then the way to handle unmountable array drives is covered here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

I think that this is expected behaviour as the pre-clear is preventing an OS level 'sync' operation from completing so Unraid cannot commit the disk change. Since pre-clear is not part of standard Unraid the fix needs to be done at the pre-clear level. I had a feeling it had a pause/resume option but not used it for a while so could be wrong.

That is normal - you should just reply in the existing support thread. The idea is to keep posts on a particular topic grouped together.

If you are on Unraid 6.10 rc1 then you fell foul of a bug where this was not the default setting - should be fixed in rc2.

Never means no automatic spin downs.

That would be consistent with it silently over-writing existing files. Perhaps you need to do a test locally within the windows system to see how it is handling copying when files already exist.

Without knowing more about the script difficult to say. If files already exist then you get the same overwrite behaviour regardless of whether they are on cache or array as tke script will not know where they are.

Yes Files normally never exist in more than one place - they will either be on the cache or on the array. Therefore their will be no duplicates unless you actively go 'under' the covers' to create them by-passing the User Share system. Since a User Share is a consolidated view of the files on the array AND the cache. when you copy to a User Share then you have no visibility of which drive it is going to and only new files go to the cache.

The screenshot suggests that the VM sub-system is the culprit Are you sure there is no VM running?

Looking at the syslog it looks as if your system is having trouble accessing the flash drive as read errors are being reported in the syslog for device sda1. You could try it in a different port, or you try recreating it (but if so first take a backup) to see if rewriting the contents helps.

Do you have a spare disk you could put in as disk3? If so then you could take the following approach: run a check/repair on the emulated disk3. I am not sure of the current state of things but running an extra check/repair will not do any harm. At this point the emulated disk should mount when you restart the array in normal mode although you may have some (or even a lot) of files in the lost+found folder. put the spare disk in as disk3 and let UnRaid build the emulated contents onto that physical disk. after the rebuild is finished (optionally) discard the contents of the lost+Found folder use rsync (or any similar copying software) to copy all files that do not exist on the new disk3 from the old disk3 mounted in UD to the new disk3. Hopefully this will pick up any files that ended up in lost+found If you did not do it earlier you can probably now discard the contents of the lost+found folder. if you have no spare disk then you can take a similar approach although in this case you do not do the rebuild at the point mentioned above and instead copy the contents of the old disk3 mounted in UD onto the emulated disk before attempting any rebuild. When that completes the old disk3 is now free to be used for rebuild purposes.

I do not see much need for such a feature. Why do you not simply put the files on a share in Unraid and then connect the VM to that share? Just for interest what drivers are you interested in that are not available as an iso image? If you want such a feature then it should probably be done to the KVM team (as that is the software that Unraid uses to run VMs), not the Unraid team as that sounds like the level it would exist at. It may already exist at that level - I am not sure without perusing the KVM documentation.

Perhaps a silly question, but how much RAM do you have installed? This is not a bug I have seen reported before so it must be specific to your system in some way. Perhaps giving more details on the hardware you are trying to use might get some useful suggestions from others with similar hardware.

That was not the right thing to do - and you have probably caused the physical drive (that was OK) to be overwritten with the contents of the emulated drive (which was not). EDIT: actually on reading more carefully if you did not start the array with the disk unassigned you may be OK as that is the point at which Unraid commits drive assignments, and you also did not mention a rebuild starting on he drive. I would try unassigning it again and checking that it can still be mounted by UD. If so keep it unassigned until you get further advice.

A bit worried that you said this. Simply adding the disk back into the array is likely to have lost its contents as it probably triggered a rebuild - thus destroying its current contents and putting the emulated contents there instead.

UnRaid automatically runs a non-correcting parity check the next time you boot after an unclean shutdown. If you are regularity getting unclean shutdowns then you need to investigate why, and perhaps invest in a UPS if they are due to power interruptions. it is recommended that scheduled checks are non-correcting. This is because if a drive is playing up and returning bad data you might end up corrupting parity.

When do you have the scheduled check set to run? I would guess from the dates they were more likely unscheduled ones? If they were ones run after an unclean shutdown then that defaults to non-correcting.

The problem is that a drive going unmountable means there is file system corruption (basically a write appeared to work, but the data written was wrong for some reason) and parity does not protect against this.

one option is to try and mount the original disk using the UD plugin to see if is in a better state than the emulated one (one reason not to rush into a rebuild over its contents). You may have to use the option in the UD settings to change the UUID on the drive to avoid it clashing with the emulated dtive.

The disk will stay disabled until it is rebuilt. If you are going to rebuild back to the original drive you should first check that the contents now looks correct as all the rebuild process does is make the physical disk match the emulated one.

Yes - go for the repair and if prompted for it add the -L option. if the repair goes well then when you restart the array in normal mode the disk should mount and you should see all your files. If that is not the case or anything unexpected happens then report back for further advice. For the parity drive it is a case of rebuilding it to remove the disabled state. as to what caused the original problem it could be anything and just a momentary glitch, particularly if a cable was not perfectly seated.