itimpi

You might want to try removing the Mover Tuning plugin as there are FCP warnings in your syslog about that version not being compatible with unRaid 6.8.3.

Install the User Scripts plugin as that makes it easy.

The question of being able to use the SD-Card slot is likely to depend on whether each such module has a unique GUID or whether Dell re-uses the same GUID on each such module. Unraid would require each one to be unique.

If server A is no longer going to be used then another option is to avoid transferring the licence and exploit the fact that all user settings are stored in the config folder on the flash. Make backups of both flash drives in case you make a mistake Copy the config folder from the trial flash being used by server B onto the licenced flash being used by server A. Remove the flash from server A and use it to boot server B and it will come up with all settings intact.

You cannot have the unRaid GUI and a container using the same ports I do not use swag so not sure what settings you should use for your particular setup.

Stop Docker and VM services under Settings Change Use Cache setting to Yes Run mover from Main tab to get files moved to array When ready to move them back: Change Use Cache setting to Prefer. Run mover from Main tab to get files moves to pool (cache) (optional) set Use Cache setting to Only to stop option for them being created on array in the future.

Handling of unmountable drives is covered here in the online documentation that can be accessed via the Manual link at the bottom of the unraid GUI.

According to your screenshot you have set up swag to use ports 180 and 1443. You can change the ports the unRaid GUI uses under Settings -> Management Access.

You would need to get it moved to a pool (cache) so it is no longer on the main array. This is also desirable from a performance perspective.

In principle the firmware in the drives should reallocate bad sectors as soon as they are written to. Using the manufacturers test software should support this.

That will cause problems as Linux is case sensitive and Samba (SMB) is not. In such a case you will find that one of those folders appears under the share contents and the other will not.

XFS repairs are normally a matter of minutes. Perhaps the section you saw was referring to ReiserFS repairs as they can definitely take hours.

There have been those who have tried to develop user scripts to have functionality along these lines. They try to exploit the fact if you manually put the same file in more than one location then the copy that is shown under a User Share is the first that is found when searching the pools and then the array disks in order. However these scripts then have to handle how to get the right files onto the pool (cache) and how to later handle backup onto the array.

Never heard of this happening before without the user taking some action.

There is no functionality of the type you describe in unRaid. A file is only ever meant to exist in one place - either on the array or on a pool (cache).

Parity2 will be calculated using all the data drives and as such does not need parity1 (it is perfectly valid to have parity2 without parity1). While calculating parity2 if parity1 is also present then the opportunity is taken to check it and correct any errors found. it is also possible to have a scenario with parity1 present and 1 data disk missing. In such a case parity1 is being read to emulate the missing data disk while building parity2.

Those settings look fine. When doing a New Config then you can put the data drives in any position you like as you are going to rebuild parity. Definitely worth doing it at this point to suit how you want them to end up.

what was the state of the ‘emulated’ drive before the rebuild? A rebuild would not change that status - it would just now apply to the rebuilt dr9ve.. it might be worth providing your system’s diagnostics zip file (obtained via Tools -> Diagnostics) so we get a better idea of the current state of your system.

in step 4 it is better to have both includes and exclude settings empty as that means ALL anyway. If you set explicit values and you later add another drive your would then have remember to update the setting whereas if you have left the entries blank it is automatically included.

Parity works at the raw sector level and has no idea what is the meaning of the bit pattern in any sector at the file system level. In other words it has no idea what XFS even means - it just understands a disks consists of a large number of sectors. When you do a rebuild every sector is rebuilt to its expected content so what was any sector before the rebuild is irrelevant. That is one of the reasons a rebuild can never be used to change the file system on the drive. when you did a format in unRaid it treats this as a series of writes to sectors just like any other write to a parity protected array. It is therefore updating parity during the format process so that it reflects at the sector level whatever the format process writes.

This is still the behaviour around pause/resume in that unRaid built-in reporting only gives figures for the last increment. It might be worth mentioning that if the Parity Check Tuning plugin is installed it will give the correct information in Notifications raised by the plugin and will also update the Parity History information so it is correct for the whole run taking into account any pauses or resumes. It will do this even if you are not using its capability of running the operation in increments.

I suspect this is a BIOS problem and nothing to do with unRaid. How are the disks connected? You may want to find a setting that stops them being treated as potentially ‘bootable’ as some BIOS’s get upset if they find too many - and I seem to remember 12 being the magic number that if you exceed can trigger this behaviour.

If there is a ‘Previous’ folder on the flash drive it can be removed, but that will mean you can no longer downgrade via the GUI. If you do not want to consider a larger drive then You can always use the manual method of upgrading by downloading the zip for the release from the Limetech site and then extracting all the bz* type files to the root of the flash drive over-writing the ones already there. A similar method can always be used to downgrade as well. A good idea, though, to backup the flash drive before making any changes.

Theoretically it should not matter but anecdotal evidence suggests USB2 is still more reliable. I think one of the reasons may be that USB3 drives seem to run much hotter than USB2 ones and that is not good for the electronics of something left permanently plugged in. I would think is going to improve over time as the chipsets get more energy efficient.

This is because the format command would have updated parity to say that the drive contains an "empty" XFS file system. When you tried to format the drive in unRaid you would have got a warning dialog saying that a format is never part of a recovery process and any data on the drive you format will be lost and to longer recoverable. Have you tried reading the online documentation online documentation that can be accessed via the Manual link at the bottom of the unRaid GUI to get a better idea of what you should have done?