foundryvtt-docker: Unable to install modules

Bug description

I get the following error in the console when I try to install a module: FoundryVTT | 2023-01-11 12:30:14 | [warn] The requested manifest at "https://bitbucket.org/rpgframework-cloud/shadowrun6-eden/downloads/system-staging.json" did not provide system manifest data.

Steps to reproduce

This happens if I select install from the following dialogue:

Expected behavior

I expect that the module will install successfully.

Container metadata

com.foundryvtt.version = "10.291"
org.opencontainers.image.authors = "markf+github@geekpad.com"
org.opencontainers.image.created = "2022-12-02T23:36:29.879Z"
org.opencontainers.image.description = "An easy-to-deploy Dockerized Foundry Virtual Tabletop server."
org.opencontainers.image.licenses = "MIT"
org.opencontainers.image.revision = "bf4e42e9570aab7e8de39d7f760cb5f16e19862e"
org.opencontainers.image.source = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.title = "foundryvtt-docker"
org.opencontainers.image.url = "https://github.com/felddy/foundryvtt-docker"
org.opencontainers.image.vendor = "Geekpad"
org.opencontainers.image.version = "10.291.0"

Relevant log output

Entrypoint | 2023-01-11 18:57:06 | [info] Foundry Virtual Tabletop 10.291 is installed.
Entrypoint | 2023-01-11 18:57:06 | [info] Not modifying existing installation license key.
Entrypoint | 2023-01-11 18:57:06 | [info] Setting data directory permissions.
Entrypoint | 2023-01-11 18:57:06 | [debug] Completed setting directory permissions.
Entrypoint | 2023-01-11 18:57:06 | [info] Starting launcher with uid:gid as foundry:foundry.
Launcher | 2023-01-11 18:57:06 | [debug] Ensuring /data/Config directory exists.
Launcher | 2023-01-11 18:57:06 | [info] Generating options.json file.
Launcher | 2023-01-11 18:57:07 | [info] Setting 'Admin Access Key'.
Launcher | 2023-01-11 18:57:07 | [info] Starting Foundry Virtual Tabletop.
FoundryVTT | 2023-01-11 11:57:07 | [info] Running on Node.js - Version 16.18.1
FoundryVTT | 2023-01-11 11:57:07 | [info] Foundry Virtual Tabletop - Version 10 Build 291
FoundryVTT | 2023-01-11 11:57:07 | [info] User Data Directory - "/data"
FoundryVTT | 2023-01-11 11:57:07 | [info] Application Options:
{
  "awsConfig": null,
  "compressStatic": true,
  "fullscreen": false,
  "hostname": null,
  "language": "en.core",
  "localHostname": null,
  "passwordSalt": null,
  "port": 30000,
  "protocol": null,
  "proxyPort": null,
  "proxySSL": false,
  "routePrefix": null,
  "sslCert": null,
  "sslKey": null,
  "updateChannel": "stable",
  "upnp": false,
  "upnpLeaseDuration": null,
  "world": null,
  "adminPassword": "••••••••••••••••",
  "serviceConfig": null
}
FoundryVTT | 2023-01-11 11:57:07 | [info] Software license verification succeeded
FoundryVTT | 2023-01-11 11:57:07 | [info] Server started and listening on port 30000
FoundryVTT | 2023-01-11 11:57:12 | [warn] Could not reach IP discovery service
FoundryVTT | 2023-01-11 11:57:36 | [info] Created client session 2381f78ce0f7e9cfec306dba
FoundryVTT | 2023-01-11 11:57:39 | [info] Created client session 90bf245526d5a6a41e48bd3e
FoundryVTT | 2023-01-11 11:57:44 | [info] Administrator authentication successful for session 90bf245526d5a6a41e48bd3e
FoundryVTT | 2023-01-11 11:58:14 | [warn] The requested manifest at "https://bitbucket.org/rpgframework-cloud/shadowrun6-eden/downloads/system-staging.json" did not provide system manifest data.
Entrypoint | 2023-01-11 19:18:06 | [debug] Timezone set to: UTC
Entrypoint | 2023-01-11 19:18:06 | [info] Starting felddy/foundryvtt container v10.291.0
Entrypoint | 2023-01-11 19:18:06 | [debug] CONTAINER_VERBOSE set.  Debug logging enabled.
Entrypoint | 2023-01-11 19:18:06 | [info] Foundry Virtual Tabletop 10.291 is installed.
Entrypoint | 2023-01-11 19:18:06 | [info] Not modifying existing installation license key.
Entrypoint | 2023-01-11 19:18:06 | [info] Setting data directory permissions.
Entrypoint | 2023-01-11 19:18:06 | [debug] Completed setting directory permissions.
Entrypoint | 2023-01-11 19:18:06 | [info] Starting launcher with uid:gid as foundry:foundry.
Launcher | 2023-01-11 19:18:06 | [debug] Ensuring /data/Config directory exists.
Launcher | 2023-01-11 19:18:06 | [info] Generating options.json file.
Launcher | 2023-01-11 19:18:06 | [info] Setting 'Admin Access Key'.
Launcher | 2023-01-11 19:18:06 | [info] Starting Foundry Virtual Tabletop.
FoundryVTT | 2023-01-11 12:18:07 | [info] Running on Node.js - Version 16.18.1
FoundryVTT | 2023-01-11 12:18:07 | [info] Foundry Virtual Tabletop - Version 10 Build 291
FoundryVTT | 2023-01-11 12:18:07 | [info] User Data Directory - "/data"
FoundryVTT | 2023-01-11 12:18:07 | [info] Application Options:
{
  "awsConfig": null,
  "compressStatic": true,
  "fullscreen": false,
  "hostname": null,
  "language": "en.core",
  "localHostname": null,
  "passwordSalt": null,
  "port": 30000,
  "protocol": null,
  "proxyPort": null,
  "proxySSL": false,
  "routePrefix": null,
  "sslCert": null,
  "sslKey": null,
  "updateChannel": "stable",
  "upnp": false,
  "upnpLeaseDuration": null,
  "world": null,
  "adminPassword": "••••••••••••••••",
  "serviceConfig": null
}
FoundryVTT | 2023-01-11 12:18:07 | [info] Software license verification succeeded
FoundryVTT | 2023-01-11 12:18:07 | [info] Server started and listening on port 30000
FoundryVTT | 2023-01-11 12:18:12 | [warn] Could not reach IP discovery service
FoundryVTT | 2023-01-11 12:18:36 | [info] Created client session a83a0978d8bf52cad551fe0c
FoundryVTT | 2023-01-11 12:26:34 | [info] Created client session 9fcb16e221a7666cb7168f8c
FoundryVTT | 2023-01-11 12:26:34 | [info] Created client session ace04160ba3a369dd643471f
FoundryVTT | 2023-01-11 12:26:36 | [info] Administrator authentication successful for session ace04160ba3a369dd643471f
FoundryVTT | 2023-01-11 12:27:03 | [warn] The requested manifest at "https://bitbucket.org/rpgframework-cloud/shadowrun6-eden/downloads/system-staging.json" did not provide system manifest data.
FoundryVTT | 2023-01-11 12:29:54 | [warn] The requested manifest at "https://bitbucket.org/rpgframework-cloud/shadowrun6-eden/src/master/system-template.json" did not provide system manifest data.
FoundryVTT | 2023-01-11 12:30:14 | [warn] The requested manifest at "https://bitbucket.org/rpgframework-cloud/shadowrun6-eden/downloads/system-staging.json" did not provide system manifest data.

