itimpi

Could you not set it up using a Trial licence, and then when you gift him then he activate the non-trial licence on his server to replace the trial licence.

Not quite right. Since Split Level has absolute priority then if a drive fills up you start getting 'out of space' errors if items that the split level setting means it should be on a drive nut will not fit.

This. That allows the "TV Shows" and "movies" folders to exist on multiple drives, but not any folders created within them.

No idea. Did not realise that the Mover Tuning plugin allowed for files to be duplicated. The Unraid User share support has a built-ion assumption that any particular file only exists in one place at a time. The duplication would not matter if the files in question are read-only as then you would never see the symptoms you describe. Should be easy enough to test by artificially creating files of the same name but with different content in two different drives and then go through the actions you describe. As long as the files have different contents for your testing you should be able to work out exactly which one you are seeing at any point.

This can happen if you ever get the same filename duplicated in multiple locations/drives (which is not meant to happen). When this happens Unraid will only show the first one. However an action such as delete or rename on that first copy would then reveal the second copy giving the symptoms you describe. The commonest cause of this is when manual copying between drives on the server has been done. Whether this could apply to you I am not sure.

Ok. That is a bug then that I need to look into for the next release. Now that I know what is happening should be easy to fix. That is why there are different settings in the plugin for the two scenarios as I could see the users wanting to treat them differently. Hopefully fixing the above issue will stop it being an annoyance.

Think of 'cache' as a logical function that you set at the User Share level and associate with a pool. The name of the pool is irrelevant so there is no requirement to have a pool actually called 'cache'

Should not be the case unless the parity check triggered a hardware error of some sort.

I have not seen this in my testing. Any idea what the notification is about so I can see which one(s) needs looking at? If you know the approximate time then a syslog covering that would probably help pin it down.

Not sure what you mean by this? As far as I know there should be no change to the plugins behaviour even on latest Unraid releases. Note that the plugin NEVER starts a check from the beginning - this only happens if the core Unraid system starts the check. When this happens there will be an entry in the syslog as a message from Unraid starting the check. If you think it IS the plugin then diagnostics captured while the plugin has the "Testing" level of logging enabled would allow me to confirm what is starting the check. There have been a couple of instances where people have managed to set the standard Unraid settings to run at unexpected intervals. This shows up in the /etc/cron.d/root file in the entry after "# Generated parity check schedule:"

That was not really meant to show to the average end user. It was only meant to show when I have set a special 'experimental' setting in the plugins .cfg file. The whole docker related feature has proved more problematical than expected so may never make it to general release. It is helpful when I AM running in experimental mode to see that prompt as in that mode the fields do need to be visible and it is a reminder there is potential work outstanding if this feature is ever going to progress further. I AM making changes relating to the 7.2 release and the move to making the GUI responsive so there will be a release in the not too distant future so that should tidy up the above issue as I will make sure the prompt does not show until/if the feature is finally completed.

Why not simply have an option to not pause if a certain % reached when the end of an increment time is reached. This should be easy to implement as is conceptually much simpler and seems to give basically the same benefit. Having said that I am not sure how much benefit this will really add as in most cases once you are splitting the check across multiple days then what is the big gain from finishing it a day earlier?

Not easy to see a way to detect that you sometimes want to be told about mover running and not others. Why not just switch off the "Send notifications for mover or backup running" option then you should not get any notifications of this sort? You can also disable the option to pause parity checks running when mover starts as an alternative. If you are running mover as frequently as hourly this might be sensible,.

An automatic check is one that is started by Unraid if an unclean shutdown is detected. The next release of the plugin will tell you whether the reason for the unclean shutdown is the system crashing on not being able to cleanly stop the array. Have you set the option in the plugin to restart array operations from point reached the next time the array is started? Note, however, that the restart only happens if the array was cleanly stopped. If you are getting automatic checks after a reboot then this is not the case and that will need resolving first.

The command you used is wrong because you have used the wrong device name. and even if it worked would have invalidated any parity. You should run this from the GUI as it would then automatically select the correct device name and it would then keep also avoid invalidating parity.

You are likely to get better informed feedback if you attach your system’s diagnostics (with everything in the one zip file) to your next post in this thread. It is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

This only applies if the cache pool filled up and so the share overflowed and was written to the array. In such a case when if space subsequently becomes available on the cache then mover moves files from the array to the cache. It has nothing to do with how often a file is requested.

You can use the New Config tool for that as long as you are only interested in the data on the 'good' drives. The tool is covered here in the online documentation.

If anything I think this is more likely to work. If sending to a remote server the network has to stay operable long enough for it to get there, whereas when being written locally it should be faster. Having said that I am not sure I have seen a comparison of what is captured when you write locally as opposed to when you write remotely to give a definitive answer. The one that is more likely to work is the "mirror to flash" option as that does not use the network.

Are you sure you have the syslog server configured to actually write something rather than just listen? To get something written you need either mirror to flash option which is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field and log to a share instead.

It DOES work! It is mentioned in the syslog server link.

The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

I thought the old ‘config’ was copied across so the focker templates should be there.

No. Docker config is saved on the flash drive. Appdata contains the working set of files for installed containers.

I see nothing in the Odroid H4+ documentation on the hardkernel site that suggests that 3.5" HDD can be powered directly from the Odroid board. I would expect each HDD to have its own power supply, and then just have a SATA connection to the Odroid board.