itimpi

I would also be a bit concerned about what are the chance of a ‘false positive’ if in fact the corruption occurred on a parity drive and not on a data drive. Could you be sure that whatever algorithm is used can detect this scenario and always be able to tell it apart from the case where the corrupt bits were on a data drive. Taking action on a ‘false positive’ could result in perfectly good data then getting corrupted as a result.

What version of Unraid are you using? If you have a 2.5GB capable NiC then it almost certain that you will need to use the 6.9.0 beta release to have drivers for it loaded.

I think the problem is that with SATA drives Unraid does not need to take any explicit action to spin up the drives (which is why there are no log entries) as it happens automatically as soon as any attempt is made to access the drive. It appears that with SAS drives explicit command need to be used to spin up the drives before attempting to access them or you get an error, and at the moment Unraid has no logic of this type in place.

The answer originally given was correct. Until Unraid gets around to having at least 1 file belonging to the share on a drive the drive is not counted towards the available space when querying across the network. In practice the first file (or folder) tends to get created almost immediately so users do not notice this behavior.

I expect you are hitting limitations imposed by the extra overhead of going through the User Share access level code.

Limetech are normally good about responding within days so it is always possible the reply got caught in a spam trap or something similar.

Limetech is the Unraid owner/original developer and as such can be considered an author active source. it is also worth noting that Limetech employees only sporadically visit the forum so you should never assume they will see any particular post.

The original mover was just a shell script that ran on top of the User Share sub-system. It is now more sophisticated than that I believe, so maybe at some future time it will be improved to take into account available space on a drive when it runs.

There is a lot of discussion (including by Limetech) earlier in this thread about the problems of adding FusionIO support. It sounds as if it is likely to be quite a bit more work than simply adding drivers (assuming they even compile on the latest kernel - many 3rd party drivers do not).

Yes, you can manage files manually. if Unraid disables a disk then this means that a write to it failed for some reason, so you probably need to pin down the cause. It might just be a cabling issue, but it could be something else.

Did you follow the instructions in the Release Notes on how to wipe the current contents and then repartion/format to the new alignment?

In many cases the new alignment offers better performance. This is probably because it is the same alignment Windows uses so it is what the manufacturers are tuning the drive for.

You can toggle the buitlin help on/off at the screen level using the ‘?’ Icon at the upper right of the Unraid GUI. It can also be done at the field level by clicking on the text of the field name.

You can do this yourself by editing the first post in the thread and changing its title to add ‘(SOLVED)’.

You might find this part of the online documentation useful in explaining why you do not get raw disk speeds when writing to the parity protected array and how the ‘turbo’ write mode can speed things up.

I do not think it is is mover that selects the target drive but lower level code within in Unraid that is applied at the time the ‘file create’ call is issued, and at that level the system does not know the size of the file. That is why there is a recommendation that the Minimum Free Space value is set to be as large (or larger) as the biggest file you expect to copy so that the copy will complete without running out of space.

If you reformatted the USB drive did you remember to run the step to make it bootable?

I have far more Dockers than fit on the screen and they scroll OK for me on my iPad. i think the root cause has to be some sort of bug at the web kit level which can therefore affect all iOS/iPadOS browsers as Apple mandates they have to use WebKit for rendering. I would be interested to know if anyone using Safari on MacOS ever experience such problems.

Just to ask the obvious question have you partitioned/formatted the drive? If you have the the UD log might give a clue as to why it is failing.

Not as far as I know (I would like to be proved wrong )

Using br0 is what you want to be using for your requirements. You probably want to check from inside the VM that you have an IP address allocated by your router AND that a valid DNS address is set up. This is expected. When using VNC you are accessing the VM via VNC server running at the Unraid level and thus using the Unraid server's address. Access to the internet via virbr0 is expected as virbr0 allows outgoing connections (and blocks incoming ones). This is expected as when using virbr0 the VM is not visible on the local LAN. You need to get br0 working to be able to do this as br0 allows incoming connections.

You need to make sure that you use one of the ‘slave’ access modes. Without this you will only see changes when the Docker container is restarted.

Your best bet might be to look at the contents of the rogue folder to work out where it might have come from.

You will never see shares listed which have the same name but different capitalisation as this is incompatible with SMB. The best thing at this point to do is to rename the Media folder on disk3 to something else so that it has a different name (and thus shows up as a different share) which will allow you to check its contents (if any). if you do not know why this happened in the first place then it is likely to happen again.

There has to be something configured to create a folder with the same spelling but different capitalisation. once you get into that scenario and folders with both spelling exist on your array, then since SMB shares are case independent but Linux is case dependant only one of the two variants will end up being visible over the network. Which one it is is difficult to predict. The only fix is to go in at the disk level to sort this out by renaming the folders on the drives to identical spelling (including case).