itimpi

It is a known issue that if a pool is having problems it can interfere with the behaviour of User Shares.

No documentation that I know of. It has been frequently stated that the only difference is loading plugins, but I guess it does not mean that there is no other difference (although I have never noticed one). Having said that I believe there is a folder on the cache drive (cannot remember. It’s name - probably something like ‘extras’) that can contain packages that are auto-loaded in normal mode and may not be in Safe Mode. The whole idea of Safe Mode is to avoid loading any software components that are not part of the standard Unraid release.

I just don’t see Limetech getting it out that quickly based on past experience. I would like to be proved wrong

Since the problem seems to have started when you added a new drive are you sure your power supply (and the cabling to the drives) is up to it? A parity check is one time when all drives are in use simultaneously.

The only difference in Safe Mode is that no plugins are loaded. All other functionality works the same.

All the LSI ones have support for both SAS and SATA. You just have to get the correct cable for connecting the drives to them.

Each plugin will have a .plg file in the config folder on the flash drive and (typically) an associated folder for holding plugin related files. Deleting these and rebooting means the plugin will no longer be present.

At the very least you will have to go through the process of transferring the licence to the new thumb drive. You should be guided through this process when booting off its replacement. I am surprised that Windows recognises the thumb drive whereas the Unraid system did not are you sure it is really damaged and does not work if plugged into a different port on the Unraid server.

Just though I should mention that using the Parity Problems Assistant that is installed as part of the Parity Check Tuning plugin (under the Tools tab) it is possible to do this. Not had any feedback as to whether users have successfully used it in practice and whether there are any suggestions for improving it.

note I did nothing about tearing the system apart before running a correcting check. I just said that it should be a human who makes the decision as to whether it is appropriate to run a correcting check. If the hardware is performing optimally then it is irrelevant as you will not get a sync error. We frequently see cases in the forum where a drive has started misbehaving for some reason and the user did not notice. By that time they may have corrupted parity badly enough to prejudice data recovery actions.

Normally one wants to try next work out why the parity error occurred in the first place. It could be something obvious like an unclean shutdown but there are all sort of hardware errors (RAM. Power supply, drives) that could be occurring that triggered the errors. You therefore want to be sure you are not currently having any hardware related issues that you know about before letting the system try to correct parity. Once you are happy that there is no hardware error and all drives appear fine you then manually trigger a correcting check via the Mover button on the Main tab.

Samba shares added via the smb-extra file will not show up on the Unraid Shares tab. They should, though I would have thought, be accessible over the network. Probably something that is permissions related or an error in the samba settings you used.

You are likely to get better informed feedback if you post your system’s diagnostics zip file.

I expect that it is likely that 6.10 will go to stable before a fix for a 6.9.x release would be rolled out. Therefore Probably not relevant as Unraid 6.10.0 rc2 is already on a later release of Samba (4.15) than that CVE says is the versions affected.

Thanks for the feedback - I will certainly look into why it resumed when it should not have. I think I know why that might have happened and it is a simple fix but I still need to check it out. I am currently testing a new feature that has been requested a few times where there is a setting to automatically pause while mover is running as contention between mover and parity check slows them both down. At the moment I am not sure whether to make the default for this setting to be on or off. The advantage of defaulting to on is that users who might have otherwise miss this feature was added may realise it when they get a notification saying paused because mover running. I also notice that it looked like your regularity scheduled parity check is set to be correcting. It is normally recommended that you set this to be non-correcting so you do not inadvertently corrupt parity if you have a drive acting up. Then only run correcting checks manually as needed.

For a portable drive I would go with whatever format is most convenient for the systems involved. If one of them is s Windows system then NTFS is likely to be the most convenient.

Unraid only includes disks on which the folder corresponding to the share exists. With the Prefer setting you are saying that you want all the files on the cache, so why do you think disk1 and disk2 should be included?

What share? have you restarted the array since making any changes to the share settings? A bug in 6.10.0 rc2 means changes in share settings do not take effect until the next time the array is started.

Jan 29 10:40:03 shogun kernel: mdcmd (36): check nocorrect Looks like check run on 29th was non-correcting. Jan 30 12:44:39 shogun kernel: mdcmd (37): check whereas the one run 0n 30th was a correcting check. That would explain why they gave the same number of errors found. if you now run a non-correcting check it should find 0 errors as they are (hopefully) now all corrected.

According to the diagnostics the flash drive has either dropped offline or failed because you are getting lots of occurrences of Jan 31 04:49:01 Tower kernel: FAT-fs (sdc1): Directory bread(block 29346) failed Jan 31 04:49:01 Tower kernel: FAT-fs (sdc1): Directory bread(block 29347) failed Jan 31 04:49:01 Tower kernel: FAT-fs (sdc1): Directory bread(block 29348) failed Jan 31 04:49:01 Tower kernel: FAT-fs (sdc1): Directory bread(block 29349) failed

I would think that is when the CA appdata backup plugin ran as is stops all dockers before doing the backup.

this is a new warning in FCP and it sounds as if there may still be a few edge cases to be correctly handled.

Do you we should recommend that Limetech provide the download link for the zip file as part of the announcement for beta/rc releases? Would avoid this sort of issue.

There is difference! The link posted is slightly different to the displayed value (the underlying link has missing - character).

Even though it is empty just the presence of the domains folder could cause that warning so delete the empty folder.