Code of Conduct

I agree to follow this project’s Code of Conduct

About this issue

Original URL
State: closed
Created a year ago
Comments: 39 (4 by maintainers)

Most upvoted comments

Had the same issue with modules not installing due to timeouts ultimately related to a complicated docker bridge (and local pihole) network configuration.

An alternative simple work around that I ended up using is to add a --dns 1.1.1.1 parameter (or any other public DNS server) to have the container use public DNS server explicitly. Curl timing test went from around ~8s to ~.4s Thanks for the lead and discussion! 🎉

Spartanaco on Mar 2, 2023

This solution seems to be working for me: https://forums.docker.com/t/dns-issues-with-local-resolver-and-containers-on-the-same-host/102319

Advantage:

No changes to other containers
No changes to your networks

Disadvantage:

Have to hard code the host IP address for your DNS container

In my case the host IP address is static, so I can get away with this configuration.

Although, to be honest, I’m not really sure why that works.

BeardedGnome on Feb 24, 2023

I fixed it in my setup. It was the default docker MTU that was at fault.

By default the docker daemon has an MTU of 1500. However many network cards can have an MTU of less, and even if you have an MTU of 1500 on your main outside facing network interface on the host machine, some things like a VPN connecting, lower the effective MTU to something like 1420 (which was the case for me).

