itimpi

@pooley182 Not sure how the symptoms you describe could happen. Can you check the contents of /etc/cron.d/root as that should have entries for when the pause/resume will happen. Maybe that does not correspond to the settings you have set in the plugin's settings for some reason. That would indicate that for some reason the settings are not getting saved to the flash drive. You could also check that the /boot/config/plugins/parity.check.tuning/parity.check.tuning.cfg file seems to correspond to the settings you think you have set. There will also be a /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron file there that should have the same settings as in the plugin's entries in the /etc/cron.d/root file. To be able to do a detailed analysis I would need a copy of the syslog with the 'testing' mode logging set in the plugins settings and the problem recreated.

You need to put a copy of your current licence .key file into the ‘config’ folder on the new flash drive to get the option to do a licence transfer.

For anything to do with licences you should contact support.

The end of the syslog in the diagnostics is showing repeating Mar 7 12:18:57 UNRAID kernel: critical medium error, dev sdc, sector 1302606 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 Mar 7 12:18:57 UNRAID kernel: sd 36:0:0:0: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Mar 7 12:18:57 UNRAID kernel: sd 36:0:0:0: [sdc] tag#0 Sense Key : 0x3 [current] Mar 7 12:18:57 UNRAID kernel: sd 36:0:0:0: [sdc] tag#0 ASC=0x11 ASCQ=0x0 Mar 7 12:18:57 UNRAID kernel: sd 36:0:0:0: [sdc] tag#0 CDB: opcode=0x28 28 00 00 13 e0 4e 00 00 01 00 which indicates a problem with the flash drive which I expect explains your symptoms as it would mean that Unraid cannot save the disk configuration.

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.

You would need to separately attach the log file that is being stored in the 'restore' share as that is not automatically included in the diagnostics.

In principle you would look in your system's diagnostics, and perhaps post the zip file for informed feedback. The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. If you want a version that services a crash/reboot then you should enable the syslog server (probably with the option to Mirror to Flash set) to 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.

The SMART report in the diagnostics does not show anything obviously wrong with the dtive. I would try running the Extended SMART test on the dtive. If it fails the disk needs replacing, but if it passes you may some other issue such as bad cabling or insufficient power to the drive.

Note that the parity.check command is part of the parity check tuning login - not a standard part of Unraid. Although it can start/stop an array operation it is definitely not the recommended way to do this (although I find it useful in testing). If you do a lot of commands via that method then make sure you use the 'parity.check monitor' command to make sure the plugin has the latest status. The 'parity.check status' option is then useful to check the status without affecting what is running, and if there is a check running to confirm what type of check it is. By making sure you take the time of an action in the GUI, and correlating that with the time you do the 'parity.check monitor' and 'parity.check status' it should make it easier to confirm exactly what is happening.

Is the share you are trying to use at the Unraid end set to be ‘cached’ (I.e. it has both primary and secondary storage set in the Unraid settings for the share)? I have seen regular reports that this can lead to ‘stale file handle’ reports happening after ‘mover’ runs with shares being accessed via NFS. I am not a NFS user myself, but it is apparently an inherent problem due to the way NFS tracks files. The way to avoid this issue is to either not have the share not set to be cached (I.e. no Secondary storage set for the share at the Unraid level), or to use SMB sharing instead. Whether this your actual problem I am not sure. You may get better informed feedback if you attach your Unraid system’s diagnostics (with everything in the one zip file) to your next post in this thread. Also mention the name of the share being used. 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 steps look good. If in doubt at any stage stop and ask here in the forum. BTW: Make sure you have a backup strategy for anything important that keeps a copy off the server. Parity is not a substitute for backup.

I do not think that there is a possibility to bring back the array in a state where recovery of the failed disks is possible. You might want to wait and see if @JorgeB concurs as the best expert on recovering from various combinations of disk failure. If it is just a case of getting your array back into a usable state with just the contents of the remaining drives then you can use Tools->New Config to do this. In such a case easiest to start with the option to initially retain all assignments. When you then return to the Main tab all drives will be marked with blue icons (I mention this because many people forget to hit the Apply option in the New Config tool and then you do not get the blue icons), and you can remove the drives that have failed. If you now start the array Unraid will recognise the existing data drives and bring them online with their data intact, and will start rebuilding parity based on those drives.

Are you really sure that disk3 has actually failed rather than simply being marked as disabled? I guess the same question applies to the other problem drives. Are you able to get SMART reports for the drives?

Since that is an XFS variant then I believe that normally one would expect a file system check to be reasonably fast (do not use encrypted file systems myself so could be wrong). The only reason that the initial check normally takes a long time with XFS is if the superblock at the start of the file system cannot be found and a scan of the entire disk has to be made to look for a backup version but then you get a message saying this is happening. The repair should still be fast unless the file system is really badly corrupted and in such cases it is rarely worth doing the repair as most of the files/folders end up in the lost+found folder which can take significant manual effort to resolve so it is normally easier to restore from backups.

What format was the drive? With XFS for instance fixing normally only takes a few minutes unless the drive is corrupted beyond repair. The same applies to the file system check which you earlier mentioned as running all night.

Are you trying to boot in UEFI or legacy mode?

Only the root user can log into the webUI. Users in Unraid are used to control access to shares, and the root user cannot access shares across the network.

Not something I have tried but I suspect that the %U is not being recognised. Maybe someone else has done this and can share how they got it working. When I tried to google it then it seemed to suggest that you could use %S (rather than %U) for Linux users, but that for Windows users you had to set them all up individually.

Traditionally Unraid had a manual process for creating the flash drive, and that still works. Both the tool based and manual one are covered here in the online documentation.

First it is possible the disks in question just have a damaged file system which is stopping them mounting, so you could try to see if Filesystem Check helps. Ideally when one has an unmountable disk it is better to do this before attempting any rebuilds as sometimes the original drive is in a better state than the emulated one. It is worth remembering for future reference that whenever Unraid says it is emulating a disk, then whatever shows on the emulated disk (including an unmountable file system) will be what you end up with if you rebuild the disk. The rebuild process has no concept of data - just of the bit pattern it thinks should be in any particular sector. Failing being able to repair the file system it could be worth seeing if a file recovery utility such as UFS Explorer on Windows can recover the data. That software is not free when trying to recover data but it does have a free option that shows what would be recovered before you have to commit to paying anything.

You might find that the original browser works if you first clear its cache. Seen a number of cases where this seems to be necessary.

@SliMat once you have replaced the disk you might want to consider running the extended SMART test on the removed drive. If it fails that it is definitely on the way out, but if it passes it may be OK.

With XFS when you format the disk you lose about 2% used for creating the empty file system

You say you have copied a lot already to the Unraid system, but as far as I can see the diagnostics show all drives are practically empty!