itimpi

what are the share settings? Points to note are: The size of a file is not considered when selecting a drive for a new file. Unraid acts as if it is zero size for drive selection purposes. once a drive has been selected then you will get an ‘out of space’ error if it subsequently does not actually fit. The Minimum Free Space setting should be larger than the biggest file you intend to transfer as falling below that is a trigger for considering another drive for the next file. The Split Level setting wins any contention for selecting a drives. Therefore if it is too restrictive it can force Unraid to try and put the file on a specific drive even though the free space is below the Minimum Free Space setting.

I think it will There is no explicit command to do a read-check as far as I know. You just ask for a check to be started and if you have no current redundancy then a read check is carried out.

They DO if they are plugged in when starting the array. Drives plugged in later (i.e. removable drives) do not count as the check is only done on every array start.

All drives that are plugged in when starting the array (except for the boot flash) count regardless of how they are being used.

Not sure there is a way to do either of the things you asked about Would like to be proved wrong

In your syslog you are getting a lot of Aug 23 20:40:24 sobnology kernel: FAT-fs (sda1): Directory bread(block 32768) failed Aug 23 20:40:24 sobnology kernel: FAT-fs (sda1): Directory bread(block 32769) failed Aug 23 20:40:24 sobnology kernel: FAT-fs (sda1): Directory bread(block 32770) failed Aug 23 20:40:24 sobnology kernel: FAT-fs (sda1): Directory bread(block 32771) failed Which suggests problems with the flash drive. If possible plug it into a USB2 port. I would suggest backing it up and then rewriting it to see if that fixes the issue. If not then the drive may be failing.

One of the best performing Remote Desktop packages in my experience is NoMachine and it exists for both Linux and Windows environments.

not quite sure what you want to do in thenVM? You never need a GPU passed to a VM to run any OS in a VM (including Windows) unless you need that VM to be able to access the GPU. You can access the emulated GPU using a browser with the NoVNC support built into UnRaid, or install the Remote Desktop software of your choice into the VM to access it that way. Lower performance than a hardware GPU but enough for lots of use cases.

If you turn of set any Split level restrictions then Unraid will create directories as needed on each disk as it fills up. No need for any manual intervention. With Fill-up allocation method the only Share setting that would then matter regarding drive selection is the Minimum Free Space value to act as the trigger for moving onto the next drive.

I think something like that is not uncommon if the drive is failing and it starts returning random data on reads. The presence of .REC files suggests that at some earlier tine there had been corruption that was then fixed, so that might have been a warning sign.

Without the Diagnostics/SMART reports is is difficult to guess what the errors might be. For instance they could be CRC errors which were recovered and you simply need to acknowledge them to stop being prompted about them if no more occur.

The syslog shows CRC errors followed by a device reset. This suggests either a power/SZTA cabling issue, or perhaps a general power issue?

Split level always wins any contention over which drive to use. This means it can force a file to a drive that does not have enough room. I would suggest that you set the Split Level to "Automatically split any directory as needed". Split Level restrictions really only make sense if using one of the other allocation methods as a way to keep related files on the same drive, with "Fill-Up" this is will happen anyway. There is a good explanation of Split Level here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

Your example path definitely requires a split level of at least 3 to give the results you want as a value of 2 forces UnRaid to try the first disk. Since you are using the ‘Fill-Up’ allocation method I do not see any advantage to putting any Split Level restrictions on the share unless I am missing something about how you want files split accross drives

According to your diagnostics it looks like your ‘system’ share has files on disk1 and cache. It is worth checking that is what files are there. If you previously had your docker.img file in that location, and your change has resulted in a new empty one being created on cache that could explain your symptoms.

I am not sure what the question you actually want answered is? If the SSD in question is going to be used in Windows why not leave it formatted as NTFS and managed by UD?

My experience is that any errors in such a situation as yours tend to be at the start of the parity check so it is not always necessary to run it to the end.

The parity disk seems to have completely disappeared! The diagnostics show it WAS there and then it suddenly seemed to disappear so there is no SMART information for the drive to try and asses its health I would suggest that you power cycle the server to see if it comes back? Before powering it back on carefully check the power and SATA cabling to the drive as that seems to be the commonest cause of such errors. If it does then try running the extended SMART test from the page available by clicking on the drive on the Main tab. Posting new diagnostics after that should let us see the result.

Thanks for letting me know. You should only get an unclean shutdown if one of the shutdown timeouts trigger. I would suggest you try hitting the button to Stop the array and time how long it takes. You need to make sure the Disk Settings -> shutdown timeout setting is longer than that.

The flash (boot) drive does not count towards the licence limit. Since you have just 6 other drives you should be,OK.

did an automatic check actually start? The reason I am asking is that in testing I occasionally get the plugin outputting that warning and the automatic check does not actually start. I have not identified the exact conditions where the plugin thinks it was an unclean shutdown but UnRaid decides it was not.

At the very least there should be a step 3.5 where you check that the contents of the emulated disk look correct as what you see on the emulated disk is what you will have on a rebuilt disk. You want to avoid pre-clearing the old drive until you are happy this is the case as if not it is highly likely that data can be retrieved from the old drive. Ideally you rebuild to a spare drive and only when this has been successful do you consider pre-clearing the old drive (and it presumably becoming the new spare drive).

You should always make sure you have a backup of your flash drive any time you make a configuration change. If you had done this then you could have used the backup to create your new USB drive and then after doing the licence transfer to the new drive you would have found that your drives were already correctly assigned and the Previous Apps section of the Apps tab would have been populated for restoring your docker containers with their settings intact.

More often than not the disk is fine and the disk has been disabled due to an external factor (such as cabling) and re-appears if you power-cycle the server (although it will remain disabled). It could be worth trying that, and if the disk re-appears post new diagnostics).

You would have to have the drive unmounted to try the ntfsfix command. However looking at your screenshot it says the drive is mounted read-write so ntfsfix is probably no longer required. No idea why the rsync command should fail if the samba share works OK.