trurl

Another possibility would be to not use cache in these situations.

I am not really going to argue this point one way or the other. This behavior is understandably surprising to the user, and same goes for the User Share Copy Bug. But both of these problems have very low level origins in Linux that may not get addressed soon if ever. There is a feature request to get a builtin file manager for the webUI. I don't expect much to happen on that front either, but I chimed in on that thread and mentioned these 2 surprises as something that might be considered if such were ever to be developed. Just keep them in mind and work around them. Most people never complain about them. Probably a lot of people never do anything that would make them happen. Probably some that don't complain just aren't aware that it is happening.

Normally we say you must set Minimum Free to larger than the largest file you expect to write. Unraid has no way to know how large a file will become when it chooses a disk to begin writing it to. If a disk has less than Minimum, it will choose another disk. In the case of torrents, where you may begin writing lots of files simultaneously, that idea probably needs to be amended. Set Minimum Free to larger than the total of those files. You will probably have to figure that out on your own depending on your torrents.

You still have some of appdata on disk1 as you can see in that last screenshot. Are you sure that share is set to cache-prefer?

Same thing happened to me. Not sure how either.

This was done with Midnight Commander:

I just tested this over the network and when I move a file from a cache-only share to a cache-no share, it does a copy from source to destination then delete from source, with the file ending up on the correct disk according to the user share settings. Which is what you would expect since the client machine expects these are different places and it wouldn't be possible to just "rename".

Not a particularly pertinent comment from me, but this would not break parity.

Check in the Settings for System Temp that you still have a sensor assigned to the motherboard temp.

This is in some ways similar to the so-called User Share Copy Bug. It is a side effect of the fact that Linux operations don't know the user shares are just different views of the disks. It sees /mnt/user as just another separate mounted device.

I am actually using Goodsync, replaced DeltaCopy since it isn't maintained anymore and it quit sending me emails about my jobs. But I only have it installed on my PC. It does nightly backups (one-way sync) of documents and other personal files to my Unraid server. As for backing up my server, I am currently just doing an rsync script of the important shares to externals for storage offsite. What advantage would there be for me to have GoodSync on my Unraid server? That docker I linked before should work fine on Unraid but I haven't bothered to figure out how to set it up yet since I don't know why I need it.

That looks good. Have you created any dockers yet? It might be best if you show us what you intend to do with that since what you posted above about qbittorent and its config didn't seem right.

What docker is it specifically? Plex for example has always had the ability to use files shared on the network in its media library. Does Nas 1 also need to mount shares on Nas 2? I think that is the main point he was making.

You're missing a * should be */5 * * * * instead of */5 * * * http://corntab.com/?c=*/5_*_*_*_*

Do you mean you actually created a user share named config? That is not the way you typically handle the config mapping of dockers. Post your docker run command as explained in the very first link in the Docker FAQ: https://forums.unraid.net/topic/57181-real-docker-faq/ Also, it doesn't look like you actually did anything at all regarding the recommendations I gave in my previous post. You need to slow down. Fix those things we already told you about. In fact, forget completely about getting any specific docker to work until you fix the way your system is using dockers. That means fixing those things I already mentioned in my previous post.

Not arguing against your points. But you CAN have protection of data in cache. Setup a raid1 cache pool.

Yet another possibility, assuming you are working on the server with the /mnt/... paths. A move from /mnt/user/some-cache-only-share to /mnt/user0/some-cache-no-share appears to do the correct thing, as I would expect. I just tested it in Midnight Commander. /mnt/user is the user shares including cache. /mnt/user0 is the user shares excluding cache. Linux sees /mnt/user and /mnt/user0 as different mounts so doesn't try to rename the path and actually moves the file from cache to array.

Copy from source to destination. That will result in a new file being written at the destination, and that new file will be created according to the settings for that user share. Then delete from the source. That way you get a move that does what you want, copy to destination then delete from source. Instead of a move where Linux is free to decide whether to just rename its path. An alternative would be to make that destination user share cache-yes. Moving from one share to the other would result in the file on cache, but mover would move it to the array at the scheduled time. You would need to be sure to have enough capacity in cache for this.

Maybe flash is going. Does it get hot?

Are you using a USB2 port? People often have trouble with flash in Unraid if it is in a USB3 port.

After looking at your diagnostics, here are some specific recommendations. Set your appdata, domains, and system shares to cache-prefer. Disable the Docker and VM services in Settings, then run mover. This will get those shares moved from the array to cache where they belong. The reason you want these to stay on cache is so your apps and VMs won't be affected by the slower writes of the parity array, and so your apps and VMs won't keep parity and array disks spinning. You can see which disks each user share is using by going to Shares - User Shares and clicking the Compute All button. Wait for the results, and if those shares have all their files on cache then enable Docker and VM services again. You shouldn't be saving anything other than appdata in the appdata share. If you have downloads going there then change that. Typically people will have a downloads share or something like that they download to, and that one can be set to cache-yes so it gets moved from cache to array.

Please in future save us the trouble of having to ask for it yet again. Asking for it is the first thing I usually have to do when looking at any thread. Attach the complete diagnostics zip file to your next post.

Excerpt from this "sticky":

It supports SSDs in the cache pool and probably most use the cache pool instead of UD for dockers.

Looks like it should be possible to get this one going on Unraid: https://hub.docker.com/r/shrmn/gsdock