trurl

👍

OK, looks like you have plenty of space on cache now. Set appdata, domains, and system share to cache-prefer Run Mover again and wait for it to complete Post new diagnostics

You specify the path of the docker image when you enable docker service in Settings - Docker. The default is in the system share. There is absolutely no reason to back it up. In fact, we often recommend people delete it when they have some kinds of problems, so it can be recreated. The docker image contains the executable code of all your containers, and these are easily downloaded again. The Previous Apps feature on the Apps page will reinstall your dockers just as they were. Possibly what you are thinking of when you say "config" is the mappings and other things on the Add/Edit Container page. These are saved in a template on the flash drive when you create/edit a container, and these templates can be reused by simply selecting the template on the Add Container page, or more simply, by using the Previous Apps feature previously mentioned. So, a current backup of flash is also important. It is especially important to have a flash backup with the current disk assignments. You can download a zipped backup of flash at any time by going to Main - Boot Device - Flash - Flash Backup. Or you can schedule an automatic backup of flash with CA Backup. It seems like all the reasons you are considering removing cache has better solutions. And letting Unraid manage cache as part of user shares is much simpler.

And SSDs in the array cannot be trimmed. Since you are planning to move downloads anyway, why not just do cache pool, downloads as cache-yes, and use the CA Backup plugin to backup appdata? Docker image in system doesn't need backup since it is easily recreated.

Let parity finish rebuilding then reboot and post new diagnostics.

Do you have any VMs? For now we will concentrate on getting space on cache, so that later we can move those things to cache that should be there. Go to Settings - Docker and disable dockers. Do the same for Settings - VM Manager. Leave them disabled until we have finished moving things. Set appdata, domains, and system share to cache-only. This will make mover ignore them for now. Later we will set them to prefer so they will be moved to cache. Set that P-------a share to cache-yes Go to Main - Array Operation and Move Now. Wait for it to complete. Then post new diagnostics,

Any application path that doesn't correspond to a mapped host path is inside the docker image.

You have a share anonymized as P-------a which is cache-prefer. The cache-prefer setting means try to keep the share on cache, and if any of it winds up on the array, try to move it to cache. Most likely this is what is filling your cache. What is the purpose of share P-------a? On the other hand you have some shares that should be all on cache but aren't, some because of the setting you have made for the share and some because there isn't space. These are going to affect docker/VM performance and keep array disks spinning.

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

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

Have you read the first post in this thread? Specifically this part?

Unraid does not copy files. What are you actually using to do the copy?

And make sure nothing is pulling on the connection. The cables must have enough slack so the connector sits square and is not disturbed. Also, don't bundle SATA cables.

Since it is just 1 CRC I would just acknowledge it and let it go unless it increases.

But why did you have 50G docker image? If it is working as before it is likely just a matter of time before it corrupts again.

Or even easier. If you have already installed the docker, just click on its icon on the Dashboard or Dockers page and select Support.

Unlikely. Unraid disables a disk when a write to it fails, simple as that. Almost certainly a hardware problem.

Since nobody directly answered this. Parity drives should spin down unless something is writing to the array. So it depends on how frequently your array is written. I can certainly imagine use cases where parity seldom spins up.

Your docker image is corrupt, and the fact you had 50G allocated to docker image likely means you have been filling it. 20G should be more than enough. Making it larger won't help anything, it will just make it take longer to fill. You need to figure out what is writing into the docker image instead of to mapped storage. Your system share has files on the array instead of all on cache. Your domains share likewise. Do you have any VMs? Go to Settings - Docker, disable, delete docker image. Go to Settings - VM Manager, disable. Set system and domains share to cache-prefer, run mover, wait for it to complete. Then post new diagnostics

Looks like docker image usage is fine now. If you want to reduce it to 20G and recover the other 20G you can delete and recreate it in Settings - Docker then the Previous Apps feature on the Apps page will reinstall your dockers just as they were.

Parity is invalid until parity is built. Once it has finished building it will become valid and the warning will be gone. "Spin Down" is just telling you how you can spin down any disk. If you mouseover any of the other disks it will say the same. No point in spinning anything down now though since all disks must be read to build parity.

Looks mostly OK. appdata and system shares are all on cache and set to cache prefer. People usually also put domains share on cache and cache prefer for better VM performance, but you don't have VMs enabled currently. Why do you have 40G allocated to docker image? You aren't using even 10G, I usually recommend 20G. I always ask if someone has been filling docker image when I see it set to more than 20G.

Posting diagnostics will let us see which disks these docker/VM shares are currently using and we can advise further.

Have you tried the manual method? https://wiki.unraid.net/UnRAID_6/Getting_Started#Manual_Method_.28Legacy.29

CRC errors are typically connection issues not drive problems. You can click on that SMART warning on the Dashboard and acknowledge it and it won't warn you again unless it increases. The small number of parity errors is typical of unclean shutdowns. But the only acceptable number of parity errors is exactly zero, so they must be corrected. If there are still parity errors after a correcting parity check then you still have problems to diagnose, so after parity errors get corrected we usually recommend following with a non-correcting parity check to verify that parity has zero errors now.