itimpi

That would stop the drive being visible over the network.

No idea - it should not with the settings you have.

If you explicitly copy to disk1 that is the only place files will go so that explains your symptoms. That is true if copying internally within Unraid in that you must not mix a disk share and a user share in the same command. However in this case you are copying from an external device to Unraid storage. If using Uranid's built in file manager it will protect you from this issue as it will not allow a combination of source and target that can cause this issue. What you want to be doing is copying to the 'Mov' user share (which appears at the Linux level as /mnt/user/Mov) as that is a share that spans all drives and pools. That will then obey whatever rules you have set up for that share as to where files should go. The /mnt/user0/Mov path is a variant that only includes array drives having files for the 'Mov' User share omitting any files on pools. You may want to manually move some files from /mnt/disk/Mov to /mnt/disk2/Mov to free up space on disk1 as Unraid will not automatically move any existing files.

No idea I am afraid but it seems unlikely. Maybe someone else will have some similar experience that might be relevant.

Unraid disables a drive as soon as a write to it fails whatever the reason as it is no longer in sync with parity. Connection or power problems are far more common than actual disk problems. The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. If this keeps happening then 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 the problem. 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 and log to a share instead.

That does not normally happen so it is not at all clear what could be running it.

That would work. Keep the old parity intact until the rebuild of the new parity completes just in case a data drive fails while building new parity as that gives a recovery option. Ideally rebuild the new parity in maintenance mode as that would stop any writes being made to a data drive until the parity rebuild completes.

Not sure that powerdown is a standard Linux command? What I have seen always exists is the 'shutdown' command, and you can use shutdown -h now to power down any Linux system including Unraid.

Could not spot anything obviously wrong, but it might help if you mentioned the Unraid share name so we can check. There are some anomalies you should correct. The share starting with I appears to not exist. You can remove any configuration files for non-existent shares by clicking the Tidy button on the Shares tab You have several shares with files on the cache that are not configured to store files there. This implies you manually created top level folders on the’ cache’ pool which then automatically become User Shares, albeit with default settings. I----h shareUseCache="no" # Share does not exist P-------s shareUseCache="no" # Share exists on cache a-----a shareUseCache="no" # Share exists on cache d-----s shareUseCache="no" # Share exists on cache s----m shareUseCache="no" # Share exists on cache

It is an option on the Unraid boot menu. There is also a plugin for testing memory while the system is running, but it can only test memory that is not currently being actively used by the OS or an app. This means that it can only test some of the memory but has the advantage of being possible on a running system. If even 1 error is found (using either variant) then you have a RAM problem.

Parity holds none of your data! What it does have is the information to enable a failed drive to be reconstituted at the bit level by using the combination of the parity drive and all the other data drives. When you do a format then parity is updated to reflect the format. It may be possible to recover the data on the drive using a file recovery program such as UFS Explorer on Windows. That software is not free, but it does have a free mode that can show you what the paid for version would recover.

It would have do this if you do NOT do the format. When you try and do the format you get a dialog warning you that format is not part of a data recovery and will result in loss of the data on that dtive if you proceed.

This means that the drive temporarily dropped offline and then came back with a different id and Unraid is not hotplug aware so it cannot handle this.

Should not affect Clear speed as only the drive being Cleared is written to during to the Clear operation.

I would expect it to take something like 1.0-1.5 hours per TB so the time you quote seems reasonable for a 10TB drive.

If you are going to combine the Unassigned drives into a single volume this would need to be done before any attempt to share them. Have never tried anything like this myself so cannot give any more detailed advice. Not at all clear, however, why the drives do not show up remotely if you have mounted them and set the Share option for them at the UD level. If you attach your system’s diagnostics zip file to a new post in this thread we might be able to give feedback on that.

That screenshot implies you have opened the console at the Unraid host level (probably by clicking the >_ icon at the top of the Unraid GUI) rather than opening it internally within the container by clicking the Console option from the menu shown when you click on the containers icon on the Docker tab.

It should not be required but probably worth doing just to play safe as only takes a few minutes whereas an unnecessary Clear would take hours.

That listing implies folders have at some point been created at the top level of a pool or array drive - not within a folder named for a share. All top level folders on any array drive or pool are automatically treated as User Shares (with default settings). If that was something that happened in the past that has since been rectified then the Cleanup button on the User Shares page will remove any .cfg files that no longer have corresponding folders on your drives.

As long as you do not attempt to do anything to them after the Preclear finishes then they should add without Unraid going through a Clear process. When you add a ‘Clear’ disk to a new array slot the array should start without any parity rebuilding required as a clear disk does not affect parity. You then format them after adding to create an empty file system ready to receive files. A common mistake is to format the drives after the Preclear before adding them to the array not realising this destroys the ‘clear’ state. Having said that there have been reports on some Unraid releases of the Clear state not being correctly recognised - not sure exactly which releases this applies to.

You fixed the corrupt file system on the emulated drive. To clear a red ‘x’ (disabled) state a rebuild is needed.

Was the SSD previously used in Windows formatted to NTFS? If so Unraid will use the existing format unless you explicitly set it to a different format. The default 9n Unraid is to use btrfs.

This suggests that the settings are not being successfully saved to the flash drive. The requested diagnostics may give more information.

That just means that Unraid thinks the drive has just spun up.

Yes, but you will need to separately post that file as it is not automatically included in diagnostics.