itimpi

What access have you set for that folder in the containers volume mapping?

I believe so.

Not sure what is going on for you? I get a pop-up allowing me to change the mount point (and thus share name)

At least it means that at some point in the past someone else thought this was a good idea

You are only meant to get told again if it changes The value is saved to the flash drive when you acknowledge it so maybe there is some issue getting the saved value off the flash drive?

If you had never explicitly set anything up then you would have the default settings. Once you set up any setting then the ones displayed get saved and used going forward. I pushed out an update earlier today to give better defaults for those who never change any of the plugins settings. Did you read the built in help regarding how the heat pausing values work? If so and it was not clear maybe you can mention what you found confusing to it can be improved. It is possible to revert to default values by either deleting the .cfg file in the plugins folder on the flash drive, or by removing and reinstalling the plugin. I will think about whether adding a Defaults button adds value - it would be trivial to implement but may be unnecessary now I have mad the initial defaults more like what a typical user would want.

Click on the blue text opposite the '1' in your screenshot (the 2nd line)

Did you try changing the increment frequency to be Daily rather than Custom? I checked and the Custom value is what you currently end up with if you never have gone into the plugin settings to make a change. One of the not-visible internal changes was to how default values are set if the user never explicitly sets values. I can change the Frequency to default back to Daily on such a case. Since you mentioned only having this problem on your 6.9.2 system I will try to see if I can get different behaviour on a 6.9.2 system compared to a 6,10.0-rc* variant.

Always maintains parity was why I suggested doing the Parity Swap procedure twice as each time around you are still protected against another drive failing by the parity you are NOT doing this process on. The first time round you get a 16TB drive as one of the parity drives and the 14TB drive that was parity replaces the selected data drive. During that process you still have the data drive being replaced intact in case anything goes wrong. You then repeat for the Parity Swap procedure to replace the other parity drive with a 16TB drive and get that 14TB drive to replace another data drive.

According to that screenshot you have set custom pause/resume using crontab type entries to pause/resume every 5 minutes! That is the sort of thing I do during testing (one of the reasons I added the crontab format option) but not something I would expect to see in normal use

Those error messages strongly suggest there is a physical problem with that drive. You are likely to get better informed feedback if you post your system’s diagnostics zip file.

The current implementation of Unraid assumes that files only exist in one place (array or a pool) so if I understand what I think you are asking for this would be a major change.

Click on the name and change it to the name you want.

You could use the Parity Swap procedure covered in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI. in theory you could do 2 both parity drives at once but you may prefer to do them one at a time in case you get an error on another drive during the procedure.

Can you please confirm whether the update I have posted has fixed the handling of temperatures on your system by the parity check tuning plugin. I find testing this feature particularly difficult as I have to simulate overheating as my drives do not actually do this. if there is still a problem then raise it in the support thread for the plugin.

Isn’t that already there? blank = not exported italics = exported (hidden) normal case = exported

Giving a valid path and starting the VM service will cause Unraid to create a new copy

What makes you think those indicate an error? They look to me just like a standard message that happens to have the string ‘error’ as part of the message.

Ok - the drive will not be mountable until you have run format on it.

Are you running Unraid 6.9.2 or 6.10.0-rc4? If the former I would suggest installing the Config File Editor plugin to edit the files, while if the latter the File Manager plugin will allow this.

When you started the array after assigning the drives did you run the option to format unmountable disks?

Ok - that screenshot shows there is a problem with displaying or saving the resume value. Not quite sure why, but I would expect to track it down and issue a fixed version tomorrow. There was a major internal refactoring of the plugins code since last months release and although this will help with long term maintenance a few gremlins seem to have crept in that I missed during testing.

The pause is being done by the parity check tuning plugin because you have what looks like a cooling problem and you have set checks to be paused if disks get too hot. Your syslog has messages like: Mar 28 07:07:02 dellnas Parity Check Tuning: Paused Manual Correcting Parity Check (0.4% completed): Following drives overheated: disk1(108C) and Mar 28 07:14:02 dellnas Parity Check Tuning: Following drives overheated: disk1(111C) disk3(109C) Do you have notifications enabled for such events as this would tell you this is happening without the need to look through the syslog. I must admit I suspect that the temperatures should be displayed as Fahrenheit as I cannot believe the disks are really that hot in Centigrade - I will need to look into that. EDIT: I can confirm that the numeric value in the above messages is the Fahrenheit value. A typo means that this happens even when told to display in Centigrade. However this looks like it purely a display issue in the syslog message. if you think that you should NOT be getting temperature related pause then a screenshot of the plugins Settings page would allow me to confirm that the values you have set are OK for temperature related pauses in case a bug has crept in somewhere in handling temperatures.

This is what happens if you try to run memtest when booting in UEFI mode. If you want a version that can run in UEFI boot mode then download it from memtest86.com

Ok - it looks like there could be a bug when you set the increment frequency to be weekly. Using the more commonly used Daily option will generate a valid entry. Edit: fixed version issued