itimpi

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.

Has anyone seen any suggestion that it might be possible to run "iCloud for Linux" in a docker container rather than needing to be done in a VM? The closest I have seen so far is a container that gives partial integration with iCloud Drive rather than the more complete integration given by "iCloud for Linux". If there is a suitable base container to which it could be added I might try to do it myself but not sure if so what base container I should use. I suspect if not possible that it might be because of the requirements around GUI support but thought it worth asking as it would be a great application to have in a container.

It is always possible it temporarily dropped offline for some reason and is still OK. Unraid does not handle this well although the "Flash Remount" plugin can rectify this sometimes. It could be worth plugging into a PC/Mac to see if it can be read there. Ideally you want the 'config' folder as it has all your configuration information and licence.

I have often thought the documentation should be made far more prominent in the GUI. On my own system I have used the Custom Tab plugin to add a 'DOCS' tab to the main GUI which is far more obvious than the little icon in the bottom status bar of the GUI. This makes the documentation feel far more integrated than the current approach.

When you say the flash drive appears to have no file but does have space used how was this checked? The flash drive is formatted as FAT32 so should easily be readable on any PC/Mac Do you have a backup of the flash drive in case it has failed and needs replacing?

That is a feature of a parity protected Unraid array. When a drive is disabled it is ‘emulated’ using a combination of the other data drives plus the parity drive(s) and the system acts as if the drive is still there. Moving the data off the disabled drive is/was probably unnecessary - just a rebuild being needed to get the drive back to its normal state. The diagnostics might help if you want feedback on that.

Note that the link you give puts to legacy documentation - not the current 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. You may find this section useful as it describes the process in much simpler terms. You may also find the Dynamix File Manager to be of use when moving the data around. It did not exist when the link you give was created so not mentioned there.

The fact a disk is disabled does not necessarily mean it has failed - just that a write to it failed. More often than not this is dies to an external factor such as cabling or power and the disk is fine. This section of 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 discusses this and actions that can be taken. 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.

The correct process for adding new disks is documented 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. As you will see the last step was to format the drive which you said you did. The fact that the subsequent rebuild resulted in an empty file system suggests that the format succeeded so at that point you should have been good to go without the rebuild. there was definitely no need to Preclear the drive which is why it is not built into the core Unraid system. The link above discusses Clear v PreClear. In this case of an old parity drive being reused as a new data drive a preclear just wastes time.

This is NOT anything to do with the pool you have called ‘Cache’. It is that somehow you have also ended up with a User Share called ‘cache’. If you look you probably have a folder called ‘cache’ on one of your drives. You definitely want to fix this and not ignore it.

For anything to do with licence keys you normally need to contact support to get it resolved.

You can always set the access permissions on any mapped drive used by a container to be read-only for all users so it does not matter what user is used inside the container. Would that work for your cases?

The process is not really that complicated and is covered 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. It is mainly a case of being methodical as one works through the drives to avoid accidents. What is useful is suggestions on improving the documentation from those who have tried to use the documentation but find the current documentation insufficient or confusing. it might be worth Limetech starting to emphasise the need to move away from ReiserFS in release notes as I am sure that there are many users who have put off the conversion because they were short of time and did not consider it urgent. However the time when reiserfs support is likely to be dropped from the Linux kernel is starting to get a lot nearer.

It is probably best (and safer) to leave it set to /mnt/user and use the Exclusive Share option that is now part of the 6.12.x releases. That gets the same performance advantages as would be given by /mnt/cache and is less likely to be something you might overlook in the future when making changes.

My memory being what is I do not either 😊

There does not seem to be a parity check running when those diagnostics were taken. Would need some taken while you were experiencing the problem.