Sn3akyP3t3

Why is this plugin being called out as an Error from the FixProblems plugin? I don't believe it belongs in the category of Error. Should be downgraded to Warning.

Have you tried adding the optional JAVA_CUSTOM_ARGS key to your container configuration with that --bonusChest as the value?

My resolution for this all was to recreate the docker image using the previous apps feature. Rather than attempt the possible fate of resurrecting the nondeterministic behavior with custom networks I've decided to go whole enchilada with vlan tagging instead. This provides the desired network segregation similar to what I was getting with custom networks, but probably far more granular and likely enables possibilities that I'm not yet aware of.

No idea at the moment. I have kept the docker image around for now in case there's some means to exhume some information that would be helpful to answer that question. The logs from docker in this area are quite insignificant at identifying what exactly the root conflict really is: I suspect the problem to be related to "custom networks", but I have no solid proof. Only that the relief in bringing the docker image back into service had to do with disabling preservation of custom networks and that one of the qwirk behaviors observed while I was able to operate in this degraded state was that selected custom networks deslected themselves whenever a docker container updated itself with the auto-update feature.

Updated to 6.12.10 today. The problem now is that the mentioned workaround above no longer works. I'm unclear what triggered this to begin in the first place. I'll be rebuilding my docker container structure tomorrow in an attempt to recover from this situation. I also saw the comments in the release notes about changing from macvlan (which is the setting applied currently) to ipvlan, but that appears to be greyed out. I don't know why I would have switched to macvlan, but if they're required for docker custom networks then that is likely why. I did notice one awkward behavior never observed before while operating in this manner. Whenever a docker container updates it deselects the custom docker network that was previously using. This might be expected per the setting to `Preserve user defined networks: No`, but I wouldn't know for sure as I was only doing this because this is the only combo selection of settings that worked.

Went through a diagnostic log after being anonymized by the UnRaid server and found some areas that were not anonymized that I thought should and some that clearly are just missing coverage. The following are generically not anonymized: Hostname/ServerName WORKGROUP The following files had sections not anonymized

I think I narrowed down the problem to "custom networks" and I did eventually mount and load all containers from the original docker image, but I don't understand how or why it is working now if that is the correct root cause. To start with I decided to update to 6.12.9 from 6.12.8. Immediately after the update I saw on the web Docker tab "Docker Service Failed to Start". I checked the logs and saw a lot of this repeating endlessly: I figured that the update must have done something bad so I tried to downgrade back to 6.12.8, but the issue with Docker unable to start persisted. I don't know what to make of that. Only that the trigger seems to have been the update. After reading up on possible failures I figured perhaps there was a problem with I/O. The cache drive where the appdata is stored and the docker.img is loading from had only around 50% utilization so it wasn't out of space. I didn't see any OOM exceptions. I figured maybe then the docker.img file was corrupt or out of room. I grew the Docker image size from 200GB to 400GB without remembering that I can't reduce it once going up (will have to revisit that later). I mounted the array to start Docker again and got the same error. Next I set the vDisk type from btrfs to xfs and UnRaid created a different filename so the old was remained preserved. I rebooted and found docker could mount and I was able to install apps, but as expected there were no docker custom networks. I shutdown docker and restored the vDisk back to btrfs. From here I figured there must be something to do with networking. I had been using a static IP up until now with static DNS set in UnRaid network config, but I figured maybe I botched that so I had my router setup with a static route for the MAC of the UnRAID eth0 connection and that seems to preserve the need for the static IP. I also had set the box to use VLAN, but never got around to putting that into effect so I disabled that. Starting docker with that change did nothing. I figured then something might be editable with the Docker config itself so I started playing with networking settings from there alone. Turns out that changing this To This was the only necessary hat trick required. I truly don't understand why, because when I started up Docker after that and checked for the docker custom networks listing, "docker network ls", they were all there. A log snippet showed one error, then rode on some degree of success. Its been running happily now for hours, but I think this is a dangerous state to operate in for me since I don't want to lose the custom network settings. A logging snippet of that said success: Mar 30 14:21:15 FakeServerName emhttpd: shcmd (1199): /etc/rc.d/rc.docker start Mar 30 14:21:15 FakeServerName root: starting dockerd ... Mar 30 14:21:15 FakeServerName unraid-api[7190]: ⚠️ Caught exception: connect ECONNREFUSED /var/run/docker.sock Mar 30 14:21:15 FakeServerName unraid-api[7190]: ⚠️ UNRAID API crashed with exit code 1 Mar 30 14:21:15 FakeServerName avahi-daemon[7169]: Service "FakeServerName" (/services/ssh.service) successfully established. Mar 30 14:21:15 FakeServerName avahi-daemon[7169]: Service "FakeServerName" (/services/smb.service) successfully established. Mar 30 14:21:15 FakeServerName avahi-daemon[7169]: Service "FakeServerName" (/services/sftp-ssh.service) successfully established. Mar 30 14:21:21 FakeServerName unraid-api[7697]: ✔️ UNRAID API started successfully! Mar 30 14:21:36 FakeServerName nmbd[7060]: [2024/03/30 14:21:36.755237, 0] ../../source3/nmbd/nmbd_become_lmb.c:398(become_local_master_stage2) Mar 30 14:21:36 FakeServerName nmbd[7060]: ***** Mar 30 14:21:36 FakeServerName nmbd[7060]: Mar 30 14:21:36 FakeServerName nmbd[7060]: Samba name server FakeServerName is now a local master browser for workgroup FAKEWORKGROUP on subnet 10.10.8.130 Mar 30 14:21:36 FakeServerName nmbd[7060]: Mar 30 14:21:36 FakeServerName nmbd[7060]: ***** Mar 30 14:22:01 FakeServerName kernel: docker0: port 1(vethb1f1076) entered blocking state Mar 30 14:22:01 FakeServerName kernel: docker0: port 1(vethb1f1076) entered disabled state Mar 30 14:22:01 FakeServerName kernel: device vethb1f1076 entered promiscuous mode Mar 30 14:22:04 FakeServerName kernel: eth0: renamed from veth71d8bae Mar 30 14:22:04 FakeServerName kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethb1f1076: link becomes ready Mar 30 14:22:04 FakeServerName kernel: docker0: port 1(vethb1f1076) entered blocking state Mar 30 14:22:04 FakeServerName kernel: docker0: port 1(vethb1f1076) entered forwarding state Mar 30 14:22:04 FakeServerName kernel: IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready Mar 30 14:22:09 FakeServerName kernel: br-659b348d1ec9: port 1(veth8cc6977) entered blocking state Mar 30 14:22:09 FakeServerName kernel: br-659b348d1ec9: port 1(veth8cc6977) entered disabled state Mar 30 14:22:09 FakeServerName kernel: device veth8cc6977 entered promiscuous mode Mar 30 14:22:09 FakeServerName kernel: br-659b348d1ec9: port 1(veth8cc6977) entered blocking state Mar 30 14:22:09 FakeServerName kernel: br-659b348d1ec9: port 1(veth8cc6977) entered forwarding state Mar 30 14:22:09 FakeServerName kernel: br-659b348d1ec9: port 1(veth8cc6977) entered disabled state Mar 30 14:22:14 FakeServerName kernel: eth0: renamed from veth90def87 Before I signed off that this was the only setting needed to flip I recreated the blocker with the same UnRAID API crashing behavior just by flipping this back: and just as before flipping it back to No allowed me to bring Docker back online with all those custom networks still readily available. At the first occurrence of success I decided to re-apply the upgrade again back to 6.12.9. I flipped the "Preserve user defined networks" a handful of times because I couldn't believe what I was observing and thought maybe I had done something more significant that I had forgotten, but nope. It was that simple. The logs may be confusing when observing the errors coming and going at the trailing end. (This would be the definition of madness I guess.) Just in case asked, yes, I am using those custom docker networks. They're not vestigial. fakeservername-diagnostics-20240330-1733.zip

