itimpi

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.

A rebuild will not clear an ‘unmountable state - the rebuilt disk would also be unmountable. Handling of unmountable disks is covered here in the online documentation accessible via the ‘Manual link at the bottom of the Unraid GUI.

Do the diagnostics correspond to the screenshot as the screenshot does not show any drive missing, but the diagnostics suggest it is not online. Since the diagnostics show parity and disks 4 and 5 are also offline I would suspect the disks are fine but that there is a problem with something common to those 4 drives such as SATA or Power cabling. I would suggest powering down; checking all cabling; reboot; start the array; and post new diagnostics. That might give a better clue on how to advise you to continue.

Since having a cache drive dramatically improves the performance of VMs and docker containers there is probably an implicit assumption that anyone making use of them if likely to have a cache drive. There is also the fact that accessing a folder on the cache/pool by referencing the drive seems to be slightly more performant than doing it indirectly via a User Share.

That implies that the code is not being reached in the first place.

Files/folders only get put into lost+found if the repair process cannot find the directory information to put them into the correct folder with the correct name. On that basis that 320GB should not exist elsewhere on the drive although that is a very large amount to have lost the directory information. In most cases it is easiest to 'nuke' the lost+found folder and restore any missing files from your backups as going through the lost+found folder is a very laborious manual process to try and identify what the files there were originally called. That does rely on you having adequate backups, and without them if the data was important you may have no other choice. When restoring from backups you can use options so that only files that are missing are copied from the backup. If you DO decide to process the lost+found folder the Linux 'file' command can at least tell you what type of content (and thus likely file extension) the file originally had).

Yes /mnt/user is an amalgamated view of all top level folders on all physical drives under /mnt including any pools In this case you have 'fooled' the system into thinking that there is a cache device. You need to be aware of this that as any time you decide to operate in Unraid at the physical drive level y/u will find that files/folders show up at both the drive level and the User Share level - they are simply two views of the same folders/files.