trurl

Go ahead and post docker run command.

OK, I just looked at sonarr (as I said I'm a new user). I mostly use radarr, but they are basically the same. It doesn't look like there is anywhere to set any paths, so I think it just relies on working with the other applications. If you don't get any errors then let it work for a while and check that files are showing up in the user shares they are supposed to. Then get new diagnostics so we can confirm your docker image isn't growing.

OK, that looks good, and is consistent with the mappings for plex and NZBGet. Now we need to look at the paths you have setup within the sonarr application.

When finished, I recommend disabling disk shares, or set it to Auto. That way nobody will accidentally

Perhaps you had already acknowledged and dismissed a warning it had earlier. If you go to Main and click on the disk to get to its page, then go to Attributes, you should see that attribute highlighted.

Apparently that is what you get with SAS drives, less than ideal but what we have. Here is another recent post about that: https://forums.unraid.net/topic/91279-aneely-docker-image-filling-up/?do=findComment&comment=846769

Those look good. Reinstall your sonarr container and post the docker run command for that.

We may have to take this up again in several hours since it is my bedtime.

OK, those look good. I assume the downloads went as expected. Now on to the trickier part, setting up sonarr. I am a fairly new user to sonarr and radarr, but they are working for me. The main thing that often trips people up with these is making sure they can properly communicate the paths with nzbget, etc. Basically, you just need to make sure they are doing the mappings the same way. To me, this suggests that you had a relative path somewhere in the settings for sonarr, since /usr isn't going to be part of a mapped path but /usr/local/bin might very well be the "current directory" of the executable inside the container.

Rebuilding an unmountable filesystem usually results in an unmountable filesystem, so the filesystem will probably have to be repaired after the rebuild. If you had asked before starting the rebuild, we could have tried to repair the emulated filesystem before rebuilding it, and maybe we would have had other options at that point. Replacing / rebuilding a disk with a smaller disk isn't possible. You could set a New Config and assign any disk you wanted, but then rebuild wouldn't be possible. Disk12 will also have to be rebuilt to make it consistent with parity, but since it is empty it can be formatted again instead of repairing its filesystem. Diagnostics are after reboot so no syslog from when the problems occurred. Also your controller isn't passing the usual complete SMART attributes. I'm not sure how to interpret that but it does indicate disks are OK, just don't know whether or not its idea of OK is the same as ours. Let the disk10 rebuild complete if it will, and post new diagnostics either way.

OK, that looks good. Use NZBGet to download something. You should see it is downloading and processing files in the user share named downloads, since NZBGet is set to use paths in /data, and /data is mapped to /mnt/user/downloads. After it completes a download or two, post new diagnostics so we can verify that docker image isn't growing.

OK, that looks good too. Just noticed you don't have docker log rotation turned on. Go to Settings - Docker, disable docker, turn on log rotation, and enable docker again. Then post new diagnostics.

Or, instead of the screenshots, you can post the contents of the NZBGet configuration file at /mnt/user/appdata/binhex-nzbget/nzbget.conf

That looks OK too. Now here is the part where you can screw it up. Within the NZBGet application itself, go to Settings - Paths, and post screenshots of those settings.

Are you mapping it with the R/W Slave Access Mode?

According to this screenshot, appdata is the name of the mounted partition so it should be /mnt/disks/appdata. I have one like this and I have given the mount a name and that is how it is shared and referred to under /mnt/disks. However, I do recommend not naming it the same as a user share, since if you ever do share it SMB won't be able to display both shares if they have the same name.

OK, plex is an easy one, and since it doesn't usually write anything except its own appdata (unless you specify a special path for transcoding) it is also unlikely to fill your docker image. NZBGet is another container I happen to use, the linuxserver one. And since it is used to download and process large files, it can definitely write into and fill docker image if you don't configure it correctly. Reinstall your NZBGet container and post the docker run command for that.

If you go with the binhex plex, then according to your mappings plex is going to see all of your user shares (/mnt/user) in the /media folder.

Or you can use Previous Apps to install the linuxserver plex you had before.

That looks OK. Is it working as you expect? Since you changed dockers and presumably the appdata path, it will be a completely new install of plex and you will have to set up your media again.

But Previous Apps is going to let you reuse the settings you already had for a container you were already using.

Whichever you prefer. I am more familiar with the linuxserver containers.

You don't need DuckDNS to connect to plex. What are you trying to do?

There are several different plex containers available in Community Applications, they have different defaults, and some of those defaults are incomplete. Review this very first link in the Docker FAQ: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564345 Go to Apps and use the Previous Apps feature. Reinstall your plex docker and post the resulting docker run command.

With plex, are you trying to do anything fancy with transcoding, such as hardware transcoding or transcoding in RAM?