itimpi

I'll have another good look. At first glance I am not seeing this on my 6.10.0 test system but I guess there must be an issue somewhere with multiple reports. I want to do some code tidying anyway

If the preclear is still running this could be interfering with the file system check I think

According to your diagnostics you have file system corruption on disk2. You need to run a repair as described here in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

The big advantage of WireGuard over OpenVPN is that it is running even when the UnRaid array is not started.

No, this is VM related the default networking mode if not bridged and using virbr0 will only allow outbound connections.

This is an invalid assumption unless as by default a file exists either on the array or on a pool (cache). You can get the scenario where a file initially created on the cache, and later moved to the array (and removed from the cache) which could be where some confusion arose? If you want a copy on both then you need something to create the backup copy. There are plugins targeting backing up docker containers data and VMs.

An array disk unexpectedly appearing under Unassigned Devices normally means it dropped offline and then reconnected with a different sdX type designation.

What networking mode have you set on the VM? It needs to be ‘bridged’ to be able to access the VM from the LAN. You may need to enable bridging under Settings->Network if you do not already have a bridge set up.

That is perfectly normal for some drives where that field is a bit-dependent field so the raw value is difficult to interpret and can effectively be ignored.

You should now find that the update I pushed out today does not display the warning message, I checked this release out on 6.8.3, 6.9.2 and 6.10.0 rc2 and they all behaved so hopefully nobody will encounter another problem.

There is a bug in the 6.10.0 rc1 users which some users encounter after upgrading where the User Shares option under Settings->Global Share settings gets turned off. Sounds as if you have encountered this? If so re-enabling User Shares will probably resolve most of your issues.

That sort of speed is not atypical. You may find this part of the online manual to be of interest.

Although I can see why such a message might be output I am not seeing it on my system Exactly which version of Unraid are you running? EDIT: Reverted the system to 6.9.1 (it was on 6.10.0 rc1) and now see the error you mention which will help with resolving. I need to see if it also occurs on 6.9.2 It looks as if I might have broken something that affects the display of Settings->Scheduler page on 6.8.3 so that is definitely going to need fixing. As I can reproduce your symptom I will make sure that is fixed as well.

Maybe the change log message is not well worded It is not just syslog messages that were not being translated, but also all the ones that could be output as notifications. The translation file already has a comment suggesting that syslog messages are probably not worth translating although the very common top level ones are there if a translator wants to bother. In fact the ‘testing’ type syslog messages are not even in the translation file as they really are meant for my use in diagnosing issues, and so if testing mode is used I want to see syslog messages I understand After the latest plugin update the visible change that the user will now see is notifications from the plugin being out put in the translated language.

There is a chance that ‘sdb’ is referring to one of the array drives since it is not showing up in the ‘df’ command. You can see on the Main tab the ‘sdX’ type designations for the array drives..

Not quite. When you remove a drive you invalidate parity (unless you have taken a special step to make sure it is all zeroes). what you should do is use the Tools->New Config option and then return to the Main tab to make any changes to the drive assignments (this can involve,adding, removing, re-ordering drives). When you start the array to commit the assignments, Unraid will start rebuilding parity based on the new set of data drives.

All your settings (and licence for each drive) are stored in the config folder on the flash drive. You can switch the drives over by copying the config folders over and then putting the correct .key file for each drive into the respective config folders. Only takes a few moments to do this, but as was suggested first make a backup of the config folder from each drive in case you make a mistake. Once that is done it is just a case of booting the servers off the correct flash drives.

I haven’t done it which was why it was a question rather than a suggestion. I am relatively certain that it is possible though.

Yes - but is done in real time as the data is copied. It is the overhead of simultaneously updating the parity as described here that causes write speeds to the array to be relatively slow.

The letter code can always change between boot as it is assigned dynamically during boot process. It can also happen if a drive drops of line temporarily and then reconnects and is given a different letter.

Agreed that dual parity allows for 2 simultaneous disk failures but with so few drives in the array that is extremely unlikely to happen. probably more important is just to make sure that anything REALLY critical is kept backup so that in the very unlikely case of 2 simultaneous failures it is not catastrophic (just very inconvenient ).

Still not clear to me if you want to keep the 6TB drive in the array or if you are thinking of moving it to an (unprotected) pool outside the array? If you wand to keep it in the array then it would need to become the parity drive as no data drive can be larger than the parity drive. In that case you would have to first get its data copied to the array (presumably using the new 4TB drives you mentioned) before building parity on it. If it will not be in the array then one of the new 4TB drives could become the parity drive for the array.

The diagnostics is a single zip pile which should upload fine.

I am confused - you start of by saying you are not using parity and then ask about parity becoming invalid

A rebuild will never fix an unmountable state as the rebuild simply makes the physical drive match the emulated one. if the format for the drive is set to ‘auto’ and you know what it was before then you can set it explicitly which will cause the repair option to again be offered. With it set to ‘auto’ the system cannot offer a repair if the file system type is not recognised as it does not know which tool to use.