trurl

I hope nobody would set such a thing loose in the world.

Shouldn't invalidate parity if you remove a partially cleared disk. Parity will be unaffected by the clearing disk contents until it is finished clearing (the whole point of clearing) and gets formatted. Don't know if New Config would be required to remove it or not.

Looks like you should have enough capacity on array and cache to move things where they belong. You will have to stop the docker service so none of your dockers are running. Mover can't move open files. Then set your appdata to cache-prefer to get it moved from array to cache. Looks like total amount that would get moved from array to cache is less than 20G and you have a lot more than that free. The downloads share would move only 15.5G from cache to array and you have more free space than that on the array, so that should be OK too. So: Settings - Docker - Disable. Shares - User Shares - set appdata share to Use cache: prefer Main - Array Operation - Move Now. Wait for it to complete. Then post a new diagnostic. You need to consider your Minimum Free for each of your user shares and for the cache drive. When Unraid begins to write a file, it doesn't know how large the file will become. Once it has chosen a disk to write it won't change its mind or try to move it to another disk if it runs out of space. It will just fail. Minimum Free is how you get it to choose a different disk before it begins to write. Any disk that doesn't have more than Minimum Free on it will not be chosen. Each user share has a Minimum Free setting. It should be set to larger than the largest file you expect to write to the share. Cache Minimum Free setting is in Global Share Settings and works similarly. Cache-yes shares will overflow to the array when cache has less than minimum, and cache-prefer shares won't get moved to cache if cache has less than minimum. Here is a wiki that gives a lot more detail about how the Use cache settings work: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#comment-537383

Your array disks are pretty full. You should probably plan to have more capacity. Your appdata is set to cache-no. It has some data on cache and some on various array disks. This isn't the recommended configuration. You want your apps on cache so they will perform better, and so they won't keep parity and array disks spun up. Your cache is pretty small though, so it might be best if you don't cache any of your other shares and just have your dockers on cache. In order to get mover to move your appdata user share to cache, you will have to set it to cache-prefer. You will also have to temporarily disable the docker service (Settings - Docker) since mover won't move open files. Before you run mover though, let's get a better idea how much of each user share is on each disk. Go to Shares - User Shares and click the Compute All button. It will take a while to produce the result. If it hasn't shown the result after several minutes refresh the page. Post a screenshot showing the results.

OK. I assume you mean the limetech plex is working for you again. Let's get some more information to get a more complete picture of how you have your Unraid configured, and how you have that docker configured. Go to Tools - Diagnostics and attach the complete Diagnostics zip file to your next post. Also get us the docker run command for that limetech plex. See the first link at the top of the Docker FAQ for instructions: https://forums.unraid.net/forums/topic/57181-real-docker-faq/ It might be useful to you if you read some of the other entries in the Docker FAQ.

Those screenshots show that you have several more mappings to your media in linuxserver, so it will be seeing these in separate root folders, whereas your limetech has a single media mapping, so it will be seeing a single root folder for your media. And the plex library database, with all the things you say you don't want to lose, is in the appdata. And that database is going to have references to the media paths that you setup, so if you want it to work they have to be exactly the same. Have you actually started the linuxserver plex? If so, then you have probably already overwritten whatever the limetech docker had.

Have you already run the "new"? If so it may be too late to do the backup, since it looks like you told the "new" to use the same appdata path as the "current" Screenshot captures might help.

I'm not entirely sure how to interpret your "current" and "new", but they definitely don't look like you have set them up the same. Did you take a backup of the appdata before trying to switch?

Possibly you aren't having this issue but some other. This issue is related to 6.7 and later. Have you tried an earlier version?

When you add a drive to a new slot, Unraid will clear it by writing zeros to the entire disk. If instead you use a new drive to replace an existing drive, Unraid will rebuild to it by writing the entire disk from the parity calculation. Either way the new drive gets a workout, though not as much as one (or more) preclear cycles. If you are only doing a single disk instead of several, and you are careful (always double-check connections) and diligent (have Notifications setup to alert you immediately), then maybe the possible infant mortality of that single disk isn't that much trouble to recover from. Somewhat less risk if you have dual parity.

Looks like you pasted the wrong link.

Some things I notice that are likely unrelated. Your syslog is filling with this over and over: Aug 16 01:29:38 Tower root: error: /plugins/preclear.disk/Preclear.php: wrong csrf_token Aug 16 01:29:38 Tower root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token ### [PREVIOUS LINE REPEATED 2 TIMES] ### https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-545988 Had you actually done a data transfer exhibiting the problem since you had last rebooted? If not then syslog would not contain any information about the transfers. Your docker image is many times larger than necessary. I usually recommend 20G for docker image. You are already using 28G, though nowhere near the 150G you have allocated. You do have a lot of dockers, so it might be possible that you actually do need more than 20G, but often the reason someone has set their docker image so large is because they have been filling it up due to misconfigured applications. Your docker image shouldn't really grow much and if it is you have something setup wrong. Now on to your complaint. You need to tell us more about the source and most especially the destination of the transfer. Are you transferring to a cached user share, an uncached user share, directly to cache, directly to a disk in the parity array, directly to an Unassigned Device? Do you get better speeds if you leave the network out of it and transfer between disks directly on the server using Krusader docker or from the terminal using mc (Midnight Commander) or a linux command?

Impossible for us to say anything further about your specific issues without more details. Possibly it is not at all the same. Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post. I may split your post and its responses into its own thread if appropriate.

Something is not right with that. Most likely you have connection issues with one or more disks. You must double-check all connections any time your are in the case. Post your diagnostics.

Would have been better if you had pasted the text instead of giving an image. I can't copy/paste anything from the image. That doesn't look like the default settings for that container. It is fine to make some changes to the defaults if you have a reason to and you understand what it will do. In the case of some dockers you have to add some things to the default anyway to make it work. But I don't understand what you are trying to do with this mapping: -v '/mnt/user/appdata/kde':'/media':'-rw' It should probably work that way anyway though, just not show you anything except that kde folder. Did you actually try clicking on the Connect button?

Post your docker run command as explained at the first link in the Docker FAQ: https://forums.unraid.net/topic/57181-real-docker-faq/

Since this is not the support thread for any particular plugin, we don't know. Which plugin did you install?

I suspect you haven't mapped any of your media. Post your docker run command as explained in the first link in the Docker FAQ: https://forums.unraid.net/topic/57181-real-docker-faq/ You might also take a look at a few of the other things in that FAQ to get a better idea how to use dockers.

If by server you mean the Unraid OS, it wouldn't. If by server you mean the actual hardware, yes that is exactly what happened. The hardware disconnected.

That should be the first problem you deal with. Since you are using such a very old version (3+ years) of Unraid, be sure to read these Update Notes: https://forums.unraid.net/topic/66327-unraid-os-version-650-stable-release-update-notes/

Have you tried the Manual method? It is in the Getting Started Guide linked on the Download page. Here is a direct link to that section of the wiki: https://wiki.unraid.net/UnRAID_6/Getting_Started#Manual_Method_.28Legacy.29

Actually I do have another thought to add. It is working fine for me.

I think most of the thoughts are already included in the text you posted. Since you don't give us any more information about what you might have tried from the suggestions in that, I guess we will wait to see if you have anything to add.

Did you read the link? Cache-yes will overflow when cache gets too full. Too full is defined by Minimum Free for cache in Global Share Settings. Should be set to larger than the largest file you expect to write to cache. Personally, I don't bother to cache queued downloads since I am not waiting on them to complete.

6.6.7 is available for download. Just backup your config folder, install 6.6.7, and restore config.