itimpi

I do not use ZFS myself, but when I google for valid names on ZFS systems the same restrictions are listed. No idea what the effects of not adhering to them might be.

I believe this is a restriction introduced because of ZFS so only applies to the latest Unraid releases. The help built into the GUI tells you what is currently allowed. There is a workaround that is to manually create a folder with the name you want on a drive and that will then automatically become a share of the same name. However if you ever start using ZFS then you will encounter issues with such names.

The process is covered here in the Unraid online documentation.

The easiest thing that occurs to me is to plug a USB hub (borrow one if necessary) into one of the USB sockets so you can temporarily have more than 2 drives attached. You can then use the Unassigned Devices plugin to copy data from the 2TB drives to the 3TB ones.

That is covered here in the online documentation.

Not necessarily. If you have duplicates you need to work out which is the copy you want to keep - in most cases this is the more recent.

The CRC count never resets to 0, so all you can ever do is stop it from increasing.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You could 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 which might give a clue as to what is going on. 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.

How are the disks powered? Do you power splitters? Drives dropping offline randomly can be caused by insufficient power sometimes reaching a drive.

Parity contains no data as such. Instead it has the information needed to recreate a failed drive by using itself in combination with all the other drives. There is a description of how parity works here in the Unraid online focumdntation.

I agree that it is always a good idea if there is any doubt. We regularly see cases where someone makes an assumption and ends up doing something that stops an easy recovery from being possible.

It would start automatically if you restart the array in Normal mode. In Maintenance mode you need to press the Sync button.

Have you pressed the Sync button to start the rebuild?

Earlier releases of the Unraid were not as strict about the capitalisation of the shares .cfg file in the config/shares folder on the flash drive but the latest releases do and you will get unexpected results if the capitalisation is not the same as that of the actual folders on the array drives or pools corresponding to a share.

The diagnostics should include SMART reports for all drives regardless of whether they are in the array.

I would think even a SATA SSD is likely to be faster than your internet or LAN speed which is likely to be the limiting factor in many cases. NVME is more likely to be beneficial for items that run locally such as VMs or Docker containers.

With those settings, the syslog server is just listening for syslog messages from other machines. As mentioned in the link if you want the server to record its own messages you either need to put your server's address in the remote server field, or set the 'mirror syslog to flash' option

Just shows - I have the opposite experience in that all my WD drives have failed while under warranty and the Seagate ones keep going. I think that which manufacturer produces the most reliable consumer grade drives keeps changing over time so very hard to have a definitive conclusion.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information.

I seem to remember there being some issue in earlier Unraid releases where you had to reboot to get this to work. It might be worth upgrading to the latest stable release (7.2.4) and trying again.

The only thing is to use a backup method that means on a restore you have the same folder/file structure as is currently present on the drive. If you do that the change of file system will be handled transparently. An alternative approach if you have enough spare space on the array is to first empty the drive by moving its contents to other drives in the array. As long as you are on the latest stable release this can be done using the mover application that is part of Unraid.

The process is the same for parity and data drives. Missing a step as after unselecting the parity dtive you need to start the array (to make Unraid ‘forget’ the assignment), and then stop the array before assigning it again and starting the array to start rebuilding it.

That is a possibility although in theory the code that resumes after mover finishes does try and work out if it should resume otnot. It could depend on the exact sequence at which things happened. Having said that I think that if you are running a manually initiated parity check it may not always work and assume you have taken control.

The syslog in the diagnostics indicates that you have file system corruption on disk2. You would need to run check filesystem to correct this. The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot so we cannot see why parity was disabled. 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 in the future. 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. The SMART information does not show any issues with the parity drive. Other issues such as cabling (power or SATA) are far more common than dtive isdues so check that again. it may be worth trying to rebuild the parity drive again to get it enabled. If the drive is disabled again then with the syslog server enabled we may get a better indication of why.