nraygun

Confirming this worked for me too. Not sure I needed to replace both, but I did anyway and Swag and Nextcloud are both back and up and running. For noobs like me, here's what I did: 1. Stop the Swag container 2. Go to the /mnt/user/appdata/swag/nginx folder 3. Rename your ssl.conf to ssl.conf.old and nginx.conf to nginx.conf.old (just in case we to restore them) 4. Copy ssl.conf.sample to ssl.conf and nginx.conf.sample to nginx.conf 5. Start the container and you should be good.

I add this to the .ovpn configuration file: tls-cipher "DEFAULT:@SECLEVEL=0" per this thread: https://superuser.com/questions/1737052/openssl-error0a00018essl-routinesca-md-too-weak And my VPN provider says they'll have updated certs in a month or so.

Crapola! I did find a workaround for now that allows the weaker cypher. I'll check with the VPN provider. @binhex Did the recent Deluge container update upgrade OpenSSL to 3.0? Thanks for the quick response!

Yes, same here. Seems to have stopped working after a container update last night(automated update). I see a deprecation warning, but I also see this error: 2023-01-15 10:38:11,187 DEBG 'start-script' stdout output: 2023-01-15 10:38:11 OpenSSL: error:0A00018E:SSL routines::ca md too weak 2023-01-15 10:38:11 Cannot load inline certificate file 2023-01-15 10:38:11 Exiting due to fatal error

Could swear I had posted an update. Anyway... I deleted both Boinc and boinc containers, deleted their appdata, and deleted their template. The updater ran a few times without either Boinc/boinc's coming back. I then re-added Boinc and the updated ran without adding back boinc. So far, so good. I just want to see what happens when there is a Boinc update. If it goes through without adding boinc, I think I'll be good to go.

The normal backup ran and I don't see a second "boinc" container. And it's updated other containers. Before I call this solved, I want to see what happens when there's a "Boinc" update. If I don't get the second "boinc" on that action, I'll call it solved. Stay tuned.

So far, so good. The backup ran overnight, it updated 1 other container, and I see no boinc or Boinc. Will schedule another update for tomorrow and see what happens, then I'll add the Boinc container back. Does anyone know of any other places that need to be cleared of the old boinc and Boinc containers?

I'm going to try deleting the two BOINC containers, their appdata, and the templates and schedule another autoupdate for tomorrow morning and see what happens.

I had a "boinc" (lower case "B") container installed which I deleted then installed a different container "Boinc" (upper case "B"). After my scheduled Docker autoupdate runs on Wednesdays, the old "boinc" keeps coming back. I tried deleting the container in the Docker tab and deleted its appdata and template. I also tried recreating the whole Docker image. The support for the autoupdate plugin says he just relies on what unRaid tells him to do the updates. The BOINC client in the "boinc" container doesn't run since the other "Boinc" container is running - which is good. After the old "boinc" comes back, I see that its appdata is pointing to the appdata of the "Boinc" container. And I don't see a template for "boinc" in my /boot/config/plugins/dockerMan/templates-user directory but I do see one for Boinc called my-Boinc.xml. The boinc container does NOT show up in the Installed Apps area nor in the Previous Apps area. Why does this old container keep coming back?

I recreated the Docker image and this morning's run of the auto update made the other "boinc" come back. And neither boinc was updated in the process - only 2 other containers were updated. Any other ideas on where to look to find why this container keeps coming back?

Ha! That's what I just figured out after wrestling with this all day! Also, for some reason, the container side ports and the server ports were set to the same port number. Changing these as appropriate (443 in container and 444 for the server) plus recreating the docker network did the trick. Whew! I guess rebuilding the docker container is not as straightforward as I thought it would be. I'm all good now. Thanks!

Ugh! I recently rebuilt my docker container as a result of a deleted container that kept coming back. Unfortunately, this process borked my Nextcloud. 😞 All other containers with a UI seem to work fine. The Nextcloud container is running but when I try to access the WebUI I get a 502 Bad Gateway error. I tried the direct ip:port, but it seems to resolve to a name. I have Swag running as well. Note that when the docker rebuilt these two containers, the Network Type was set to none. I changed these to bridge but still no go. I'm a relative noob and I'm not even sure where to start looking. Attached diagnostic file. flores-diagnostics-20221228-1328.zip

