itimpi

You need to connect first to the Private share(s) before any Public shares and it then works without problems. You will then connect to the Public shares using the same username as used for the Private ones.

According to your screen shots the ‘data’ folder inside the container is not relative to the / folder inside the container but in a folder relative to a home folder, but the Docker run command IS mapping it at the host level to be relative to /. That will be why you are seeing what you describe.

Not sure what you mean by this. Why do you need multiple accounts since any user you can use for Private shares will also be able to connect to Public shares.

I have pushed an update that should now correctly handles the maximum sector number and no longer incorrectly tells you a sector number is too large when it is not. There is a bug still in the GUI in that you have to press the Apply button to save the settings you have just set up before hitting the "Start Check" option. This is needed to tell other parts of the plugin what range you have set. I need make a change to disable that button until the settings have been saved. You will see I have also added a button that later will help with getting the sector number out of the syslog but at the moment this is not activated to do anything. Please report anything else you notice as feedback always helps with picking up any bugs I missed or giving suggestions for improvement.

No, because under the covers this gets converted to sector numbers for validation. Because I am out by a factor of 2 on the maximum sector allowed any percent above 50 falls foul of the same problem.

Let me see if I can work out what is happening. As far as I know you are the first person to try and use this feature in anger (other than me in testing) so it is quite possible there is an error in the input value validation. Edit: Seems in validating the maximum sectors allowed I forgot to allow for the fact that Unraid reports the size of the parity disk in 1024 byte units while sectors are only 512 bytes. I will get this fixed and issue an updated plugin.

on the docker tab click on the container and select the Edit option on a drive mapping click on the Edit option on the resulting dialog there is an option to set the Access mode You probably want to set the access mode on any path that allows access to your data files.

If it is installed then Parity Check Tuning plugin corrects the speed recorded in the history to a value that accurately represent the check speed (although there can be a short delay after the check finishes before this happens). If the plugin is not installed then if a check is manually paused/resumed the speed Unraid shows will be incorrect as it does not take account of the pause and assumes that it managed to check the whole disk in the time between the last resume and completion.

What access mode have you set in the drive mapping for Krusader? I believe that for dynamic changes it needs to be one of the ‘slave’ modes.

It is possible to get ‘false positives’ for Pending Sectors which correct themselves the next time the sector is written. However with that many there is quite likely to be a genuine problem. it is probably worth running an extended SMART test on the drive. The results of that will give more information on the health of the drive..

use the main array for cold storage of your media, and then create as many SSD pools as you need for cache/docker/VM purposes. If the pools contain multiple devices then they can be made redundant and you can select any of the RAID profiles that BTRFS supports.

Probably not as the swap file is only used to swap out applications

Unraid does not care if there is a monitor attached or not so it is likely to be something in the BiOS (you might want to also check it is set to not want a keyboard). Many people run UnRaid in ‘headless’ mode (me included) and I think you may well find that the dummy HDMI plug will be needed .

At the moment you have to manually search the syslog for the affected sectors (it will typically be near the end if you have just run a check). I was intending to add a button on the input page that would scan the syslog and pop up a dialog with any sectors found so that it is much easier to both know what sectors are involved and to make it easier to select them. I had been waiting on some feedback on people trying to use this assistant and finding it useful before putting the work in to implement that option. Sounds as if it is definitely going to be wanted Looks like you added an extra 0 on the end. I will improve the error message to include the acceptable range which might help with picking this up.

OK. Just thought I should check. However since the underlying problem seems to be that for some reason the plugin has not picked up a sensible value for the warning threshold from UnRaid it was not going to help. It is late here so it will probably be tomorrow morning before I work ou what I can ask you to supply that might help me work out why a sensible value is not being obtained. you are not actually 0n the latest version of the plugin but I do not think that is why you are having problems .

Strange the log shows that the plugin thinks the warning threshold for the drive is set to 0C at the UnRaid level I’ll think about what you can provide that will help me track down how this can happen. as an aside you seem to have set the pause threshold to a negative value - is this intentional? It would mean that if everything was working as expected you would only get the pause when the temperature went ABOVE the warning value. It would also mean you would normally get a temperature warning from UnRaid as the temperature crossed the warning level. Normally this setting in the plugin would be a small positive value to pause at that amount below the UnRaid warning threshold.

It is perfectly feasible to straight to the latest UnRaid release. This wiki article should answer your questions even though it is quite old now. Feel free to ask questions if you need clarification.

You cannot use classic Linux RAID support with UnRaid. The md device driver included in UnRaid replaces the standard Linux version and the mdadm command has been customised for UnRaid specific use.

It is better if you provide your system’s diagnostics zip file (obtained via Tools->Diagnostics) as this contains more information. handling of disabled disks is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the UnRaid GUI.

If you turn on the Testing mode logging and select the option to write to the flash drive that should create a log file that will provide enough information to try and work out why you are getting problems. Can you also please confirm what version of the plugin you are running?

An automatic parity check is only run if UnRaid did not successfully stop the array before a shutdown/reboot or you have one scheduled to be run at regular intervals and the scheduled time has been reached. One of these events must have happened if UnRaid started one without manual action.

Disks used in the UnRaid array have to be partitioned and formatted by Unraid.

It has just occurred to me that if you have the Parity Check Tuning plugin installed then you might be able to investigate this far more rapidly using it's Tools -> Parity Problem Assistant feature? That feature was developed for exactly your scenario but I have never had any feedback on how useful it turns out to be in practice so would be interested to get some (plus any suggestions for making it more useful).

The first set of diagnostics shows the parity check starting but only lasts for s few minutes more so no indication of what sectors had the problem. Are you sure they were taken AFTER the 2 errors occurred? the second diagnostics sdlog shows which sectors had the problem as it has these entries May 31 13:51:10 Nasgard kernel: md: recovery thread: Q incorrect, sector=18795850688 May 31 14:32:14 Nasgard dhcpcd[1903]: br0: failed to renew DHCP, rebinding May 31 15:52:33 Nasgard emhttpd: spinning down /dev/sdj May 31 15:52:33 Nasgard emhttpd: spinning down /dev/sdh May 31 15:52:33 Nasgard emhttpd: spinning down /dev/sdi May 31 15:53:47 Nasgard kernel: md: recovery thread: Q incorrect, sector=20466240808 May 31 18:14:49 Nasgard kernel: md: recovery thread: Q incorrect, sector=22417914176 May 31 19:46:33 Nasgard kernel: md: recovery thread: Q incorrect, sector=23565254352 May 31 20:12:20 Nasgard kernel: md: recovery thread: Q incorrect, sector=23959071080 May 31 20:38:19 Nasgard emhttpd: spinning down /dev/sdb May 31 20:38:19 Nasgard emhttpd: spinning down /dev/sdc May 31 21:30:28 Nasgard kernel: md: recovery thread: Q incorrect, sector=25097677136 indicating the error sectors. However since there were no corresponding enters in the syslog in the first diagnostics it is not possible to see if there was any correspondence in the sectors reporting errors.

you may find this item in the online documentation available via the ‘Manual’ link at the bottom of the Unraid GUI useful in getting back to an operational status.