itimpi

I have spotted one anomaly in your diagnostics that might explain your symptoms! You have a share called 'Serien' which is set to a split level of 1 which means that any sub-folder on that share is constrained to the disk on which it is first created. This will apply regardless of allocation method so is that the behaviour you want?

As far as I know there should be no changes to the permissions required for dockers except perhaps in the special case of those that want to directly access the flash drive. I have certainly not seen any of mine starting to have permission issues.

How are you copying the files? If you are not doing over the network then you may be by-passing the user share system. the diagnostics look like they were taken after a reboot - not while a copy was actually in progress - is this the case?

In case it helps, if you want to edit the xml then this is now done by selecting the Edit option and then switching the resulting screen to xml mode using the toggle at the top right.

This sounds like a side-effect of the fact that in the 6.8.0 rc series the permissions on the flash drive are far more restrictive (as described in the release notes), and I expect this is being reflected in the backup copies of the flash drive. it might make sense for the plugin to be altered so that the copy of the flash drive is explicitly set to have less restrictive permissions?

If you do not have a cache drive then /mnt/cache will be in RAM and thus will not survive a reboot (assuming you do not first get problems with running out of RAM).. You probably want the path to be /mnt/user based to have it compatible with not having a cache drive. If the appdata share is also set to Use cache=Prefer (which is the default for the appdata share) then the docker will be using the cache if you have one (or later add one), but will use the array otherwise).

The security changes should only affect containers that want to access files on the flash drive and I would not have thought there should be many where this is likely to be the case?

Were all 4 drives always there? Which drive are new files going to? At this point from the screen shot I would expect them to be going to disk4.

Chances are that you just need to rewrite all the bz* type files on the USB stick. You can do this by downloading the zip file for a release (including rc4) and extracting the bz* files. There should also be the files from the previous release in the ‘previous’ folder that can be copied to the root of the flash drive.

That picture does not show enough information to draw any conclusions. One thing you have to remember is that the ‘Split Level’ setting on shares over-rides Allocation method when selecting a disk for a new file so the path to files can be relevant if you have any restrictions imposed by Split Level.

One difficulty in the implementation is that the Shares tab is completely disabled until the array is started. I am not sure how much work it would take to change that as the flash share would need to be visible even with the array stopped.

Yes pre-clear is a good way of checking drive health as well as zeroing them. The pre-clear takes longer than a clear as it also does read checks that the zero writes were successful whereas the simpler ‘clear’ only does the write of zeroes assuming they are oK if the drive reported no error. Pre-clear can also be done without any effect on the array while it is running so can often be more convenient.

A disk has to be all zeroes when added to a parity protected array to avoid invalidating parity (an ‘empty’ disk is not normally all zeroes). Pre-clear is a way of doing this before attempting to add the drive and then the drive is available for formatting immediately. If not pre-cleared then Unraid will carry out the required ‘clear’ operation when you add the drive and it cannot be formatted ready for use in the array until that completes.

Was the disk pre-cleared? If not then the 4 hours was probably Unraid doing a ‘Clear’ operation (writing zeroes to all of the disk). The format operation should only take minutes. maybe there is a bug when you ask for format while a Clear operation is in progress? If you have not rebooted perhaps you can post the system diagnostics zip file (obtained via Tools >> Diagnostics) so we can see what was going on?

No. It is only by clicking on the Boot device that you can currently change its visibility and security. There was a feature request some time ago for it to be visible on the Shares tab and I thought that made it more ‘discoverable’ to new users but so far it has not been accepted/acted on.

There is no delete checkbox for the flash which is why there was confusion over how this might be achieved. your screenshot shows that you have set the SMB export setting to ‘no’ which means it is not shared as ‘flash’ and thus accessible over the network. To be able to access it over the network it needs to be set to one of the Yes variants. You may also want to make sure you have set up the security options to suit your planned needs.

Adding the SSD to the array is likely to be a waste as write performance will be severely limited by the need to also write to the parity HDD for all write operations. if you want resilience add it to the cache or else use it as an Unassigned Device.

The primary vdisk location needs to be the full path (including filename) to the vdisk to be used. If you get that wrong then you the location will not exist on physical media so you will end up using RAM instead.

The array is usable while a rebuild is going on and any downloads should be reflected in the rebuilt disk if that was where they were sent. Parity (including the emulated drive) is always updated in real time. The thing to remember is that any array access is contending for access to the drives with the rebuild process (which is using all array drives) so can have performance impacts. A problem could occur if for any reason things went wrong during the rebuild and you were writing to the array and you lost more drives than you have parity drives. In such a case it would not be possible to recover without (potentially) losing some of the recent data written to the array. You need to determine for yourself if this is an acceptable risk.

This is normal in this scenario as you have been swapping drivesaround. The file system repair has run against the emulated drive as the real drive7 was disabled at this point (I think) or was already needing a rebuild If you had run the file system repair when the drive is not being emulated then a rebuild would not have been necessary.

Do you have any idea of what NIC types are supported by the VM?

No - the purpose of the plugin is to allow you to access drives that are NOT part of the array on an Unraid system. It can be used to facilitate copying data off ZFS formatted drives to an Unraid array.

BTW: You are much better off posting the system diagnostics (obtained via Tools >> Diagnostics) as that contains much more information than just the SMART report. With that it is easier to draw a conclusion as to why the drive got disabled.

Not quite. I am saying that anything written to the start of the drive such as mounted status would be corrected quickly. Data files that are likely to be much further into the drive would not be covered.

I think they are effectively the same thing! It is just the image variant has binary data so cannot be entered manually. In both cases the content of the file is used as the key.