itimpi

A rebuild will not clear an ‘unmountable state - the rebuilt disk would also be unmountable. Handling of unmountable disks is covered here in the online documentation accessible via the ‘Manual link at the bottom of the Unraid GUI.

Do the diagnostics correspond to the screenshot as the screenshot does not show any drive missing, but the diagnostics suggest it is not online. Since the diagnostics show parity and disks 4 and 5 are also offline I would suspect the disks are fine but that there is a problem with something common to those 4 drives such as SATA or Power cabling. I would suggest powering down; checking all cabling; reboot; start the array; and post new diagnostics. That might give a better clue on how to advise you to continue.

Since having a cache drive dramatically improves the performance of VMs and docker containers there is probably an implicit assumption that anyone making use of them if likely to have a cache drive. There is also the fact that accessing a folder on the cache/pool by referencing the drive seems to be slightly more performant than doing it indirectly via a User Share.

That implies that the code is not being reached in the first place.

Files/folders only get put into lost+found if the repair process cannot find the directory information to put them into the correct folder with the correct name. On that basis that 320GB should not exist elsewhere on the drive although that is a very large amount to have lost the directory information. In most cases it is easiest to 'nuke' the lost+found folder and restore any missing files from your backups as going through the lost+found folder is a very laborious manual process to try and identify what the files there were originally called. That does rely on you having adequate backups, and without them if the data was important you may have no other choice. When restoring from backups you can use options so that only files that are missing are copied from the backup. If you DO decide to process the lost+found folder the Linux 'file' command can at least tell you what type of content (and thus likely file extension) the file originally had).

Yes /mnt/user is an amalgamated view of all top level folders on all physical drives under /mnt including any pools In this case you have 'fooled' the system into thinking that there is a cache device. You need to be aware of this that as any time you decide to operate in Unraid at the physical drive level y/u will find that files/folders show up at both the drive level and the User Share level - they are simply two views of the same folders/files.

You can put them on separate lines so they get executed in order (as long as they are all before the ;; that terminates the case. The syslog is accessible via the 'Log' icon at the top right of the Unraid GUI. You can bring it up before pressing the power button and thus see the entries appearing if they are being executed

A lost+found folder gets created as a place for the repair to put any files it cannot find directory entries for to give their correct name. Since all top level folders on any drive are treated as a User Share you got a share with this name appearing (with default settings). If you are happy to lose the 320GB that was put there by the repair process then you can simply delete it and remove the share. Quite why it got created in the first place is not clear if all the steps appeared error free (including the repair) as you state. Just for interest what file system type is on the drive in question.

If ANY mapping refers to /mnt/cache then this will get created when the container is started thus causing this to get created in RAM which will have undesirable side-effect of fooling the system into thinking it has a cache drive and san start putting files there (and these do not survive a reboot)

Have you tried adding a ‘logger’ command in front of the ‘docker run’ one, and another one after so you get entries into the syslog? That would at least confirm that point is being reached and the command tried. Not sure if you should also redirect any output from the docker run command anywhere to see if is failing for some reason

if you have made no configuration change and spontaneously start getting reboots this strongly suggests something at the hardware level is starting to fail. The PSU in general the PSU is something that can degrade over time so when you suddenly start getting reboots it is an obvious suspect, and hopefully is something that can relatively easily be checked out. if it is some other component (e.g motherboard, RAM) that is starting to fail this is much more difficult to diagnose.

Having a user share setting of Use Cache=Prefer is perfectly OK without a cache drive as the system then just reverts to using the array. If you later add a cache pool it can then switch to using it for that share. I suspect that your problem is caused by one or more of your docker containers having a mapping that refers to /mnt/cache (when it should refer to /mnt/user) and this is creating the location /mnt/cache (in RAM) which the system then subsequently treats as though the cache drive WAS present so starts writing to it. This means that the contents of /mnt/cache do not survive a reboot, and also start filling up RAM until the system runs out and stops working correctly. Makes me think that the Docker Manager should have a check that will not let you set up a mapping directly under /mnt that does not refer to a physical drive to stop users being able make configurion mistakes of this sort.

I have just checked and I could pass my iPad through to iTunes in a Windows VM. I was hosting the VM on an Unraid 6.9.2 system. I could do it in the VM definition but that is not ideal as then the VM would not start if the iPad was not connected. What worked far better was to not have it in the VM definition, but instead to use the libvirt Hotplug plugin to assign it dynamically to the VM after I had the VM running.

If you have not bound the card to VFIO then Have you installed the NVIDIA plugin to enable drivers for it?

Not quite sure what you are asking for here? I pass USB devices through to VMs (for instance an Unraid USB flash drive to run a development UnRaid environment). There are also plugins for dynamically assigning USB devices to a VM. You can also pass through a complete USB controller for the VM guest OS to manage plugged in USB drives.

The problem is that if you have set the cards to be passed through to a VM then you have probably hidden them from Unraid?

I think that to get GUI mode you will need the NVidia plugin loaded and activated to have drivers for your card. Having said that I am not certain that the card you have is supported by the plugin.

I think WireGuard will be the best secure option for maximum flexibility. However I think it (and OpenVPN and My Servers) will all require you to be able to open up an incoming port on the router which you say is not a possibility? Not sure of other solutions that will not require this.

A bit confused by this as any disabled disk would not take part in a parity check. Maybe you meant something else? The amount of data on a disk is irrelevant to a parity check as its is working at the raw sector level. Even a disk that has no data will have a lot of non-zero sectors due to the fact that the disk was formatted to create the control structures for an empty file system.

I must admit I have never tried it, but I would think there is a high likelihood that doing so will abort the update process. Unless someone else can weigh in on this I think you are wise to remain cautious

What are you doing at the RPi end to define the UnRaid SMB share? I have Unraid shares defines in the ‘etc/fstab’ file on my RPi and they seem to mount OK.

It might be worth downloading the zip file for the release, and then extract all the bz* type files overwriting those on the flash drive just in case the power outage somehow caused some corruption to occur. It should not be needed as you said you got a tidy shutdown, but you never know.

Not really your fault I think it is a bug introduced in the 6.10 rc1 release where that setting is disabled by default rather than enabled by default, and is going to be corrected for rc2.

Have you enabled user shares under Settings->Global Share Settings?

In principle the format operation would have updated parity but as mentioned it would not do any harm to run a check to make sure it is valid.