itimpi

The syslog shows: May 29 16:07:45 unRAID root: mount: /mnt/cache: can't read superblock on /dev/sdc1. and the cache device not mounting which explains your symptoms. It is hopefully @JorgeB might give you best achieve on recovering from this.

This is an address assigned when the DHCP server cannot be connected. You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

for any share where you want files to be moved from cache to array you need to have the Use Cache=Yes setting.

If the Resume button does not work then I am not sure there is a way to resume the operation.

If you are running the SMART tests then any failure is an indication that the disk needs replacing. The Short test is so much quicker than the extended test that you probably want to start with it, but only the Extended test is a thorough one.

Have you checked under Settings->Global Share settings that you have allowed disk1 to be used for User Shares?

I would just add it (without using preclear) and let Unraid clear it when it is added. That tends to be the fastest. In terms of which drive it is best to replace that is really up to you. I would first look through the SMART reports for all drives and see if any are showing signs of potential problems such as pending or reallocated sectors.

Under Settings->Global User Share settings you have set restrictions on which drives can be used for User Shares and all those drives are full I suspect you mean to allow some of the other drives be used for User Shares as well? It is normally better to let that setting be left at all drives and then use either Include or Exclude settings on individual shares if you want to restrict the drives they can use. It is easy to forget the global setting when you add additional drives.

CRC issues are connection issues and are normally related to the cabling to the drive. Occasional CRC errors are not an issue, but if they occur frequently then you need to check the cabling.

Have you tried clicking on the Orange icon to see what it says is the problem, and then using the Acknowledge option on the drop-down menu so you only get notified about new changes.

If that is the case then yes there could be permission issue on the drive.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Did you make sure the drive was properly ejected at the Windows end? If not and it is NTFS format it will probably have the ‘dirty’ flag set so it is being mounted read-only. It will probably say this in the syslog.

That suggests it will not finish - it normally takes just a few minutes

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

You need to reinstall the docker container binaries into the docker.img file (a new one should have been created when you re-enabled docket). If you do it via Apps->Previous Apps then they will be re-installed with the same settings as last time.

This was unecessary and maybe even counter-productive as it puts stress on the failing drive. Rebuilding the contents of the failed drive would get back the contents anyway. Sounds like you have encryption set as the default under Settings->Disk Settings? Regardless you can click on the drive on the Main tab and set its format explicitly to a non-encrypted file system which should now let you start the array. Unraid will be quite happy if you want to leave parity1 slot empty. You cannot combine removing parity2 and assigning parity1 into a single step. Moving parity2 to the parity1 slot involves Stop the array and unassign parity2 Start the array to make Unraid 'forget' the parity2 assignment Stop the array and assign the old parity2 to parity1 Start the array to commit the change and build the contents of parity1 (it uses a different algorithm to parity2). Until step 4 completes your data will be unprotected against another drive failing.

The licence is tied to the flash drive that is used to boot Unraid and therefore each server requires its own licence.

The /run location should never run out of space. You need to look to see what is taking up that space.

Preclear is not a standard part of Unraid which is why I suspect that it is never checked for. If you know that you are going to use a disk for parity then there is no real reason for pre-clearing it as the parity sync process writes to every sector on the drive anyway. if mover is running then it must be writing or reading array drives so resuming the parity sync will slow down mover. If the pause is being done by the Parity Check Tuning plugin then if you do not want the pause to happen uncheck that option in the plugins settings.

Whatever disk you want to get files off! Parity has no file system and stores none of your data.

All the array disks are free-standing file systems. You can easily access them from any Linux system (perhaps by booting a Linux Live system), but if using a Windows system you need to have drivers for the file system being used. You could also I guess use file recovery software like UFS Explorer to get files off the drives or perhaps Linux Reader software.

Settings->Docker and set it to be disabled.

According to the diagnostics an unclean shutdown had happened: May 26 07:46:50 Nostromo emhttpd: unclean shutdown detected and later this May 26 07:48:20 Nostromo kernel: mdcmd (37): check correct showing a correcting check was initiated which is not normal after an unclean shutdown (unless you started one manually). No idea why though.

An unexpected reboot is normally hardware related. A parity sync is when the system and drives are most heavily loaded so are your sure your power supply is up to this and also your system is not overheating and causing a thermal shutdown. Another possibility is issues with the power cabling if at any point it may not be able to provide sufficient current to all drives and a voltage dip occurs.