trurl

Absolute and relative paths are a general concept and not really about Unraid specifically. An absolute path is any path beginning with / on Linux. On windows, an absolute path begins with \ since that is the path separator used by Windows. An absolute path begins at the root of the filesystem, such a C:\ in Windows. In Unraid, an absolute path will be a path like /mnt/user/... That path begins at the root and goes down into the mnt folder, then from there to the user folder, etc. A relative path is any path relative to an already specified or assumed directory, often to the current directory. A relative path does not begin with / For example, if you are already in the /mnt/user directory, then just specifying the relative path appdata is enough to refer to /mnt/user/appdata. When setting up an application, there are usually paths that you must specify, such as where to download files. If you specify a relative path instead of an absolute path, that path will be inside the docker image. Relative paths are not allowed in docker mappings, so any container path is an absolute path within the container that corresponds to an absolute host path.

That looks good. Since you are a storage engineer, I assume you know about paths generally, and the difference between a relative and an absolute path. I will also mention that Linux is case sensitive, so "Downloads" and "downloads" are different paths. As I mentioned above These application paths I mention above are the paths set within the application itself, not in the mappings. Do you understand docker volume mappings? That is the thing that often confuses people in the beginning with dockers, and they wind up getting things sort of working by blindly following someone else. I think the word "map" may not make sense to some people in this context, though it is often used in this somewhat abstract way in other contexts such as mathematics. A mapping is just a correspondence. Just as a place on a road map corresponds to a place in the world. A docker volume mapping is a correspondence between a path on the host (Unraid) and a path within the container. Port mapping is similar, a correspondence between ports on the host and ports within the container. If you understand mappings you are most of the way there to setting up any docker. Another piece of this puzzle is the paths to the user shares. The user shares are at /mnt/user/... The Unraid webUI helps you out with this when setting up a docker since it gives you these paths to choose from when setting up a docker, for example, /mnt/user/appdata. Which dockers have you been using?

Looking at the SMART folder in your diagnostics, there are some other things you might consider. I'll just put this here for later discussion if it seems appropriate. You are using a controller that isn't passing the serial number or SMART information from your disks. Disk controllers are not my area of expertise so I am going to see if @johnnie.black has any recommendations. Fixing that may be more trouble than it is worth, but I don't think Unraid can monitor your disk health the way it is, and you have a lot of disks and only single parity. I always recommend fewer, larger disks instead of more, smaller disks. Larger disks perform better and are less expensive TB/$ than smaller disks, and each additional disk is an additional point of failure that requires more hardware to support it .

I use some of these same dockers, and nothing has changed that will break them in this manner. Your setup has been wrong from the beginning, as illustrated by your filling an incredibly huge docker image. Somewhat surprisingly, your appdata, domains, and system shares are all on cache as they should be. Your docker image, which is going to be the first thing we deal with since it is ridiculous, is not on any user share. It is not even specifically on any disk. You have configured it to be at the root of the user shares, /mnt/user/docker.img. Go to Settings - Docker, disable dockers, and delete the docker image. Change the path of docker image to /mnt/user/system/docker.img, and set its size to 20GB. Then enable docker, but don't install any dockers yet. That will put your docker image on the system share where it belongs, and since the system share is cache-prefer, it will wind up on cache where it belongs. When you have done that much post new diagnostics so I can verify. Then we can begin working on getting your dockers set up correctly. Maybe after we work through one or two of them you will understand how this is supposed to work.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

