Default configs downloading for paper {Broken Repo?}

[softcrunch]

Has anyone run into the issue when starting a paper server on the latest version, that the default configs repo is broken?

I have the configs already copied to the /data/config directory in the container but it still tries to download the defaults.
I assume i have some configuration wrong as I assume that it would skip the default configs if it detected they were already present?
It looks like the download retries a few times before throwing the error and this causes the server to take around 5 minutes to start!

Any assistance would be appreciated as Im not sure what i've done wrong. Thank you!

[init] [WARN] One or more default config files were not available from https://raw.githubusercontent.com/dayyeeet/minecraft-default-configs/main/1.21.7/paper-global.yml,https://raw.githubusercontent.com/dayyeeet/minecraft-default-configs/main/1.21.7/paper-world-defaults.yml

[init] [WARN] One or more default files were not available from https://raw.githubusercontent.com/dayyeeet/minecraft-default-configs/main/1.21.7/bukkit.yml,https://raw.githubusercontent.com/dayyeeet/minecraft-default-configs/main/1.21.7/spigot.yml

[root@DockerHost lucyvanilla]# cd config/
[root@DockerHost config]# ls
paper-global.yml paper-world-defaults.yml spigot.yml

[root@DockerHost config]# cd ~/lucyvanilla/data/config
[root@DockerHost config]# ls
paper-global.yml paper-world-defaults.yml spigot.yml

docker-compose.yml

services:
mc:
image: itzg/minecraft-server:latest
container_name: lucyvanilla
tty: "true"
stdin_open: "true"
ports:
- "25566:25565" # Java port
- "19132:19132/udp" # Bedrock port (Geyser)
- "8123:8123" # Dynmap
environment:
EULA: "TRUE"
TYPE: "PAPER"
MEMORY: "16384M"

  # Crossplay options
  ENABLE_GEYSER: "true"
  ENABLE_FLOODGATE: "true"

volumes:
  - ./data:/data
  - ./plugins:/data/plugins
  - ./config:/config
restart: unless-stopped

volumes:
data: {}

[itzg]

Thanks for reporting this, but you can ignore those warnings. No, it won't overwrite a file that you already put there. Also, it does the defaults processing after the config mount, so it also won't overwrite files you provide that way.

[softcrunch]

Thank you for the quick reply! I was more concerned with the server load times due to the retry attempts of the download, i might make a host file entry to redirect that specific url.

[itzg]

I'm not sure what you mean about any impact on server load time and retries. It probably takes 100ms or less for the call to check GitHub for the file. And it doesn't retry except once at each startup...unless you're seeing logs that say it's retrying?

[softcrunch]

My apologies, I was making an assumption based on the time between the message for downloading default configs and the one or more files were not available warning.

If it's not set to retry and should only check once, maybe its a time-out on my side, I will curl from my server and see what result I get. My desktop can access the url and receive the http 404 error, so I assumed the server was retrying the url multiple times before moving on.

No need to waste any more of your time on this! Thanks for the help so far.

[itzg]

I assumed the server was retrying the url multiple times before moving on.

I'm quite certain it's not retrying 😄

In any case, the next image will provide more sensible logging to indicate when a default config is actually being downloaded and quietly move on otherwise.

[softcrunch]

I figured out the issue and it was my own fault. I have geo blocking in place and this was stopping the traffic outbound, however this wasnt explaining the long time attempting to download the configs...

2025-07-06 14:19:49 id=20085 trace_id=613 func=print_pkt_detail line=5529 msg="vd-root received a packet(proto=6, 192.168.0.149:45422->185.199.108.133:443) from internal. flag [S], seq 1801989311, ack 0, win 29200"
2025-07-06 14:19:49 id=20085 trace_id=613 func=init_ip_session_common line=5693 msg="allocate a new session-01743ef1"
2025-07-06 14:19:49 id=20085 trace_id=613 func=vf_ip4_route_input line=1604 msg="find a route: flags=00000000 gw-220.233.1.17 via ppp1"
2025-07-06 14:19:49 id=20085 trace_id=613 func=fw_forward_handler line=601 msg="Denied by forward policy check (policy 14)"

It turns out that it was rotating through the IP addresses resolved by DNS before failing.

Non-authoritative answer:
Name: raw.githubusercontent.com
Address: 185.199.109.133
Name: raw.githubusercontent.com
Address: 185.199.110.133
Name: raw.githubusercontent.com
Address: 185.199.108.133
Name: raw.githubusercontent.com
Address: 185.199.111.133

Due to the way TCP functions, no reply being received, a TCP retransmission occurs and repeats a few times. When there is no firewalling in place, it receives the 404 and fails instantly.

Sorry for not doing my due diligence first!