Oh well, so much for that idea. The extra boinc container came back again after this morning's run of the backup. I'll research and try recreating the Docker image. Hope I don't screw it up.

I think I got it. I deleted the container again, deleted its appdata, then deleted its template. I had it run again this morning and the old "boinc" container didn't come back this time. I put the updater's settings back to the normal day for the backup(Wed) so we'll see what happens.

I'm having a problem where an old Docker container comes back after the auto update is done. I had a "boinc" container (lower case B) but was having problems with it so I deleted and added a different one called "Boinc" (upper case B). I see a single container called "Boinc" until the updater runs on Wednesday's, then I see the other older "boinc" container has returned. I delete the "boinc" instance again, and I'm good until the following Wednesday. I also tried deleting them both and loading back the new one, Boinc. In looking at the settings of this plugin, if I change the option to update all to No, I can see a list of containers with a toggle to turn on autoupdate. I can see the old "boinc" container in this list. Is this a Docker problem I'm having or a plugin issue? Any ideas on how to make the deletion of the old "boinc" container permanent?

Did you try removing the /dev/dri: parameter from your container? Stop the container, go to settings, remove /dev/dri, then restart the container and see if that helps. If it does, you'll have to do this every time the container is updated.

BINGO! I changed them both to be the same (omitting the bzroot-gui for the default) and the problem is solved - no more prompt for a reboot when looking at the VM settings!!! Woohoo! Thank you so much @SimonF!!! Not sure, but maybe in the past I changed the syslinux file manually. But wouldn't changing it in the GUI write a new one? Oh well, it's fixed. Thanks again!

The setting in the GUI for PCI ACS override is "both", not "downstream". Maybe I need to change that? Is "both" the proper parameter name?

default menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 50 label Unraid OS menu default kernel /bzimage append initrd=/bzroot pcie_acs_override=downstream,multifunction vfio_iommu_type1.allow_unsafe_interrupts=1 label Unraid OS GUI Mode kernel /bzimage append vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream,multifunction initrd=/bzroot,/bzroot-gui label Unraid OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label Unraid OS GUI Safe Mode (no plugins) kernel /bzimage append initrd=/bzroot,/bzroot-gui unraidsafemode label Memtest86+ kernel /memtest The default looks similar to the default except the default has commas and the parameters are in a different order. Should I make the default parameters the same as the GUI mode?

Still looking for more support on this. Hope someone can help or steer me in the right direction.

Any other ideas?

Tried a few more things. I turned the PCIe ACS override off(disabled). Still get the reboot message after rebooting. I tried deleted the virtio driver and redownloading. Still get the message after rebooting.

Tried a few more things. 1. Tried Edge from a Windows VM. Thought maybe Firefox in Linux was doing something weird. Nope. Same problem. 2.I see the following in the HTML/script of the page. Is that php script changing the file for no reason? I can see the file change when entering the page and upon reload. Is there a way to see this "data" object before and after it goes to the php script? Note that I don't know Javascript nor PHP. $.post("/plugins/dynamix.vm.manager/include/VMajax.php", {action:'reboot'}, function(data){ var rebootMessage = "VM Settings: A reboot is required to apply changes"; if (data.modified) addRebootNotice(rebootMessage); else removeRebootNotice(rebootMessage); });

I tried moving domain.cfg around before. On 7/6 I tried this: "Copied the domain.cfg to domain.old, deleted the file, then had unRaid recreate the file. I rebooted, then went to the VM Manager area, and it still has the reboot message at the top." This time, if I read your suggestion correctly, I just deleted the domain.cfg file then rebooted. When I went to go look at the VM Settings, I got the prompt again at the top to reboot. I just put the settings back to the way they were (had copied the original domain.cfg somewhere else) and tested a few VMs to make sure they still work. They do. Not sure where to go from here.

Just to make sure, I created another trial instance and booted a laptop with an extra USB to act as the array. I went into Settings, then VM Manager, and it did NOT display the reboot message. So I guess there's something wrong with my main unRaid system. 😞 Since I purchased a license for my main system, is there some sort of formal support path I need to engage? I'd like to get this resolved.