eat_eat_the_doreets

In case anyone else sees the above and thinks this is not possible / a dead end, see what I did. I am on 6.11.5. I also have keys generated in 2019 that I wanted to continue using. Add the block @frakman1 mentioned: RSAAuthentication yes PubkeyAuthentication yes HostKeyAlgorithms=ssh-rsa,[email protected] PubkeyAcceptedAlgorithms=+ssh-rsa,[email protected] to your /etc/ssh/sshd_config I added it after line 34 (PermitRootLogin yes) because there's certain blocks in the file, like the end, where it can't be added. You can't just append the above to the file. 2. Restart the sshd. /etc/rc.d/rc.sshd restart RSA keys should work now. If you want this to stay in effect for every boot: 1. First, copy the new config file you generated to somewhere it will stick around (unraid runs in RAM) I copied mine to the ssh folder of /boot/config (the USB key) because that should (?) be persistent cp -p /etc/ssh/sshd_config /boot/config/ssh/ 2. Get the Userscripts plugin 3. Create a new script, use these contents: #!/bin/bash cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-`date +%d-%m-%Y%H%M%S` cp -p /boot/config/ssh/sshd_config /etc/ssh/sshd_config /etc/rc.d/rc.sshd restart This just copies the file into place and restarts the sshd service. 4. Set the script to run "on array start". Bing bang boom, should be good to go.. I haven't tested a reboot though. Don't feel like resetting my uptime

Thanks so much for these instructions. I too use dynmap and saw rsync processes taking up all of the container's CPU .. i didn't put 2 and 2 together that Dynmap creates tons and tons of very small files. There are 2 modifications needed: Step 1 and 2 need to be "mkdir -p" to create the entire hierarchy of directories Step 5 - Copy the entire contents of the original web folder to the new folder. Something like: cd /mnt/user/appdata/binhex-mineos-node/mineos/games/servers/CREATIVE/plugins/dynmap/web <existing folder cp -pr * /mnt/user/appdata/binhex-mineos-node/mineos/games/dynmap/SURVIVAL/web/ < folder for server I was trying to fix Mine didn't work if I didn't do that - it only showed "directory : /" when you went to the webpage. Following those instructions has made my WebGUI load pretty much instantly again. Thanks!!

Hi Binhex, since you switched back to Java 8, my FTB Infinity server (based on minecraft 1.7.10) starts now. I just recreated the container. A lot of mod packs are still on older versions of the game that don't support Java 11. Is there a way to, in future when you're going to change to Java 11 again, make it a container parameter so we can launch with "java_runtime_8" or "java_runtime_11"? That would give everyone the most flexibility in running whatever servers they want. Thanks for making this container and for all that you do 😊

This has happened to me today, that's why I'm in this thread. I had 2 torrents queued (not actually started downloading) and I restarted the array (for a different issue) and when the container came back up they were gone. I also am having some completed (seeding) torrents going into Error, and the files are missing, frequently. But sonarr / radarr hardlinks / moves my media to my media / plex area so I'm not really too worried about that bug, but it is affecting my ratios on private trackers if I can't seed for 2 full weeks. Binhex... Do you want me to post some logs? I'd be happy to be a guinea pig and help with this. I think I still have my supervisord log from today when the container was restarted if that's helpful. There's nothing that stands out in it, to me.

Click Edit on the docker, and it's right above the variables and after the "console shell command" I changed this, and both my servers (1 FTB, one Vanilla) started perfectly.

For symptom 1, look in the binhex-delugevpn thread or on dockerhub for his instructions on how to change your endpoint. You should definitely use a New York or something endpoint, you don't need your traffic to go through Montreal for no reason. It's just editing a text file then restart the container. For me it's here: /mnt/cache/appdata/binhex-delugevpn/wireguard/wg0.conf (private information omitted...) Endpoint = ca-toronto.privacy.network:1337 For symptom 2, I'm not really sure 30ms is anything to be concerned about. It might vary widely if you're on wireless, your router /AP are busy, etc... 5 to 6 seconds really doesn't seem like a problem

for what it's worth, i'm getting this too in my logs, the container is operating normally right now (seeding and downloading fine) but I have had this issue in the past where I've had to restart the container. Previously, it ran for 11 days without issue. 2020-11-10 05:58:24,937 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '38175' 2020-11-10 06:13:30,983 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '38175' 2020-11-10 06:19:26,115 DEBG 'watchdog-script' stdout output: 0 2020-11-10 06:19:26,991 DEBG 'watchdog-script' stdout output: [warn] Incoming port site 'https://portchecker.co/' failed to web scrape, marking as failed 2020-11-10 06:19:27,904 DEBG 'watchdog-script' stdout output: 0 2020-11-10 06:28:31,377 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '38175' 2020-11-10 06:43:31,851 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '38175' 2020-11-10 06:50:33,809 DEBG 'watchdog-script' stdout output: 0 2020-11-10 06:50:34,691 DEBG 'watchdog-script' stdout output: [warn] Incoming port site 'https://portchecker.co/' failed to web scrape, marking as failed 2020-11-10 06:50:35,286 DEBG 'watchdog-script' stdout output: 0 2020-11-10 06:58:32,265 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '38175' Not sure if this is an early indicator of failure, or what.