trurl

You have to set Minimum Free for the user share to get a cache-yes user share to overflow to the array, otherwise it just fills up and fails. You should set Minimum Free to larger than the largest file you expect to write to the share. Unraid has no way to know how large a file will become when it chooses a disk for it. If a disk has less than Minimum, it will choose another.

Something not working about your network obviously. Have you tried rebooting server, router, switches?

You still have no /mnt/user0 which would be expected if cache were participating in user shares. Try editing config/shares.cfg on flash drive. Change this shareCacheEnabled="no" to this shareCacheEnabled="yes" You might be able to make this edit from command line or in mc with the server still running and then just stop and start the array to get it to take effect.

appdata, domains, system share will typically be cache-prefer so docker/VMs will not have performance impacted by parity, and so they won't keep disks spinning. Have you tried setting up dockers or VMs yet?

Instead of syslog, we much prefer the complete Diagnostics zip, which includes syslog, SMART for all attached disks, and a lot more information about your hardware and configuration. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

I don't see it on yours either. Not sure how yours got set to no or how to change it to yes except maybe editing the file on flash and rebooting.

Cache-Prefer means try to keep the files on cache. Cache-Yes means move them to the array.

Looks like dual ethernet ports. Are you using both? Have you tried each alone?

Lots of this in syslog: Sep 12 12:41:37 unraid kernel: traps: node[18277] trap invalid opcode ip:561baad9070f sp:7fff2093b428 error:0 in node[561baad8c000+77b000] Sep 12 12:41:39 unraid kernel: traps: node[18343] trap invalid opcode ip:555bf6e6370f sp:7ffdf4287d78 error:0 in node[555bf6e5f000+77b000] Sep 12 12:41:40 unraid kernel: traps: node[18368] trap invalid opcode ip:559dd34a670f sp:7ffcb4b7c288 error:0 in node[559dd34a2000+77b000] Sep 12 12:41:43 unraid kernel: traps: node[18431] trap invalid opcode ip:55c31874e70f sp:7ffd845efdf8 error:0 in node[55c31874a000+77b000] Have you done memtest lately?

What is the exact model of your motherboard?

In those, config/shares.cfg has shareCacheEnabled="no" That doesn't seem to be the usual setting in other diagnostics I have looked at. I don't see where to change that in the beta I'm running but that may just be a bug due to the introduction of multiple pools. Maybe we can find it in your version. Go to Main - Array Operation and Stop the array. Then get 2 screenshots from Settings and post them, Disk Settings and Global Share Settings.

Parity is updated realtime. Any time a disk in the parity array is written, parity is calculated and updated. There are 2 different methods for updating parity and these have tradeoffs, but both are slower than writing without parity. See here for more details:

Unmountable, possibly unrelated to the beta. Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Go to Tools - Diagnostics and attach the complete Diagnostics ZIP file to your NEXT post in this thread.

Do you mean the source and destination are both in the Container user share?

Still not clear from your screenshot if you are accessing disks, or accessing user shares with that copy. Did you turn off disk sharing as I suggested?

It still seems like you have some confusion on how user shares have always worked though. If you are sharing disks on the network, then you will see a file in the user shares, and you will also see the file on whichever of the shared disks the file actually exists on. And cache is a disk just like the array disks, and cache can be shared. Go to Global Share Settings and turn off disk shares. Then you won't see any of the disks on the network. And when you write to a cached user share, it will go to cache and later moved to the array if the share is cache-yes.

If you copy a file over then network to a shared disk, it always goes directly to that disk. Cache is not involved when you are working directly with the array disks. It is also possible to work directly with the cache disk. All this is exactly as it was even before V5.

There is no cache setting for disk shares, only for user shares. And there really isn't any concept named "Disk Array Share". When speaking about disks shared on the network, it makes sense to talk about "Disk Shares". But as mentioned I recommend not sharing disks on the network. When speaking about disks on the server, then there isn't any reason to talk about disk shares because sharing isn't in play. When speaking about user shares, that concept is relevant whether looking at it on the network or on the server, because user shares on the server are the aggregated view of the top level folders on all array disks and cache. On the server they are in /mnt/user. Again, all this is exactly as it has been since before V5.

You seem to be confusing "disk shares" with "user shares". If you copy directly to a disk, it goes directly to that disk. If you copy to a user share, it goes to cache if the user share is cache-yes, cache-prefer, or cache-only. Then later mover will move any cache-yes from cache to array. I recommend not sharing disks on the network, and only working with user shares. It is possible to get yourself in trouble by sharing disks, including data loss. All this is exactly as it was before V6.

The user shares are simply the aggregate of top level folders on cache and array. The top level folders have the same names as the user shares. Cache has always been part of user shares. If a file is in /mnt/cache/share1, then it is also seen in /mnt/user/share1, and it is in the share1 user share. If the share1 user share is set to cache-yes, then any files in /mnt/cache/share1 will be moved to the array disks according to the settings for the share1 user share. This is how it has always worked, even before V5, and this is how it still works in V6. The only new thing is the cache-prefer setting, which tells mover to move files TO cache.

Your logs have a lot of mover stuff in them, maybe you will want to disable that eventually. But I noticed it is moving vdisks. You probably don't want that. domains share should be cache-only or prefer for best performance, or cache-no if you don't care about that and don't care that your array disks stay spunup. Same for appdata and system shares. appdata, domains, system shares are cache-prefer by default but you have changed them. You want these on cache and configured to stay on cache so they won't be impacted by slower parity and so they won't keep disks spinning. Also your docker.img is 150G. Have you had problems filling it? 20G should be more than enough and making it larger won't fix anything. I have 17 dockers and they are taking less than half of 20G. Having said all that, that is all just general advice. I don't actually run any Windows VMs.

Been a while since I used V5, but I think the only difference with the Use cache setting is the addition of Prefer. No, Yes, and Only work just as before. Mover runs as scheduled or you can run it manually. Anything on cache for a user share is part of the user share just as it has always been. This is exactly how it works in V6 just as in V5. Why do you think it isn't working?

Yes, I think diagnostics might at least clear up some things that aren't being communicated well.