itimpi

It probably depended exactly when you looked at the speed At any point the speed is determined by the slowest drive currently active. With multiple drive sizes you will see it slowing down as a particular size of drive gets to its inner tracks, and then jumping up again when the build gets past the size of that drive and the next drive size becomes the limiting factor. This pattern can repeat for each drive size.

The .page files are not really designed to work outside the Unraid GUI unless special action is taken in the PHP code to support this which if probably why you got the errors you mentioned. In particular the code to handle multi-language support can sometimes have unexpected side-effects. I was hoping that you might get useful error messages to help with debugging.

A parity check does not even know about dockers so it will not be that stopping them but something else. for anyone to be able to give any sort of sensible suggestions as to why this is happening to you then you will need to provide your system’s diagnostics with the logs in them covering a period when this happens.

I have made it clearer that the options listed are all OR selections so you only need to do one of them (although there is no damage caused if you try more than one of them).

This was not present in the 6.9.2 release either although it is in 6.8.3! It just seems to be a wrapper that redirects to running the 'install' command.

You could try running the .page file from the Unraid console via the php -f option so it executes within an Unraid context in case the php conflicts with something that Unraid adds as standard to .page files Also including a line reading error_reporting(E_ALL); // This option should only be enabled for testing purposes at the top of the file might provide additional information

Did you see the post from Limetech that said: Maybe this is your issue because as far as I can see extraPutty has not been updated for some time.

How are you ‘moving’ the files? It sounds like you may be encountering this issue?

That is quite normal for the speed to go down as one moves towards the inner tracks. Drives spin at a constant speed, so because the outer tracks are physically longer they can hold more sectors and the resulting speed is higher.

Once you have the 14TB drives in place and built with valid parity then you could follow the normal process of upgrading disk1 and disk2 to 14TB (with their data intact). When that completes you would have plenty of space to use unBalance (or a manual move process) to move data off the drives you want to remove and then shrink the array to the drives you want to keep. The relevant procedures are documented in the Storage Management section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI.

Putting the original parity drives back is just going to result in the system rebuilding parity on those drives to match the data drives so as such will not affect data visibility. The diagnostics did not show the array started in normal mode so we could see if any data drives are not mounting (showing as unmountable) due to file system level corruption which would mean their contents would not show until the appropriate action is taken to repair the file system.

No - the idea is to identify that you have a problem that you can investigate further. If the problem is a data drive then you do NOT want it to cause invalid corrections to be made to parity which could then prejudice recovery of that drive’s contents if is later replaced. I would only recommend having the option to correct parity set for a check which is initiated manually after you have decided that is the most appropriate action. Still not clear how data loss can result from building parity as that is only reading from the data drives.

Having a folder with the name of the share (even if it is empty) will make UnRaid display like that. If you are sure the folder on the cache drive is empty then deleting it will correct that. I guess the real question is what you did that resulted in you having that folder on the cache in the first place?

I am confused as writing parity should never affect the content of the data drives Perhaps if you post your system’s diagnostics zip file we might be able to get a better idea of what happened and the current state of the system. BTW: it is recommended that scheduled parity checks are set to be non-correcting - your description makes it sound as this is not how you have yours set?

You don’t need to do #1 if you are going to do #2 as in that case the ‘mover’ application does the transfer of the file to the array.

Since the UPC seems to be stirring up a lot of adverse reaction, maybe the easiest option is to set up a setting under either Settings->Identification or Settings->Management Access (whichever is deemed most appropriate) to remove the Login prompt from the top of the GUI? It can then be defaulted to Enabled until explicitly disabled by the user so new users see it is an option. That might also help with making it clearer that this is purely an optional feature

Set the I thought the recovery action was implicit in the description but obviously I was wrong I have edited the entry and added the recovery action at the start of the bullet point workarounds.

This link in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI both explains what has happened and what you can do about it.

I would expect that to be overkill in CPU terms. On most Unraid systems the drives and/or disk controllers are what limits performance

For basic file serving capabilities any modern CPU should be fine and 4GB of RAM. If you start running docker container and/or VMs then their requirements need to be added.

It needs to be put on the boot drive then a script run during the boot process to move it to its runtime position.

Your docker problem is probably because your cache drive is full and this has resulted in corruption of the docker.img file. There also seem to be quite few shares with the Use Cache=prefer seting which means that you want their contents moved to the cache if there is room. Since you have not set any value for the Minimum Free Space value this means that these shares are allowed to use all the free space on the cache. It is not infrequent for people to use the Prefer setting when what they really want is the Yes setting. I would think you need to check that you really want the "Prefer" setting for these shares (the help built into the GUI explains how the options for this setting work). You also want to set the Minimum Free Space value for the cache to be bigger than the largest file you expect to copy to the cache so that it never gets completely filled. The docker.img file will need to be deleted and then recreated (via the Advanced view under Settings->Docker once you have made sure their is enough space for it on the cChe drive. You can then re-install all the docker container binaries via the Previous Apps section on the Apps tab. This will restore them with all settings intact except for any Custom Networks (which you will have to redo manually).

If that is the requirement then the easiest thing to do is install the Config Editor plugin.

It is really up to you The licence is tied to the USB stick, not to the particular box that is running Unraid.

I would have thought the easiest thing is to shutdown the UnRaid server so that you can plug the USB into a PC/Mac and delete the errant files from there?