itimpi

The way to get a disabled disk back online is to rebuild it. Does the emulated drive contents look OK as this is what would end up on the disk after a rebuild as the rebuild process simply makes the physical drive match the emulated one. No real reason to move the files off the drive before doing a rebuild. if you provide the system’s diagnostics zip file this might give a clue as to why unbalance is running slow (and also show if there is any other potential problem).

Make sure you have a copy of the licence file for the flash drive and then prepare it as if doing a new install and after that put the licence file back into the config folder. When assigning you drives Unraid will recognise they were previously used by Unraid and thus will not try to format them. Assuming you want to format them then (with the array stopped) change the file system type and restart the array and you will now be given the option to format them. You can repeat this to get back to the original file system type if that is what you want.

You may find this section of the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI to be of interest.

You have the share Project with a Use Cache setting of "prefer" which means you want it on the cache if space allows. The space available is calculated from all the drives that contain part of that share at the moment so if it is all on the cache it makes sense for it to be 1TB. If the share overflows so the array then the available space will include the array drive(s) BTW: If that is not where you expect the files for this share to be located then it is worth pointing out that there is a good summary of how the Use Cache setting works included in the GUI help and an even more detailed explanation in the online documentation that can be accessed via the Manual link at the bottom of the Unraid GUI.

What type of WireGuard configuration have you selected? This can affect the address you need to use when trying to access shares remotely.

Not looked at the diagnostics - but one of the xfs_repair commands you give are incorrect. When done via the command line the it has to /dev/sdb1 (I.e. include the partition number if using ‘sd’ type devices. You do not need the partition when using ‘md’ type devices.

The issue starts when a file is ‘moved’ to anther share at the Linux level (rather than copy/deleted) either via the command line or via a container. Linux (which does not understand User Shares) implements ‘move’ by first trying a rename and only if that fails doing a copy+delete if source and target appear to be on the same mount point (/mnt/user in the case of user shares). The rename succeeds leaving the file on the original drive so the copy/delete never gets triggered. Doing an explicit copy+delete gives the desired result, or (in the case of containers) map the paths so they appear to be different mount points. 2) as it is not part of standard UnRaid. It should be possible to get the script to handle this correctly by making it get the list of pool names from /boot/config/pools on the flash drive. Having said that there are valid Use cases for keeping files for non-cached shares on a cache/pool (and I know of Users who exploit this behaviour) so this script would break those Use Cases unless it is explicitly written to allow for them.

Did you make sure that the correct pool was referenced when you change the setting to Yes? There have been reports of files ending up on a pool not named in the share setting - they will not get moved.

An easier way to fix permission issues is to use Tools->New Permissions tool.

Mover ignores files for a share that has use Cache=No. If you want them moved to the array then you need to change Use Cache to Yes (at least temporarily). Note that the Use Cache setting primarily determines where NEW files are placed - it does not stop old files from being left on the cache (conversely the Only setting does not automatically move files from array to cache). Mover only gets involved for the Yes and Prefer settings.

The only acceptable number of errors in memtest is zero.

I think the normal approach is to put the master files somewhere persistent and then have a script to copy files into position for testing. I personally use Dropbox as that means I can edit on my Windows system with the files automatically synced to the UnRaid server and then I have a terminal session active on Unraid to copy files to their runtime position. I think others do something similar simply keeping the master files on the flash drive.

that looks correct for the High water allocation method. You should read up on it and if you still do not understand what is happening come back here.

That looks as if it has managed to repair any corruption without any data loss.

This is normally done by having 2 different buttons and using JavaScript to show/hide the one that is not relevant.

It might help if you gave us a clue which share is not behaving as you expect?

Do you have a Docker container (or something similar) downloading files to the extra cache drive? If so it may be by-passing the user Share system.

We’re you passing any hardware through to the VM? If so then did you remember to remove at vfio mapping as device ID’s are almost certain to change when changing motherboard? can you log in at the console? If so do it and use the ‘df’ command to see if you can see something mounted at /boot (should be your flash drive). If so try the ‘diagnostics’ command and the resulting zip file will get put into the ‘logs’ folder on the flash drive.

You were lucky in that if is disk is disabled then Unraid stops writing to the physical drive. Hopefully the disabled drive had not completely failed and if that is the case then as suggested going the New Config route will result in UnRaid treating it as though it is good and will try to mount it. If this turns out not to be the case then come back detailing exactly what happens when you try this. Whatever you do, do NOT try to format a drive. BTW: there was no need to do what you tried to wipe the parity disk. The parity disk contains no file system, and the sectors on it are meaningless unless one has access to the ‘good’ disks in the array so no chance of anyone working out your data.

It is not at all unusual for a drive to pass the short test and fail the long one so if possible do that as well.

The ‘root’ user is purely for admin purposes and cannot be used as the username for accessing shares. if you want a private share then you are going to need to sort out the Windows side. It is critical that the first access to a share on the server after booting Windows is done using the username/password you set up for private access as a quirk of Windows is that it will not allow two sets of credentials (e.g. guest plus private user) to be used to the same server - and it gives misleading error messages about the username/password being invalid if you try.

Your syslog in the diagnostics is full of resets on disk1 which makes it difficult to look for any other errors. This is probably a power and/or SATA cabling issue. Could also be worth running an extended SMART test on that drive as a check on its health.

UnRaid security works at the user level so set the security for the share to ‘Private’ and then you can control which users have access to it and what type of access. Does this not meet your needs?

You can always install the Config File Editor plugin which makes editing any file of this type very easy without any need to go to the command line.

The parity check tuning plugin never does nothing that can directly cause the system to become unresponsive, although it could be that a running parity check can cause this. The plugin periodically runs a monitor task to see if there is currently a parity check in progress so it is not abnormal to see entries in the syslog relating to this. Having said that I see that the version of the plugin you have installed is a few release out-of-date.