-
I get this Issue:
While trying to install a CurseForge Modpack using following Docker Compose: version: '3.6'
services:
minecraft:
container_name: val3
image: itzg/minecraft-server:java8
ports:
- "25566:25565"
environment:
EULA: "TRUE"
VIEW_DISTANCE: "12"
MOTD: "Valhelsia 3 Server"
TYPE: "CURSEFORGE"
VERSION: "1.16.5"
CF_SERVER_MOD: "/modpacks/valhelsia3-server.zip"
CF_BASE_DIR: "/data"
FORCE_REDOWNLOAD: "true"
REMOVE_OLD_MODS: "true"
ENABLE_AUTOPAUSE: "true"
AUTOPAUSE_TIMEOUT_EST: "7200"
AUTOPAUSE_TIMEOUT_KN: "240"
TZ: "Europe/Berlin"
MEMORY: "10G"
USE_AIKAR_FLAGS: "true"
volumes:
- "~/val3/data:/data"
- "~/modpacks:/modpacks"
restart: always |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments
-
I'm afraid that's not something I can fix from the the image. As you've probably the noticed the failure is within the forge installer and is somehow influenced by network connectivity towards their library repo. |
Beta Was this translation helpful? Give feedback.
-
If you don't mind, I can convert this issue to a discussion to see if others have encountered and fixed this scenario. |
Beta Was this translation helpful? Give feedback.
-
Thank you for the Info, changing this into a Discussion seems to be a good Idea. I was able to run the |
Beta Was this translation helpful? Give feedback.
-
Yes, that's what it already does. So, again, the start script provided by the modpack is beyond my control via the image. Modpack scripts are inconsistent and some are broken, so you could also try https://github.com/itzg/docker-minecraft-server#buggy-start-scripts |
Beta Was this translation helpful? Give feedback.
-
This seems to be some other issue as version: '3.6'
services:
minecraft:
container_name: test
image: itzg/minecraft-server
ports:
- "25566:25565"
environment:
EULA: "TRUE"
TYPE: "FORGE"
VERSION: "1.16.5"
FORGEVERSION: "36.2.2"
FORGE_INSTALLER_URL: "https://maven.minecraftforge.net/net/minecraftforge/forge/1.16.5-36.2.2/forge-1.16.5-36.2.2-installer.jar"
TZ: "Europe/Berlin"
MAX_MEMORY: "4G"
INIT_MEMORY: "1G"
volumes:
- "~/test/data:/data"
restart: always BTW: Not specifying the Download URL results in the non functioning URL: https://maven.minecraftforge.net/net/minecraftforge/forge/1.16.5-36.2.2-1.16.5/forge-1.16.5-36.2.2-1.16.5-installer.jar I have experimented around a bit more. But I cant seem to pinpoint the problem. The Out put of the
So this seems to be a Issue with the docker Image? That seems odd. It did not resolve by removing the Image and redownloading. |
Beta Was this translation helpful? Give feedback.
-
Did a lot more digging. I have come to the conclusion this must be somehow related to the container image. @itzg Here is what I have found out so far.
Downloading the minecraft server jar from mojang works fine. version: '3.6'
services:
minecraft:
container_name: test
image: itzg/minecraft-server
ports:
- 25565:25565
environment:
EULA: "true"
volumes:
- "~/test/data:/data"
restart: unless-stopped Running this compose fails to download even the Forge installer even if provided with the correct link. version: '3.6'
services:
minecraft:
container_name: test2
image: itzg/minecraft-server
ports:
- "25565:25565"
environment:
EULA: "TRUE"
TYPE: "FORGE"
VERSION: "1.17.1"
FORGEVERSION: "37.0.48"
FORGE_INSTALLER: "https://maven.minecraftforge.net/net/minecraftforge/forge/1.17.1-37.0.48/forge-1.17.1-37.0.48-installer.jar"
volumes:
- "~/test2/data:/data"
restart: unless-stopped
I am not sure if the fix for this is also the solution for the original problem. But since I have the same Issue on different operating systems it seems to be related to the container. |
Beta Was this translation helpful? Give feedback.
-
OK, I finally figured this Issue out. After playing around with the network-test container a bit more I found a error establishing an ssl connection. Why this was only an issue on some downloads is unclear to me, but it might be related to the package size sent by the server. |
Beta Was this translation helpful? Give feedback.
OK, I finally figured this Issue out.
After playing around with the network-test container a bit more I found a error establishing an ssl connection.
This lead me to an article regarding the network mtu. https://mlohr.com/docker-mtu/
And this was the problem causing all the issues.
So what might have caused the issue is that the server provider changed the mtu on the physical link in the datacenter and this caused the issue with docker. Docker does not set the mtu of its bridge networks according to the mtu of the actual link.
Setting this manually according to the linked article solved the connectivity issues.
Why this was only an issue on some downloads is unclear to me, but it might be…