itimpi

I have a feature request as well. I am looking at an easy way to have a script available both via the plugin and from the command line. One way I though of achieving this would be to set up a symbolic link under /usr/local/bin that pointed to the script file on the flash. I could do this myself in the current implementation by running the appropriate commands on each boot of the system, but it would be neater if the plugin did this on my behalf. I cannot think of any obvious downsides (but I may have missed something). Another option might be to allow the plugin to point to an external script file on the flash, but this seems more of an effort to implement and provide no obvious benefits over the approach outlined above.

If you want to be able to RDP into the Windows 10 VM you also need to make sure you have selected a 'bridged' connection when specifying the network settings for the VM so that it is visible on the local LAN. Regarding not having sound when using VNC this is probably because there is no sound hardware specified in the VM configuration? You can specify a virtual sound card by editing the XML of the VM and adding an entry of the form: <sound model='ac97'> </sound> This would also be required to get sound via RDP.

The script I linked to has an option to check if files that have duplicate names also have duplicate contents. It slows down generating the duplicate list somewhat as for those files that match on file names it then first checks if their sizes are the same (which is fast) and if they are then it does a binary compare as well to validate if their contents are equal. If the copies are different this is then indicated. Finding duplicates for files which have different file file names but identical contents is possible using other tools but will take much longer time unless you already have file hashes generated. However I got the impression that in this case we were looking at the case of the same filename occurring on multiple disks (probably as a side-effect of a small misstep when re-organising data on the drives).

If you have a lot of duplicates then you may find it easier to get the list of duplicate files using the UnRAIDFindDuplicates script I created some years ago when I managed to create a lot of duplicates when re-organising my disks. I know you said you preferred not to use a script but if there are a lot of files this can be a fast way to get a list of them.

The only way you can get duplicate files is if you work at the disk level (/mnt/diskX or /mnt/cache). Working at that level bypasses the User Share Level and so means you can create duplicates. If you work purely at the User Share Level you will not get duplicate files (defining duplicates in this case as files with the same path on different drives). If duplicate files do end up being created it is almost universally caused by users moving files between drives and making some sort of error during the process. As an example this can easily be caused by copying files from one disk to another leaving the originals behind rather than moving them.

I do not see how unRAID itself would create duplicate files in normal use. In my experience this is always caused by the user manually copying files between drives. Do you have a scenario where unRAID itself manages to do this? As has been mentioned there are various user-supplied solutions to this problem. How easy they are to use depends on whether you are looking for files with identical paths but on different disks, or whether you are looking for files where the paths differ but the contents are identical.

@digitalfixerIf you are running any sort of adblocker, have you made sure that the unRAID server has been whitelisted? Adblockers are notorious for interfering with the correct functioning of the unRAID GUI.

If your VMs shutdown tidily when unRAID stops the array does then you do not need to do anything, just make unRAID manage the UPS and run through a normal unRAID shutdown if the UPS triggers it.

It is worth pointing out that you cannot get read speeds much above 100 MB/s as at that speed you are saturating your LAN. There are those who have gone to 10Gb Ethernet to up speeds but that is a significant hardware investment and can take a bit of filddling to get your network set up correctly to exploit such hardware.

It is worth pointing out that this technically a ‘Clear’ and not a ‘preclear’. The ‘clear only happens at the time you add the disk to the array and thus the‘ Clear’ is part of the adding process. Preclear is something you do before you attempt to add the drive to the array. Also ‘Clear’ merely writes zeroes to the drive whereas the ‘preclear’ adds read phases before and after the write zeroes phase which does a more thorough test of the drive.

I think that if you changed the second phase to start with a ‘cd’ like in the first phase it will give you the results you want.

OK, but in that case is the plugin capable of using SSL?

6237 is an unusual port for https (it is normally 443 by default). Is that what you have set under Settings->Identification?

You can always download the ZIP file of the release from the Limetech site and follow the manual process to get files onto the USB stick. Going this route does not need the USB Creator tool at all. Make sure you have a backup of your current USB stick (or at least the config folder which contains your key and settings). If you have a backup you can then copy your config folder on top of the files extracted from the zip to keep all your settings intact.

It is an option on your Account Settings for the forum.

Since this plugin is currently deprecated and will not install on the latest unRAID release not sure that the effort would be worthwhile.

The issue appears to be consistent as far as I can see. Attached is the requested file. NerdPack.cfg

I actually have no entry at all in that file for inotify-tools, let alone one set to “yes”! I seem to remember removing it at around the time inotify was built into the standard unRAID release.

I seem to be getting a spurious notification about "inotify-tools set to install"! I cannot find what might be causing that as I do not have any reference to it that I can see in the nerd pack settings. What is actually checked to cause this message to be output?.

If a Share is set as cache only then files will never be moved from the array to the cache. If you want this to happen then you need cache-prefer to be set. Turning on the help in the GUI gives more detail on how the different settings work.

If you just drop the drive in then unRAID will start clearing it (takes 8+ hours for a 8TB drive). During that period the array is available for use. When the clear finishes you will be offered the option to format the drive (which only takes a few minutes) and you are then ready to use the disk.

As you have found running VMs off array disks will never get good performance because in practise they all do a significant amount of writes and these are a lot slower to array drives. Using the cache pool with SSD is frequently used to get better performance than using array drives, but the cache does not get speed improvements by adding additional drives to the cache pool - they are used to provide protection and/or to get additional space in the cache. you have omitted one scenario that may well be best for you - that is to use SSD drives for your VMs that are not part of the cache or array (and are typically mounted using the Unassigned Devices plugin). The downside of this approach is that you become responsible for handling the backup of the VMs (probably to an array disk).

If you copy a file in the ordinary way via a User share then unRAID will ensure that only one copy of the file exists. If it is on the cache it will not be on the array and vice versa. it is possible to circumvent the normal unRAID handling by going in at the raw Linux level and manually copying the same file to more than one location. In such a scenario there is a predictive order in which copy shows up via the User Shares. I suspect a cache copy takes top priority but I am reasonably certain this is more an accident of the implementation rather than something you should rely on. Also if you create such a scenario manually then when mover runs and moves a file from the cache to the array then the cache copy is certainly the one you end up with.

Regarding one of your questions - unRAID never expects a file to exist on both cache and array simultaneously. If you force such a scenario by manually copying files then one copy will end up hiding the other in a User Share and you do not have any control over which copy you are accessing. You can also get confusing behavior where you delete a file and nothing appears to happen as you have now ‘uncovered’ the other file with the same name that was previously being hidden.

Actually if you are using a script then you can use newperms path against any valid path (including ones set up by the UD plugin) and it will work just fine.