nraygun

Mine stays up for a while, then overnight it goes into the state you are seeing. I think I have a good ovpn file since it does work upon a restart. We'll see what happens tomorrow morning since I recreated the container.

With the AppData backup app disabled, my DelugeVPN still fails overnight. I'll try rebuilding the container unless anyone else has recommendations. (deleted DelugeVPN from Docker tab, then Apps, Previous Apps, reinstall)

This keeps happening. Is there something that needs to be done to the container after a shutdown to make it come back up with a start up? For now, I'll disable the auto backup plugin and see if it stays up for the rest of the week.

No GPU passthrough. It serves its purpose without one for now.

I was able to get it to work with OCC 2.55.0.0. Looking at the page that hosts OCC, I don't see a reference to what version of OC it supports. I've seen in other posts something about 0.7.7, but the latest OpenCore at the https://github.com/thenickdude/KVM-Opencore/releases site says it's version v19. How can I find what version of OC I have? And how can I find what version of OCC supports what version of OC?

I couldn't get Monterey to work so I'm back to Big Sur. Using the new Macinabox container, do I have to use a particular version of Opencore Configurator to complete the installation or should I just go grab the latest one? When I run the latest 2.67.1.0, I get a popup that says "You seem to have an old version of OpenCore bootloader. This app creates a configuration file for 0.9.0 and higher versions. Use at your own risk."

It croaked again. This time it was downloading. Anyone have any suggestions?

It happened again. This time it was seeding. Restarting the container fixes it. Any ideas what's going on here?

Update on my connection refused issue. Without a seeding file, the container seems to shutdown and restart fine. It might be only when there's a seed in motion that it doesn't restart after a backup.

Still monitoring for an update to Boinc. Stay tuned.

Connection refused after container restart I have the AppData Backup plugin setup to run every night. This includes shutting down the containers, then restarting them. It appears that on the restart of DelugeVPN, the container is not accessible. I get a repeating pattern of errors below. unRaid shows the container is running but I can't access the webUI. To get it to work again, I have to restart the container via the unRaid GUI. Any ideas why it goes into this state? (there was an IP in the log so I hid it as iphidden) 2023-02-28 08:25:12,889 DEBG 'start-script' stdout output: [info] Starting OpenVPN (non daemonised)... 2023-02-28 08:25:12,904 DEBG 'start-script' stdout output: 2023-02-28 08:25:12 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 2023-02-28 08:25:12,904 DEBG 'start-script' stdout output: 2023-02-28 08:25:12 WARNING: file 'credentials.conf' is group or others accessible 2023-02-28 08:25:12,904 DEBG 'start-script' stdout output: 2023-02-28 08:25:12 OpenVPN 2.6.0 [git:makepkg/b999466418dddb89+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jan 25 2023 2023-02-28 08:25:12 library versions: OpenSSL 3.0.8 7 Feb 2023, LZO 2.10 2023-02-28 08:25:12,905 DEBG 'start-script' stdout output: 2023-02-28 08:25:12 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2023-02-28 08:25:12,909 DEBG 'start-script' stdout output: 2023-02-28 08:25:12 TCP/UDP: Preserving recently used remote address: [AF_INET]iphidden:1194 2023-02-28 08:25:12 UDPv4 link local: (not bound) 2023-02-28 08:25:12 UDPv4 link remote: [AF_INET]iphidden:1194 2023-02-28 08:25:13,018 DEBG 'start-script' stdout output: 2023-02-28 08:25:13 read UDPv4 [ECONNREFUSED]: Connection refused (fd=3,code=111) 2023-02-28 08:25:14,277 DEBG 'start-script' stdout output: 2023-02-28 08:25:14 read UDPv4 [ECONNREFUSED]: Connection refused (fd=3,code=111) 2023-02-28 08:25:18,990 DEBG 'start-script' stdout output: 2023-02-28 08:25:18 read UDPv4 [ECONNREFUSED]: Connection refused (fd=3,code=111) 2023-02-28 08:25:27,227 DEBG 'start-script' stdout output: 2023-02-28 08:25:27 read UDPv4 [ECONNREFUSED]: Connection refused (fd=3,code=111) 2023-02-28 08:25:42,547 DEBG 'start-script' stdout output: 2023-02-28 08:25:42 [UNDEF] Inactivity timeout (--ping-exit), exiting 2023-02-28 08:25:42,547 DEBG 'start-script' stdout output: 2023-02-28 08:25:42 SIGTERM[soft,ping-exit] received, process exiting

Roger that. Swag went down overnight. Just restarted the container and it and Nextcloud are back. Parity check still running from the shutdown due to the crash. Just getting a general instability feeling lately. I setup the syslog server so now we wait.

Had a lockup of my server today and trying to pin down if there's some bigger problem in play. I was out and about and had checked for a document in Nextcloud while I was out so I know it was working 3-4 hours previously. When I got home, I found the server was down. It was not accessible from the web GUI, I could not ping it, and the containers were down(couldnt get to Plex or Nextcloud). When I tried to interact with it over the iDRAC virtual console, that was locked up too. So I forced a reboot and it came up. Whew! Googling around I found a few threads, but they dont seem similar to my situation. I've not changed hardware. My Deluge is up to date. However, on the Deluge container, I did notice there was a problem with it when the server came back up. I restarted it and it's working now. https://forums.unraid.net/topic/130543-complete-server-lockup-611x/#comment-1187761 https://forums.unraid.net/topic/135518-server-locking-up/#comment-1232774 https://forums.unraid.net/bug-reports/stable-releases/crashes-since-updating-to-v611x-for-qbittorrent-and-deluge-users-r2153/?page=8&tab=comments The only other thing out of the ordinary is I had an XFS corruption issue on the cache drive a week or so ago. Following the repair process documented on the website seemed to have fixed that issue. I'll setup syslog if I can figure out how. I doubt the diags will show anything, but they're posted. Any ideas? flores-diagnostics-20230226-1756.zip

Following this thread. Mine locked up this afternoon. I couldn't ping it nor bring up the web gui. When I did a remote session into it with iDRAC, it seemed unresponsive/locked up. I went down to the basement to check it out and it appeared on.

Thanks @JorgeB! Looks like drive in question was the cache drive. I ran the repair and it completed. See below. It mentions something about lost+found but I don't see that in my Cache drive. Am I good to go? Also, I've never seen this before. Is this a common thing? Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done

Crapola! I saw this morning that the appdata backup plugin didn't complete. Looks like it couldnt stop the docker containers. I tried to stop them but they wouldn't. I then tried to kill off any zombie processes. I could not kill them nor their parents. I then decided to reboot the server. I can't tell at what stage the errors started, but it's stuck at a "Metadata corruption detected at xfs_dinode_verify+0xa0/0x732 [xfs], inode 0f42f168 dinode". It then says to run xfs_repair and shows the first 128 bytes of corrupted metadata buffer. Looks like it's sdb1 that has the problem. The situation looks similar to what's going on in the link below. Just want to confirm the right steps to recover. 1. Power cycle the server 2. If it comes up, then do the test and repair here: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui (not sure what to do if it doesn't come back up) Is this correct or should I do something else? Am I have a major server problem here or are XFS corruptions fairly common? PS - I can't provide logs with the server in this state. I

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?