itimpi

The process is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release.

Almost certainly as having it too high would make Unraid consider as full any drive that has less than that free. Conversely setting it too low can also cause issues as considering your example Unraid will try to put any new file onto a drive as long as it has at least 10GB free. This means writes of Giles larger than 10GB csn start failing. Ideally you want the value to be larger than the biggest file you expect to write in normal operation.

When you add a parity drive the array does not need to be down while you are building parity - it is only in the special case of using the parity swap procedure which does not apply in this scenario that there is some forced array downtime. Performance is, however, severely degraded if you try to do anything with the array at the same time.

Yes. You might then need to do editing of share properties if you had non-default settings for any if them.

I recommend doing this on a different machine rather than in situ on the server do this issue is then not relevant.

You can always revert to doing things manually as described here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.

The guide has separate list of steps for 6.1.5 and earlier and the 6.12 series so is up to date as far as I know

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

Assuming you are talking about the main Unraid array, then array does NOT need to be down while it is rebuilding a data drive or building a parity drive contents. It will only be down if you do the operation in Maintenance mode. If however you have the array available while either parity or a data drive is being built then any read/write operations to the array badly degrade each others performance while they are both running, but as long as you are aware of this and the amount of read/write to data drives will be minimal this is normally an acceptable compromise. Note these statements apply to the main Unraid array which is not limited to XFS as drives can also be in BTRFS and XFS and they can be mixed - it is just in the main Unraid array each drive is a free-standing file system. There is an exception to this statement in what is called the Parity Swap procedure where you are trying to simultaneously upgrade a parity drive to a larger one, and then use the old parity drive to replace a (possible failed) drive in the main array. In this case the array is not available during the initial phase while the old parity drive content are copied to the new larger parity drive, but it IS available at the second phase where the array drive that is being replaced is having it contents rebuilt.

Yes once you have made the new drive be the 'cache' pool (the /mnt/cache drive).

Delete the config/shares/system.cfg file from the flash drive. Probably not necessary but I would suggest rebooting. Since it appears you got corruption 0n the flash dtive you may want to plug it into a PC/Mac and run chkdsk on it. when you now go to the Shares tab it should now have default settings. You need to change anything there you do not want to be default value.

Never heard of this behaviour before! I think a bit more digging into why you get it needs doing, although I am not sure what the next steps are at the moment. Maybe if you attach your system’s diagnostics zip file to your next post in this thread it might give a clue. it is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

If memtest fails then that is definitive. If it passes you can still have a RAM issue when the system is under load so in such a case the solution is often to run with less RAM sticks installed.

You can skip steps 4 & 5. However since all your settings and licence are in the 'config' folder on the flash drive you could also simply follow the procedure and at the end copy across the config folder and all its contents from the zip you have overwriting the one on the flash drive.

Yes. I suggest when that happens you post new diagnostics plus the syslog that is stored in the 'logs' folder on the flash drive.

Is the current cache pool a SSD or a hard disk? What will the 4Tb one be? What file system is it using? Alternatively if you attach your system’s diagnostics zip file to your next post in this thread we can get this information from there. it is always a good idea when asking questions to supply your diagnostics so we can see details of your system, how you have things configured, and the current syslog.

The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

You might find this section of the online documentation accessible via the Manual link at the bottom of the Unraid GUI useful? Feel free to ask for clarification if needed.

The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

That looks non-standard so something must be changing it. It normally has owner and group both as 'root'. All folders directly under / should have the same permissions in my experience. You could try booting in Safe Mode and checking again. That would tell you if a plugin is changing it.

The purpose of the patch is to get around the fact that certain types of errors in Docker templates used to silently get ignored, and with 6.12.8 if you have them the docker container can fail to start. There seem to be many users with this issue on frequently used containers so this plugin was created to get back the old behaviour to reduce support load. If you have no containers that have this issue then you can simply tell Fix Common Problems to ignore it.

Have you checked that your Connect (myServers) plugin is up-to-date? That looks like an error that might originate from that plugin.

Either.

No idea how you do it, but it needs to be enabled at the ProxMox level as there is no setting for this at the Unraid level. Unraid will just query to see if it is available.

It is possible you are running into a power issue as the parity check is one time the PSU is likely to be under maximum load.