itimpi

Note that this does not necessarily mean that it is that process that caused the issue - just that it was the one chosen to be killed.

You might want to look if you have an ‘extras’ folder on the flash drive. Any packages placed in that folder would be automatically installed.

Was it the Extended SMART tests - passing those is normally OK. The other commonly used way to stress test a disk before using adding to the Unraid array is to run a pre-clear on it.

The (undesirable) side-effect of the monitor task stopping running is that if you have the plugin settings set to pause a parity check if you have mover or appdata backup running then when either of those is detected you are likely to get the plugin executing the pause but then not doing the resume so you need a manual resume to continue.

No. You have the pool set to have the Single data profile which gives you maximum space but no redundancy. If you want to be able to recover from drive failure you probably want the RAID1 profile which gives you redundancy at the expense of halving the usable space.

The default contents of the config/go file on the flash drive are simply: #!/bin/bash # Start the Management Utility# /usr/local/sbin/emhttp & you can stop the server and edit the flash drive on another machine to remove everything else that you have not manually added yourself. When you reboot you should now be OK.

You may find this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page will help with this.

The developer requirements for multi-language support are covered in this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

If you think the drive is healthy then the process for rebuilding a drive to itself is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

If you use the option to open a console session from the Unraid GUI then you run commands just like on any other Linux system. Because Unraid is a cut-down Slackware based system then the command available may be limited to the more common (or Unraid specific) ones. The NerdTools plugin can be used to install additional commands. That is an internal consistency check for a state condition that I do not expect to happen, but it should (in most cases) let things run without a problem. Was this error with the latest version of the plugin (2023.07.08) as if so I might give you instructions on how you could gather additional diagnostics to help identify the cause so I can correct for it.

No idea then. Mover logging might give you an idea as to why. There is no reason you should not move them manually using something like the Dynamix File Manager. This is often much faster anyway.

I know that many people use name brands drives such as SanDisk and Kingston without issues. Also although we frequently recommend USB2 as being more reliable than USB3 there is no technical reason for USB3 drives to not work as long as the BIOS of your machine properly supports them as boot drives. Did the ones you got meet the unique GUID requirement (if not they are probably fakes despite the packaging)? Did you try the Manual install method instead of the USB Creator tool - the tool seems to sometimes fail when the manual method will work fine.

Do the files also exist on the main array? Mover will not overwrite files that already exist there.

You could have a 20TB HD in a pool on its own just to host VMs.

It is 5.8GB. Not 5.8TB so it is effectively full.

The commonest cause of this is RAM. It can be either faulty RAM or overclocked RAM.

with exclusive shares they should be equivalent to each other.

Yes there is - there are the standard Unraid messages when an array operation completes that look like this: Jul 10 10:00:43 Tower kernel: md: sync done. time=132325sec Jul 10 10:00:43 Tower kernel: md: recovery thread: exit status: 0 The messages that look like this: Jul 8 21:17:28 Tower Parity Check Tuning: DEBUG: Parity Sync/Data Rebuild running Jul 8 21:17:28 Tower Parity Check Tuning: Parity Sync/Data Rebuild detected Jul 8 21:17:28 Tower Parity Check Tuning: DEBUG: Created cron entry for 6 minute interval monitoring are from the parity check tuning plugin that is not a standard part of Unraid. This currently has an issue that I do not understand where the monitor task seems to stop running and I do not know why. The latest version of the plugin is 2023-07-08 but I suspect you did not have that installed at the time.

Have you checked that the Export option is not set to No on the shares as that would stop them being visible on the network.? if the answer to the Export setting is Yes have you tried running Tools->New Permissions on a share showing no files to see if that fixes the issue?

Unfortunately it is basically the same process. what are you trying to achieve by this conversion? Trying to see if you are expecting something that will not happen.

The sdX type names are irrelevant to Unraid as it goes by drive serial number.

Looks like a XFS file system was found and fixed. You should now see if it will mount

Are you sure your PSU is capable of driving all your drives simultaneously? Have you checked the power cabling as well as the SATA cabling?

Have you actually formatted the data disk from the Unraid GUI using the format option on the Main tab?

You should boot in Safe mode to disable plugins being loaded and then see if the dashboard loads. If it does you then know you have a plugin installed that is incompatible with the 6.12.x releases and you can start looking into which one it is.