trurl

It isn't so much about the mappings. It is about whether the application is using the container paths in the mappings or instead using some other paths. For example, suppose you have a mapping with a container path of "/download", but the application is using the path "/Download". Since linux is case-sensitive, these are different paths. Or the application might be using "download" instead of "/download". Since "download" is a relative path, it is going to be relative to something inside docker.img. Container Size button at the bottom of the Docker page.

Once a week is probably excessive. Most do once a month. Since parity is realtime parity checks are not needed to maintain parity. It is just a check. Post a screenshot of your parity schedule settings.

What is the current state of your array? Is anything still disabled or unmountable?

As I discovered custom docker network is apparently kept in docker.img, so when you recreate docker.img you must recreate custom network. It is a simple one line command best done before reinstalling containers.

Not for me, but this might:

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

You have allocated 150G to docker.img. 20G should be more than enough. I am running 17 dockers and they use less than half of 20G. But I see you are already using more than 20G, so more than should be needed. Have you had problems filling docker.img? Making it larger won't fix anything, it will just make it take longer to fill. The usual reason for filling docker.img is app writing into docker.img instead of to mapped storage. Common mistakes are specifying a path in the app that doesn't correspond to a container path in upper/lower case or specifying a relative path. Your appdata, domains, system shares are set to cache-no. They do have files on cache, but also files on the array. These shares should be cache-prefer (or cache-only after you get them all moved to cache). You want these shares set to keep all their files on cache. These shares are used by dockers/VMs. If the files are on the array, docker/VM performance will be impacted by slower parity writes, and dockers/VMs will keep array disks spinning since these files are always open. Getting all this fixed will require several steps. Let me know when parity sync has completed and we can start working on this.

post new diagnostics

If you have rebooted then it won't be full anymore.

https://wiki.unraid.net/UnRAID_6/Storage_Management#Replacing_disks

From backups may be the simplest. The problem is those files will have lost anything that tells their name or folder. How much is there?

syslog and docker.log in those diagnostics aren't very large but /var/log is full. What do you get from the command line with this? du -h /var/log

Do you know if docker.img is getting full? You can see on the Dashboard how much is getting used. You can also use the Container Size button at the bottom of the Docker page to see how much each is using.

Also, the version of Unraid you are running is over a year old. Why haven't you upgraded?

I have replied on your thread.

docker.img corrupt. Why have you allocated 40G to docker.img? Have you had problems filling it? 20G should be more than enough and making it larger won't fix anything, it will just take longer to fill. I am running 17 dockers and they are using less than half of 20G. You will have to delete and recreate docker.img. Previous Apps on the Apps page will reinstall your dockers just as they were. Some of your appdata is on the array. You should set that share to cache-prefer so it can be moved to cache. While you have docker disabled you can run mover to get the rest of appdata moved back to cache. Mover can't move open files so you will have to do that before installing your dockers again.

docker.img corrupt. You will have to delete and recreate it. Previous Apps on the Apps page will reinstall your dockers just as they were. Some of your appdata is on the array even though cache isn't full. Have you had problems filling cache? While you have docker disabled you can run mover to get the rest of appdata moved back to cache. Mover can't move open files so you will have to do that before installing your dockers again.

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

SMART for disk11 still looks OK. Stop, shutdown, check connections, SATA and power, both ends, including any splitters. Change SATA cable if you have another. Then reboot and Start parity sync again.

That is a lot of read errors on disk 11. Maybe the disk is failing. Go ahead and post those Diagnostics since that is the easiest way to get me everything else including SMART for all disks.

That isn't diagnostics, that is only syslog. Diagnostics contains syslog and many other things. But syslog probably has most of what we need now so I will take a look. You did manage to post diagnostics in the first post. It is on the Tools page.

Post diagnostics

Unmount that Unassigned Device. Stop the array. Go to Tools - New Config and keep all assignments. Before starting the array, reassign disk11. Make sure you do NOT check the box saying parity is valid, because it needs to be rebuilt. It may only be a little out-of-sync but it should be rebuilt anyway. Then Start the array to begin parity sync. If there are any problems during parity sync, post your diagnostics but let it continue pending further advice. What you should see during parity sync is a lot of Reads on all data disks, a lot of Writes to parity, and zeros in the Errors column. Parity sync errors are expected, be interesting to see how many.

No that is correct, just being cautious. Go ahead and start the array. Disk 11 should be missing, disabled, and unmountable but you should be able to look at the Unassigned disk on the network.