Since you already had this on 2 different threads (I won't say they were hijacks exactly since one was dead and the other resolved), I have collected all the posts related to your issue into this thread. You have literally the largest docker image I have ever seen, 2TB, and you are still filling it up. I always recommend 20G for docker image. That should be more than enough, and if it is growing you have something wrong. Of course, you know you have something wrong, but I suspect you have had something wrong for a while now. I sort of looked back at some of your post history and you have had problems with your dockers for years and your fix seems to be mostly just deleting docker image and starting over. How long have you had a docker image larger than 20GB? The usual reason for filling docker image is an application writing to a path that isn't mapped. Typical mistakes are using a different upper/lower case than specified as the container path in the mappings, or specifying a relative instead of an absolute path.

To give an example on how Minimum Free works: You have a user share set to 10GB minimum. A disk has 11GB free. Unraid can choose the disk because it has more than minimum, and due to other factors, it does choose the disk and not some other. You write a 9GB file. After that, the disk has 2GB free. Since this is now less than minimum, Unraid will not choose the disk again. Another example, similar conditions as above, but: 10GB minimum, disk has 11GB free, write a 15GB file. The disk can still be chosen since it has more than minimum, and it will run out of space trying to write the 15GB file.

There seems to be some confusion about Minimum Free on this thread. Unraid has no way to know how large a file will become when it chooses a disk to write it to. If a disk has more than minimum, Unraid can choose the disk, no matter how large the file is. This is why the advice is to set Minimum Free for a share to larger than the largest file you expect to write to that user share. To the OP, putting all these different things into a single user share keeps you (and Unraid) from managing them differently.

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

Another approach: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?tab=comments#comment-462135

Your keys are in the config folder on the flash drive. You should only have the pro key. Your system share, where your docker image and libvirt image are stored, has files on disk1 instead of all on cache, so your dockers and VMs could keep parity and disk1 spun up since they will be using those files.

appdata is one of your user shares. Can you see any of your user shares in Krusader?

Maybe you missed this earlier reply in all the excitement: https://forums.unraid.net/topic/91138-cache-not-being-moved/?do=findComment&comment=846549

It shouldn't create a new share, and you don't really want it to, do you? /downloads is mapped to /mnt/user/Downloads. That is your share named Downloads, which you already created, and which is presumably where you want your downloads to go. It will now put new downloads into your Downloads share. As for those previous downloads, you will have to get them out of appdata and put them where they belong, Downloads. You can use Krusader for that.

Not what you want to do anyway. You need to take your time and pay very close attention to upper and lower case.

You shouldn't need to worry about seeing cache in Krusader in order to use Krusader to get those downloads out of your appdata. It is appdata you are interested in, some of which (but not all) is on cache.

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your NEXT post. Also, post the docker run command for your Sonarr docker as explained at this very first link in the Docker FAQ:

Exactly what we were saying. You have the settings WITHIN the application wrong. You must be telling it to download to "downloads" instead of to "/downloads". You would have to give us the docker run for your Krusader before we could even speculate.

Cache is always included in user shares just the same way array disks are. So if you have a share named Downloads, and part of it is on cache, then anything that looks at Downloads is going to see all its files whether they are on cache or the array. This last screenshot isn't what I asked for. It is only showing the same information we already got from your docker run you posted earlier. What I was asking for was the folder settings WITHIN the application itself. Likely you have exactly what Squid suspects: If you told SAB to download to "downloads" instead of to "/downloads", then it is going into a subfolder of "/config", which is mapped to your appdata share.

This is a share named Downloads. Doesn't seem like you are understanding the difference. Linux is case-sensitive, Downloads and downloads are completely different folders, and you don't have a share named downloads. Your mappings seem to indicate that SAB should see the Downloads share, /mnt/user/Downloads at the container path downloads. As Squid noted, though, your more immediate problem is full cache. According to your diagnostics, only appdata, domains, and system shares have anything on cache. Could be your downloads are going into appdata. And this last screenshot you just gave makes me think you are downloading into appdata. I haven't used SAB in a while, but I'm sure there are settings within the application where you tell it where to download files. Possibly you are sending them to a subfolder of /config, which is mapped to /mnt/user/appdata. Give us a screenshot of the folder settings for SAB.

Looking at a post you made nearly a year ago, it appears you must have plenty of license to plug in lots of drives. So, you could just setup your new server with the license you already have, using the same flash drive it is already on. Then use the Unassigned Devices plugin and just plug in the drives from the old server one at a time and copy their data that way.

And if you are downloading into the docker image, that would be due to writing to a path that isn't mapped. You likely have specified the wrong upper/lower case somewhere. Don't do this. It can only be bad. If you have a user share and a UD share with the same name then SMB is only going to show you the contents of one of them.

You repeatedly talk about the downloads folder, but from your diagnostics it looks like the user share is actually named Downloads. That share is completely on disk1 according to the diagnostics. You have no user shares named download or downloads. And you say you can't locate the downloads anywhere. Are you sure you have your docker mappings correct? My guess is you are downloading into a folder inside the docker image. Post your docker run for SAB as explained in this very first link in the Docker FAQ: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564345

Correct Other disks look fine.