trurl

Linux sees all user shares as being mounted at /mnt/user. So when you try to move from one user share to another, Linux will see they are on the same mount, and instead of copying from source to destination and then deleting from source, as it would if you were moving between disks, it will instead just rename to a different path. This is instantaneous but it stays on the same disk, not the result you wanted. You will have to do the move in 2 steps. Copy from source to destination. That will make another copy that follows the user share settings of the destination. Then delete it from the source.

First link in docker FAQ: https://forums.unraid.net/topic/57181-real-docker-faq/#comment-564345

If you don't report it you may be SOL

You should click on the Container Size button on the Dockers page. It will let you see how much space each of your containers is using.

You can easily reinstall any docker without setting anything up simply by using the Previous Apps feature on the Apps page.

You probably have some issue with your app configuration and increasing it to 50G is only going to make it take longer to fill. It is very unlikely 20G would not be sufficient if you have things configured correctlly.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post.

Do you really mean Unmenu? Or are you actually talking about the Unraid webUI? Unmenu was an addon from before Unraid V6. I don't think it is being maintained anymore. Not at all clear what you are talking about. Maybe a screenshot would help.

isn't I have some sympathy with the "i don't like monochrome" camp as well as the "i don't like dark" camp. But I also think it will help keep things clearer for support purposes if we don't get too carried away with "skinning".

Since we have made you aware of sigs now why don't you fix it or delete it?

That's about it. You can skip step 8 😄 You can skip steps 2,3,4 if you don't write any new data to your server while doing this. In fact, it's probably simpler if you don't exclude any disks globally then there won't be any confusion if you rearrange things. And the unBALANCE plugin might be an easier way to accomplish step 5. I haven't looked at that video but I know some configurations of Krusader won't let you work directly with the disks, which is what you need to do here. You should never work with user shares and disks at the same time or you could lose data. As for step 10 and your last question, yes you can rearrange the DATA disks. The main thing you MUST NOT do is assign a data disk to the parity slot since it would be overwritten. Some people are afraid New Config wipes out everything they have done. The only thing it will do is allow you to change your disk assignments, and it won't even write anything except (optionally) parity. And you do have to rebuild parity when removing disks. Just in case, if it offers to format anything at any point, DON'T.

The plugin installs a custom build of Unraid. See Step 2 of the instructions in the 3rd post.

There are 3 settings for a User Share that Unraid considers when deciding which disk to write: Split Level, Minimum Free, and Allocation Method. Split Level has the highest precedence. When choosing a disk to write, if Split Level says the file should go on the same disk other files are already on then that is the disk that will be chosen. If a disk has less than Minimum Free remaining, then Unraid will choose a different disk (except Split Level has precedence). High-water Allocation is a good compromise between using all (included) disks without constantly switching disks simply because one disk temporarily has more free space than another. It is a little complicated to explain but fortunately there are already explanations in the wiki: https://wiki.unraid.net/Un-Official_UnRAID_Manual#High_Water

Writes to the parity array will be slower than the normal write speed of the disk being written, because parity must be updated at the same time. This actually involves reading the data and parity disk, calculating the parity change the new data will cause, and writing the data and parity disk. This is how it works whether you are working directly with a data disk, or whether you are working with a user share. But you actually bypass some features of Unraid if you work directly with the disks. User Shares can span disks. This allows you to have a folder with some of its files on one disk, and other files on another disk. And User Shares can be cached. This allows new files to be written to cache and later moved to the parity array. The speed of writing to cache isn't impacted by the parity update, and people often use SSDs as cache so caching user shares can be a way to write faster. Is there something specific you want to do with Krusader? It isn't going to help with the speed problems since they are just the way parity works. I always just use Midnight Commander since it is built-in and I have been using it in Unraid since long before dockers were introduced. There is another method of doing parity writes that is somewhat faster. This thread explains the 2 different methods of writing parity:

Just in case there is still any doubt, that theory of yours is completely wrong. As I already explained, an empty disk isn't a clear disk. And even after you format a clear disk, that empty disk isn't clear either. It has an empty filesystem on it.

An empty disk is not a clear disk. The format operation writes an empty filesystem to the disk. This is a very small number of the total bits on the disk. Format doesn't write zeros to the entire disk, nor does it need to. If it did it would take a long time on even a small disk. Even the empty filesystem itself is not zeros. It has the metadata to represent an empty top level folder ready to have files and folders added to it.

Probably goes back long before V5. I'm pretty sure it worked that way on 4.7 when I started. And of course, it is necessary to maintain parity. Unless the disk added to a new data slot is all zeros, parity will not be valid.

It isn't necessary to share disks. If for some reason you want to control which disks get used you can do this with User Share settings. Sharing disks has a number of ways it can get you into trouble, including data loss. I always recommend just working with User Shares, at least until you get a good idea of how User Shares actually work "under the hood" so you will know how to avoid the problems if you ever decide you do need to access the disks directly for some reason. I never put the disks on the network and I know how this stuff all works. I always just work with the disks directly on the server if the need arises.

I've run out of ideas. I will tag @bonienl to see if he has any. Probably he reads the thread but hasn't posted to it in a very long time.

Looks like you are running the NVidia plugin. This installs a custom version of Unraid. Probably not causing this issue though. Have you tried another browser?

Is there some reason you are still using 6.6.4? I notice that version has been pulled from the Download page.

Do you have multiple browsers (including additional tabs or any mobile device) open to the Unraid webUI?

What I really wanted to see was the Compute All of your User Shares. Why are you even sharing disks?

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post.

You should post your diagnostics so we can take a look and make sure there isn't an issue with your flash drive preventing your settings from being saved.