itimpi

All Unraid drives are readable on standard Linux distributions.

Then you simply need to add the right header to your page file. As an example in my Parity Check Tuning plugin I use: Menu="Scheduler:1b" Title="Parity Check Tuning" Tag="gear" --- to add a new page to the Scheduler section of the Settings page. You may want to add it to a different section? I then use Menu="About" Title="Parity Problems Assistant" Tag="gear" --- to add it to the "About Section" of the Tools page. You can look at the existing page files stored at /usr/local/emhttp/webGui to see examples. That also shows how to create a new section within an existing page (use the About.page as a simple example).

The question I guess is why do you want to disable mover in the first place? The closest you could get is to set it to run once year.

Not quite sure what you are trying to achieve. What I think you are saying is that you are going to have 2 page files - one located on the Settings tab and one located on the Tools tab? If that is what you want it will be easy to achieve. Do you really want the one on the Tools tab to go into its own Disk Utilities area rather than adding it to one of the existing ones? This is achievable but a bit more work than adding it to one of the existing areas.

If you have reset the array via Tools->New Config then there is no need to put the old disk back - just build parity with your new parity disk based on the data disks you want to keep in the array. Where you physically connect the drives is irrelevant as Unraid recognises them by their serial numbers - not by where they are connected.

Probably a better option is to mount that backup pool via Unassigned Devices as UD devices are not part of User Shares. UD is the way you are expected to handle removable devices.

Have you read the help built into the GUI about how the Use Cache setting on shares work, and how this interacts with Mover? There is also more detailed descriptions in the online documentation. As an example setting Use Cache to No which you mentioned just stops new files going to the cache but leaves any files already untouched.

Have you tried simply giving the vmdk without conversion by typing in the path manually and making sure it is set to scsi?

Exactly which log is that is the 23MB that you mention as that sounds rather large for a log? The code looks like it it is trying to anonymize entries in the syslog in the diagnostics created by Plex Media server. The solution would be to stop Plex generating all those entries in the first place. Sounds as if your Plex is set to do a lot more logging than is normal.

That could indicate it is corrupt and contains binary data rather than text?

mdResyncPos is set to be none-zero when a parity check starts and its value indicates the point currently reached. You can then use mdResync to test if it is currently running (this is 0 when it is paused).

I notice that the disk.cfg file in the diagnostics is 0 bytes which is not normal. Not checked all the other .cfg files (they should all contain human readable text).

Do you have any ad-blockers installed? If so you should make sure you white-list your Unraid server as they have been known to interfere with the Unraid GUI. you might want to also turn off anything that provides custom themes to the GUI in case that is the cause of the issue.

You can do that if you do not mind your data drives being unprotected until the parity rebuilds complete.

U

Could not see anything in diagnostics to explain this Is your server exposed to the internet? You may find a utility such as UFS Explorer or something equivalent can retrieve deleted files off the drives.

You are getting the following error repeating in the syslog: Jun 4 10:48:01 Tower crond[1974]: failed parsing crontab for user root: #015 You should perhaps post the output of cat /etc/crond.d/root if it is not obvious what is causing that. You also have the following: Jun 5 02:33:34 Tower kernel: sd 10:0:3:0: [sdi] tag#1210 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=6s Jun 5 02:33:34 Tower kernel: sd 10:0:3:0: [sdi] tag#1210 Sense Key : 0x3 [current] [descriptor] Jun 5 02:33:34 Tower kernel: sd 10:0:3:0: [sdi] tag#1210 ASC=0x11 ASCQ=0x0 Jun 5 02:33:34 Tower kernel: sd 10:0:3:0: [sdi] tag#1210 CDB: opcode=0x88 88 00 00 00 00 02 8f 36 16 20 00 00 04 00 00 00 Jun 5 02:33:34 Tower kernel: blk_update_request: critical medium error, dev sdi, sector 10992621088 op 0x0:(READ) flags 0x4000 phys_seg 128 prio class 0 Jun 5 02:33:34 Tower kernel: md: disk1 read error, sector=10992621024 Jun 5 02:33:34 Tower kernel: md: disk1 read error, sector=10992621032 Jun 5 02:33:34 Tower kernel: md: disk1 read error, sector=10992621040 which looks like it may be a genuine disk issue so you should consider running an extended SMART test on it as a check. There are also a lot of FCP warnings that it might be a good idea to consider tidying up.

I could not spot anything obvious in the diagnostics that would explain why disk5 is hardly used (it DOES seem to have a few files). Have you by any chance relatively recently added disk5 and disk6? If so that might explain it as with the default Highwater utilisation method set disk5 would not start being used until the free space on all drives (including disk6) fell below 4GB. I also note that you seem to have the Nerdpack plugin installed which is incompatible with the version of Unraid you are running. Not sure what problems (if any) that may be causing.

The diagnostics you have posted are after a reboot. The Unraid logs are by default only in RAM and do not survive a reboot. You may get something useful we can look at if you enable the syslog server to get logs that survive a reboot. You should also check how long it takes to stop the the array. It is possible that something is either stopping this from happening or it is taking too long so that a timeout ends up closing the array forcibly. If you reboot after a successful stop of the array then you should not get an unclean shutdown detected as long as Unraid was able to update the flash drive with the fact the array was successfully stopped.

If you want this then you need a multi-device pool set up for redundancy. The default for a multi-device pool if using BTRFS is RAID1. There are plugins available to back up docker container data and VMs to the array at specified intervals.

Files on the cache are outside the array and thus not protected by parity which only protects the drives in the main array.

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

This is covered in extensive detail in the release notes. The same functionality is available, but the GUI presents how to achieve it using new terminology that is thought to be less confusing for new users and also in preparation for future changes.

Why do you think everything should be on cache? With the settings you show new files should go to the cache until mover runs, but older files will have been moved to the array.

I have never turned the services off.