I don't think I have a silver bullet solution to your particular problem, but I do believe you can benefit from some trial and error with suggested settings and revisit your current setup if you wish to apply another layer to what you have which might actually solve your issue. So I was getting similar symptoms you described with and I'm not exactly sure what the cause or fix was, but I suspected it had to do with TLS error that was showing itself in the Gitea logs. I don't know what I changed that fixed the problem, but this is what I did along the way so pick at it for details and see if one or more helps you: Settings in Gitea's App.ini need tweaking or triple checking: PROTOCOL must match what you're doing in the reverse proxy DOMAIN, SSH_DOMAIN, and ROOT_URL also must agree with the reverse proxy config I downgraded TLS for now since there was talk about it being a culprit: SSL_MIN_VERSION = TLSv1.0 Also downgraded minimum on Cloudflare to TLSv1.0 which may not be applicable to you. Above and beyond, but set FILE_MAX_SIZE to something high-ish like 512. (located under [repository.upload]) Triple check your reverse proxy config. Adopt SWAG docker container and/or view this mighty fine template and conform it to your environment. Walkthrough the guide from Cloudflare for setting with GitLab. Note the comments at the bottom of that page for dealing with push/pull over SSH. This might be a good use-case for routing it through Cloudflare Zero Trust. Combine the previous guide from Cloudflare with the IBRACORP guide for setting up a Cloudflare Tunnel. NOTE: I found this guide invaluable in getting things setup right.

If the Web UI isn't going to cut it for you then perhaps you can find the better solution being modification of the properties and/or json config files directly. https://minecraft.fandom.com/wiki/Server.properties

Any chance Python can be updated to mainstream 3.11 since it has a ton of speed improvements among other things. Also, Python 3.12 will be available Oct. 2023 with another set of speed improvements so I'll likely request that be targeted as well when that time comes. Thanks for this plugin. I use it with local Docker containers for automatons requiring Python. I may migrate to Automation Studio in the future, but for now I'm loving how this adds value.

Support link to join Discord appears to be broken.

I have impeccable timing! I'm just researching dashboard technologies and wanted to know what made this one tick, but of course its currently in some sort of limbo state. The link way at the bottom was what got me the information I was seeking:

Trouble with multiplayer realms seems to come and go with MC updates with some fixes server side and some client side. Playing local LAN multiplayer is how its done in my house and there hasn't been any noticeable lag with 1.19 as others appear to be reporting. We are keeping view distance at or around 10 which has helped keep some lag noted with the release of 1.18 down, but takes away from enjoyment of exploring across the surface campaigns which we have learned to plan for and temporarily increase viewing distance to at or around 12 during those campaigns taking the punch for lag during that time.

Yay! Wild Update dropped! https://www.minecraft.net/en-us/article/the-wild-update-out-today-java

I saw no response to this and just wanted to point out many years later that there is no Help provided for the Verification tasks section.