itimpi

Have you tried running a scrub on disk2 (which is the drive the errors mention)? You are likely to get better informed feedback if you attach your system’s diagnostics 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.

That shows there is an issue with the docker setting the permissions correctly, not with the owner being ‘nobody’ and the group being ‘users’ on a directory I would expect them to be drwxrwxrwx and on a file -rw-rw-rw- These are the permissions you would get if you ran Tools->New Permissions on the share to set them to standard Unraid defaults.

What share is it that you think is a problem? None of the shares you have set up to move files from cache to array have any files on the cache so there is nothing for mover to do.

I suggest you post the result of ls -l command to show the full permissions of the file in question. It could well be something other than the username that is the issue. i have all my Unraid files owned by ‘nobody’ and can access them with no issues from all my systems with no problems which is why I suspect some other issue.

Not quite sure why you think you have a problem? The "nobody" user is the standard default in Unraid.

Yes, and has been present for the several releases now.

Not really as the Unraid approach to parity is very different to a traditional RAID system. As an example the Unraid array has each disk as a separate file system (that can be read on another system by itself if needed), and you can use a mix of the supported file systems in the Unraid array. It WOULD, however, allow for any 2 disks failing in the Unraid array and being able to recover their contents.

No parity drive can be smaller than the largest data drive so you would need one of the 4TB drives to be a parity drive. there is a description of how Unraid parity works here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

This would have also formatted the emulated drive thus wiping its data. You would have needed to run the procedure for fixing disk1 to make it mountable before attempting any format.

You might need to check that your Minimum Free Space setting is causing this. We could probably tell if your posted your system’s diagnostics.

@jmt380 So far I have not been able to replicate your issue when running a test on 6.12.9. Just in case it is something specific to the way you have your array setup perhaps you could let me have a screenshot of your Main tab so I can try and set up my test environment to mirror that as closely s possible. Alternatively a copy of your diagnostics would allow me to extract the needed information from there.

@jmt380 Thanks for reporting this. I will have to see if I can recreate the problem on 6.12.9 and/or 6.12.10. I must admit I have not gotten around to explicitly tested against those releases thinking nothing in the Release Notes looked like it would break the plugin - but it looks like that might have been optimistic 😒. The fact it occurs every 7 minutes tells me it is the monitor task the plugin runs while a check is in progress. The CustomMerge file mentioned is a built-in Unraid one that I have made use of and it is possible something in it has changed that I need to take account of (or write a replacement for it so I no longer need it).

I simply mounted the remote shares in Unraid using Unassigned Devices and then ran rsync from the Unraid end using the User Scripts plugin. You are going to need to sort out what needs doing for one machine to see the others shares. Cannot help with the details of doing that I am afraid as I have a different combination of end devices from you.

I have used rsync to backup for backing up before. You should give more details about why it did not work. Have you successfully managed to get a network connection made between the two machines so that they can see each others shares?

Was disk1 showing as unmountable before the rebuild (as a rebuild does not clear an unmountable status)? Have you followed the procedure documented here the in online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page for unmountable drives? The new disks showing as unmountable is expected until you format them from within Unraid to create an empty file system ready to receive files. However you do NOT want to do this while disk1 is also in the list or you will format disk1 as well thus losing its contents. Not sure how you could be looking at its contents since it is unmountable?

The fact that in the special case of 1 data drive and 1 parity drive they are mirrors of each other is an accidental by-product of the algorithm used to calculate the contents of the parity drive. The moment you add any additional drives to the array this will no longer remain true. What I do not see is why you need them to be mirrors? With 1 parity drive and 2 data drives you still have redundancy against any single drive failure.

This would be expected if the files were being cached at that point and had not been moved to the array.

Does in now mount and show expected contents when array started in normal mode?

Strange - should work Have you tried rebooting and then trying to update? If you have and still fails then it might be worth posting diagnostics to see if we can spot anything.

You need to have the standard schedule set to start checks as the plugin does not initiate the check (as this is still done by Unraid) but set the option for cumulative parity checks to No if you want the plugin to handle running the checks in increments.

All drives attached to the machine (except the boot flash drive) count at the point you start the array regardless of whether Unraid is using them. Your example shows 7 drives attached.

The port is stored in the config/ident.cfg file on the flash drive. You could edit that file to the correct value and then reboot.

If it is disabled in Unraid (I.e. has red ‘x’ against it) then you will be looking at the emulated drive rather than the physical one.

Whatever the container is looking for it to appear as inside the container. Basically the container path is where the container ‘thinks’ the file or folder is located and the other part is where it is really located at the Unraid level.

What is the emulated drive in Unraid showing? Whatever appears there is what would appear if you rebuilt the drive. when you say the drive is ‘empty’ is that looking at in Unraid array or somewhere else? You are likely to get better informed feedback if you attach your system’s diagnostics 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.