trurl

As I mentioned, Linux is case-sensitive. You shouldn't have a Downloads folder unless you told it Downloads when you should have told it downloads. Where are you seeing this Downloads folder?

Are you trying to work with new downloads, or the downloads that sab already told radarr where to look?

Probably the 'arr created an empty folder to put them in, but it couldn't find anything to put there since it didn't have access to the folder sab told it to look in.

How are you looking for the files? From outside the containers, only the host paths exist, such as your Dwnlds user share.

If you made the changes we discussed, nothing should be looking in /dwnlds. Since these applications haven't been using the same paths, anything they have already done probably won't work together since they have already told the other application the wrong path. You will have to manually move the downloaded files yourself and see if new downloads will work

After you make the change to the container paths so sabnzbd has the /downloads path, you need to go into the webUI of sabnzbd and change the setting for the path. I use nzbget instead but the idea is the same, there is a setting where it has /dwnlds and it needs to be changed to /downloads. Very important. Linux is case-sensitive. For things to match, they have to use the same upper/lowercase. So, Downloads doesn't match downloads. Also very important, mapped container paths must begin with the /, since they must be absolute (not relative) paths. This means they must also begin with / within the application. So, /downloads is correct, downloads is not.

When sabnzbd finishes downloading, it tells radarr/sonarr where it put the download, which is the container path /dwnlds, but radarr/sonarr doesn't know about a path /dwnlds, so they can't find the download. You need to make them have the same container path mapping to host path /mnt/user/Dwnlds

Your downloads are going to your Dwnlds user share at the host path /mnt/user/Dwnlds. Each of those containers already has a mapping to that host path, but the container path doesn't match, and the container path is the path each application knows about. If you have several 'arr containers, and they are all using the container path /downloads, then the simplest fix would be to change the container path in sabnzbd from /dwnlds to /downloads, so it matches the 'arrs, and then setup sabnzbd to download to /downloads instead of to /dwnlds

correct

Each of your containers only has access to its own mapped container paths. sab doesn't know about a path named downloads, and radarr/sonarr don't know about a path named dwnlds

Same problem with sonarr, of course.

sabnzbd has a container path dwnlds mapped to your Dwnlds user share, but radarr has a container path downloads mapped to your Dwnlds user share. sab puts it downloads into dwnlds then tells radarr to go there to get it, but radarr doesn't have dwnlds.

except

You didn't have to "apply" the change, you just needed to make a change to enable the "Apply" button. Then you could have changed it back before doing "Apply". And the changes you made failed due to the port change, but I assume when you changed them back they reinstalled OK. In any case, you got the information I wanted to see. I will take a look at it.

Windows won't even let you install it on most old hardware.

Click on the container icon to get its popup menu, select Edit

Post docker run for sabnzbd and sonarr

What application is doing the downloads?

What application is that screenshot from?

Looks like everything got moved where it belongs. Noticed you don't have parity. Do you plan to add a parity drive?

It will move the array files from appdata and system to cache, except for duplicates as mentioned. If a file is already on cache it won't be moved from the array. After mover finishes post new diagnostics and we will see if anything got left on the array.

Those shares are already configured to be moved to cache when Mover runs. You can run it from Main - Array Operation. Mover won't replace files so if there are duplicates you will have to remove those manually using the File Manager. You should do an extended SMART self-test on cache.

Your appdata and system shares have files on the array. You probably had Docker/VM Manager enabled when cache wasn't working, so those got created on the array. Better if Docker/VM related shares are all on cache or other pool with nothing on the array, so Docker/VM will perform better, and so array disks can spin down since these files are always open. Nothing can move open files, so you will have to disable Docker and VM Manager in Settings before these shares can be moved. There is a plugin for appdata backups:

If you don't have more than 4 drives per PSU cable, It is OK to split MOLEX to 4 SATA, just don't split SATA to more than 2 SATA. Better to avoid SATA-SATA splitters.

In addition to the settings Previous Apps uses to setup your dockers again. each container needs its appdata or you will have to setup the application again. You need backups of appdata. For additional advice Attach Diagnostics ZIP to your NEXT post in this thread.