itimpi

I think you would be OK if you used ‘cp’ or ‘mc’ (midnight commander) from a console session. Not sure about rsync. Another possibility is doing it over the network but then network speed becomes a constraint.

Just thought it was worth mentioning that I am looking into the best way to integrate this plugin's settings and capabilities with the new facility built into the just released 6.10.0-rc3 for running parity checks in increments. The easiest for me (and a short term solution for existing users) is to NOT use the new built-in feature for increments and let this plugin continue to handle running the increments. This will allow all the plugin functionality to run unaffected by the move to rc3 (or later). I will shortly make a release that I have validated runs correctly with rc3 with all the plugin functionality intact it you are taking this approach Longer term I want to retain any functionality this plugin has that goes beyond the built in functionality while avoiding duplicating anything unnecessarily. Before I make any final decisions I am going to have to work out exactly how rc3 handles manual and automatic checks as well as scheduled ones to see if the plugin settings relating to these are still relevant. I also need to see if the new functionality also covers (or interacts with) other operations the plugin handles like rebuilds and clear operations; restarting parity checks after an array restart; temperature related pause/resume; etc. This work is likely to take some time to complete.

Splitting only the top level is what you want for the distribution you say you want. I believe that the problem with your TV shows is that Krusader creates all the folders before it starts copying files into them. Since cresting a folder takes almost no space they all get created on the first drive and then the Splut Level setting constrains the files to that drive. If you copy the files back in smaller increments then you should get the files split across the drives. You would also get it if you used a copy method that does not start by creating all the folders required.

Unraid does not care if there are gaps.

You can use the New Config tool to change the disk assignments to what you want, but you then need to rebuild parity to match the new assignments.

these are the wrong steps What you should at this stage is: Stop array Click on the drive on the Main tab and change the format to be XFS Start the array The drive should now show as unmountable and Unraid should be offering the option to format unmountable drives Make sure it is the only drive showing to be formatted and if so go ahead with the format. The format should only take a minute or so and then the drive is ready for use.

According to your screenshot you have the Torrent_Storage share set to NOT use the cache so Unraid is (quite correctly) writing to the array. If you want it only on the cache it needs to use the Only (or Prefer) setting for Use Cache Pool. Note that if you change this setting it only applies to new files.

Two alternatives that have existed for ages are automated backups via the CA Backup/Restore plugin and manual backups by clicking on the drive on the Main tab and selecting the backup option.

This would invalidate one of the benefits of using preclear when adding new disks in that you only have to stop the array for a minute or so as when you add a precleared disk as Unraid can assume that there is no update required to the parity disks. If Unraid could not assume that the parity beyond the largest drive was guaranteed to be all zeroes assumption would break if the disk was larger than any of the current array disks as then Unraid would have to write new parity information.

This is done because it is also important that all of the parity drive beyond the size of the largest drive is all zeroes so that when you later add a larger data parity is correctly managed without having to write anything new to the parity drive. I guess in theory it could be handled differently when adding larger drives by clearing the additional parity space before adding the larger drive but that would add complication to that process. I think there is probably an assumption made that if you are using parity drives larger than the biggest drive you will soon be adding data drives of a similar size so zeroing that additional space up front keeps it simple.

The only really important part of the backup is the config folder and it’s contents as that contains all your settings. If you have that then you can go through the normal process of creating a new USB (using the manual method if the USB Creator does not work) and then replace the config folder with the one from the backup.

It is not a standard facility in Unraid 😘 Since Unraid reloads 'fresh' every time you boot the system you have to take positive action to make any change to standard settings persist. My suspicion is that you must have had an entry in the config/go file to modify something like the /etc/profile or .bashrc files after Unraid has loaded ?

It might be worth logging in at the console and using the 'df' command to check that it shows a /boot mount point as if that does not show then the problem is the flash drive not being recognized in the later stages of the boot. If that DOES show then using the 'diagnostics' command will get a file written to the /logs folder on the flash drive that you can post here to see if anyone spots an issue.

Yes if you want data drives to be up to 16TB.

Neither parity drive can be smaller than the largest data drive, although they do not have to be the same size.

It is covered in the Getting Started guide (username root)

Maybe this link might be of more use?

That has always been there when a parity check started

First time I have heard of anyone reporting trying to use that feature I can reproduce that error message so will get it fixed. I must have made a code reorganisation internally in the plugin and got something wrong and did not retest the Assistant. The Assistant is independent of the handling of pause/resume of the parity check so that should not be affected.

Just to check the obvious - are the drives formatted and are User Shares enabled (under Settings->Global Share Settings). the automatic shares do not get created until you enable the docker and VM services.

Are you sure the drive really has failed? Often a drive gets disabled (marked with a red ‘x’) because a write failed for some reason but the dtive is OK. We might be able to give a view if you supply your system’s diagnostics and mention which drive it is. Unraid will stop using a file that is disabled so when you remove it is up to you.

Why not (how does it fail)? It is likely that whatever issue you had would not be fixed by a clean install.

Your original post mentioned getting: Mar 6 04:30:05 Unraid root: Fix Common Problems: Error: Invalid folder cache contained within /mnt which was my big concern. If this repeats then it is almost certainly a misconfigured docker container referencing that path. I do not see this repeated recently so you might want to run Fix Common Problems again to see if that path still exists and if it does look at what that path contains to give you a clue as to what creates it.

You are likely to get better informed feedback if you post your systems diagnostics zip file as without those we are just guessing. The messages suggest you have something mapped to /mnt/cache (probably a docker container) and you do not have a pool called 'cache'. This would mean that the /mnt/cache location is in RAM so writing to this that will fill up your RAM.

Looking at your diagnostics I see: Mar 6 10:20:06 Tower kernel: XFS (md1): Corruption detected. Unmount and run xfs_repair followed few seconds later by: Mar 6 10:20:07 Tower kernel: XFS (md1): xfs_do_force_shutdown(0x8) called from line 955 of file fs/xfs/xfs_trans.c. Return address = 000000004ccdb74b Mar 6 10:20:07 Tower kernel: XFS (md1): Corruption of in-memory data detected. Shutting down filesystem Mar 6 10:20:07 Tower kernel: XFS (md1): Please unmount the filesystem and rectify the problem(s) Mar 6 10:20:07 Tower move: move: create_parent: /mnt/cache/downloads/sab-incomplete/Mr.Robot.S04E04.404.Not.Found.1080p.BluRay.REMUX.AVC.DTS-HD.MA.5.1-EPSiLON/__ADMIN__ error: Structure needs cleaning Mar 6 10:20:07 Tower root: Cannot stat file /proc/9617/fd/34: Input/output error and from then onwards continual Input/output error messages. This suggests to me that you may have RAM issues. I would recommend running memtest from the Unraid boot menu. I would also suggest running a File System Check/Repair on all your array drives.