That means that packets that come from any docker container using the bridge network with its higher MTU have to be fragmented or result in fragmented return packages. These are often dropped by firewalls, resulting in the timeouts we see here. Services running directly of the host or containers using host networking are aware of the lowered MTU and thus work without problems.

So why would this only happen in compose for some? My best guess is that your default docker daeomon MTU is actually adjusted accordingly, but docker compose creates new default bridge networks for every service it starts and it doesn’t use the daeomon’s MTU parameter but defaults to a hardcoded 1500. This has to be adjusted for each compose network individually (or you create one overarching adjusted compose bridge and connect new containers to it instead of using a default network).

Below is a tutorial that explains the way how to adjust the MTUs for docker. You can check if it worked with “netstat -i” (please note that the docker0 interface shows MTU 1500 always, and only changes in netstat to your configured MTU when a container is connected to it).

https://www.civo.com/learn/fixing-networking-for-docker

DerLeole on Feb 21, 2023

Hey @felddy, just wanted to update once more and let you know I’ve confirmed the above. Last night I performed the following test:

Access docker container that was created via docker-compose
Attempt to install several modules that have failed consistently
Each attempt is met with same failure as seen previously
Executed “sudo docker-compose down” to stop and remove container
Created new container in Synology Docker GUI using the exact same configurations from the docker-compose.yaml file
Note: I also pointed the new container to the same existing directory
New container came up with all of the previous configurations and installations in place
Attempted to then install same modules that had just failed and each installed without issue.

At this point it seems abundantly clear that there is some sort of variance under the hood in how these deployment methods are working.

To try to help, I’ve exported the configuration from the GUI and am attaching it and the docker-compose.yaml files here. docker_files.zip

salsabeard on Jan 19, 2023

I saw a lot of those comments as well, but I don’t think this is GitHub rate limiting for two reasons:

Some GitHub downloads work consistently while others fail. Working installations can be added from GitHub repeatedly and work every time, while others fail consistently every time.
I appear to only experience these issues when deploying via docker-compose. If I create the container from the Docker GUI on my Synology, the same installs will work. I can literally run both containers simultaneously and it will work on the GUI deployed container and fail on the DC deployed container.

salsabeard on Jan 19, 2023

I’m not sure if it’s possible, but I think we should re-open this. I am seeing this same issue when trying to install MANY systems, modules, and add-ons. One specifically that can be tested with is the Blade Runner RPG: https://github.com/fvtt-fria-ligan/blade-runner-foundry-vtt

The reason that I suggest reopening this issue is that when I was initially configuring my docker instance, I did so through the Synology Docker GUI tool. Once the container was up and running, I added that specific system and it worked just fine. I ran through my tests and then killed the container and reconfigured using docker-compose. I got it up and online and all seemed to be working, but that’s when I noticed that I’ve barely been able to add any systems at all. But that’s not to say none will work.

So far I’ve had no issues installing Cyberpunk Red, FATE, and Starfinder, but Blade Runner, DnD5e, and Call of Cthullu have all failed with similar to the following console output seen:

setup.js:292 Error: Unable to load valid system manifest data from “https://github.com/fvtt-fria-ligan/blade-runner-foundry-vtt/releases/download/10.0.2/system.json” The requested manifest at “https://github.com/fvtt-fria-ligan/blade-runner-foundry-vtt/releases/download/10.0.2/system.json” did not provide system manifest data. at Module.installPackage (file:///home/foundry/resources/app/dist/packages/views.mjs:1:1634) at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:96:5) at async SetupView.handlePost (file:///home/foundry/resources/app/dist/server/views/setup.mjs:1:1980)

salsabeard on Jan 14, 2023