Squid

try reinstalling and give the /config (show more settings) a different path / folder name

You can always limit the memory usage https://forums.unraid.net/topic/57181-real-docker-faq/?page=2#comment-566088

Try today's update

Can't do that without rewriting the built-in mover script

The auto update plugin has never and will never update the OS for a user Sent from my SM-A530W using Tapatalk

It would be something like within the container you've got a setting thats putting say the downloads into /Downloads instead of /downloads

Something like this. csrf=$(cat /var/local/emhttp/var.ini | grep csrf | sed 's/.*="\(.*\)"/\1/') curl -d "csrf_token=${csrf}" -d "cmd=add" -d "e=Transmission: Torrent Done" -d "s=Download finished" -d "d=Download of Torrent" -d "i=normal" -u "root:THEROOTPASSWORD" "http://192.168.1.61/webGui/include/Notify.php" You would need to map "/" to "/" on the container

Still can't replicate it, no matter what I've done, dockerMan is keeping track of the adjusted filename, and picking up the correct xml in the URL always

I'll retest, but iirc dockerMan did keep track of the change of the filename. That being said, it was an edge case it solved. Mainly because of the multiple apps called Plex Media Server where users would up installing incorrect versions of what they wanted simply because of FAT32 naming conventions

Wow. I'm going to step back from this thread, as its going to quickly degrade.

Not to argue, but I do think that this bug is urgent, and does require a special release just to fix it, without waiting for whatever else happens to be scheduled for 6.6.5 It can potentially result in lost data due to the cache drive filling up, containers crashing, notifications not being sent etc. Personally, I'm going to give this a day or two tops to be fixed, and then ultimately I'm going to have no choice but to downgrade back to 6.6.3, as I (and probably many users around here) are reliant upon notifications, scripts running on a schedule.

Under CPU isolation, remove all references to Docker. Make it simple and state its to isolate cores so that VMs have exclusive access to it. While technically you can pin docker to an isolated core, it introduces complications and support headaches as to why it doesn't run on multiple cores. Additionally, per my original suggestion on the originating PR, don't allow containers to be pinned to isolated cores via the GUI. Uber advanced users can still do it via extra parameters.

OTOH with zero testing, etc basically following the dockerHub directions for it. See here https://hub.docker.com/r/mayanedms/mayanedms/ Install PostGres (available in Apps) Add the following environment variables POSTGRES_USER=mayan POSTGRES_DB=mayan POSTGRES_PASSWORD=mayanuserpass Enable dockerHub searching in CA's settings and search for mayanedms Add the following environment variables MAYAN_DATABASE_ENGINE=django.db.backends.postgresql MAYAN_DATABASE_HOST=unRaid's IP address MAYAN_DATABASE_PORT=the port for postgres MAYAN_DATABASE_NAME=mayan MAYAN_DATABASE_PASSWORD=mayanuserpass MAYAN_DATABASE_USER=mayan MAYAN_DATABASE_CONN_MAX_AGE=60

You would have to also scrape var.ini to get the current csrf token and then append it to the url. Would probably ultimately be easier to instead add a path mapping to /usr/local/emhttp/plugins/dynamix/scripts and then execute notify.php directly as a script.

Not at all. Rather, if there is another one in there, I am curious if dockerMan was getting confused as to which one it was dealing with. IE: I downloaded and installed sonarr using your template, and was completely unable to replicate the problem. The reason why is because my-Sonarr.xml isn't the actual name of the container. According to the xml you posted, the name of the container is sonarr (lowercase). Due to an edge case scenario a couple of revs ago I submitted a code change to dockerMan to handle filename collisions on the boot drive (which is FAT32) which makes no differentiation between my-Sonarr.xml and my-sonarr.xml hence it began to add a (1) to it. IE: the name of the container dictates the filename. You *may* be running into a weird little edge case with this, but I still can't replicate the problem.

Generally, you would reference the IP address of the server with the applicable port number

Opening in your browser should display it properly. Might have to rename it to be .html

Should work no problems. I get the list of running containers before executing the custom stop script.

cat /tmp/fix.common.problems/extendedLog | todos > /boot/extendedLog.txt

Is there another my-Sonarr.xml in there? Like my-Sonarr (1).xml?

Can you post the relevant xml file from /config/plugins/dockerMan/templates-user on the flash drive and also your diagnostics after doing replicating this again. But one comment Part of the update process is to also update the templates with some certain information. Notably in this case is the Config entries. This means that if the template author has a config entry which you do not, then it gets added (for requirements of the app etc). Net result is that it gets (*should*) added back in in this particular case. Doesn't completely explain your problem though as I can't replicate it myself, hence why I'm asking for the particular xml.

Advanced settings Sent from my SM-T560NU using Tapatalk

Don't know about the 100% cpu, but can tell you that you don't have your path mappings set up correctly between Radarr and your DL client https://forums.unraid.net/topic/57181-real-docker-faq/?page=2#comment-566086

Alternative is to simply download the .zip file instead of the creator. Format (as FAT32) the flash drive. Name it UNRAID Copy all of the files from the zip to the flash drive Run (as administrator) MakeBootable.bat