How to cache a FoundryVTT release so it doesn't need to redownload

[MicahZoltu]

🐛 Bug Report

I installed using FOUNDRY_RELEASE_URL which worked the first time, but when I restarted the container it tried to download again but the URL was no longer valid. I have a volume mount for /data, but no other volume mount, so it isn't surprising that the actual install wasn't retained.

To Reproduce

1. Run with FOUNDRY_RELEASE_URL and /data mounted.
2. Wait for the URL to expire.
3. Restart the container.
4. Notice that it says No Foundry Virtual Tabletop installation detected. and tries to download/install again.
5. Notice you get a 403.

Expected behavior

The download and install are saved to a volume so I don't have to re-download and re-install every run.

---

This may just be a documentation issue. Should I be mounting another volume besides /data?

[MicahZoltu]

Note: Reinstalling also requires me to accept license key again and configure admin password again.

[felddy]

If you recreate the container the Docker image needs to reinstall the FoundryVTT distribution. The installation of Foundry does not persist by design. Since you used the FOUNDRY_RELEASE_URL method, you'll have to provide a fresh link.

If you want to avoid this hassle you can do a few different things. First, I'd use the CONTAINER_CACHE environment variable to store the downloaded release somewhere in your /data volume. I use /data/container_cache. Once you have the release tarball cached you can remove theFOUNDRY_RELEASE_URL. The container will use the tarball to install.

If you want to avoid enabling and disabling the FOUNDRY_RELEASE_URL you can pass your credentials either with secrets or environment variables so the container can fetch a fresh URL and license key itself.

I should probably make this clearer in the README by adding a list of the pros and cons for each approach.

As for the EULA, you shouldn't need to re-accept it unless you move to a new version. (e.g.; 0.7.9 -> 0.8.0). This could be a sign that your /data volume is not persisting.

For the Admin password: You'll need to set it with the FOUNDRY_ADMIN_KEY or the associated secret. The admin.txt file is recreated by the container at each startup. Alternatively you can set CONTAINER_PRESERVE_CONFIG to true to prevent this behavior.

Let me know if this makes sense or if I can provide any more clarity.

[MicahZoltu]

As for the EULA, you shouldn't need to re-accept it unless you move to a new version. (e.g.; 0.7.9 -> 0.8.0). This could be a sign that your /data volume is not persisting.

The data volume did persist, as I retained my modules, worlds, etc.

[felddy]

That is good news.

I know what the likely cause is then... if you're not setting the container's hostname then Docker is generating a new random one each time. The EULA signature is tied to the hostname. You'll need to set the hostname to a static value. The example docker-compose.yml file in the README.md has an example of this.

[MicahZoltu]

I tried your suggestion of using CONTAINER_CACHE. I first ran with FOUNDRY_RELEASE_URL and CONTAINER_CACHE set, which successfully worked. I then removed the FOUNDRY_RELEASE_URL and restarted the server but it failed to launch at a later point:

Entrypoint | 2021-02-21 01:56:10 | [info] Using CONTAINER_CACHE: /data/container_cache
Entrypoint | 2021-02-21 01:56:10 | [info] Installing Foundry Virtual Tabletop 0.7.9
Entrypoint | 2021-02-21 01:56:12 | [info] Preserving release archive file in cache.
Entrypoint | 2021-02-21 01:56:12 | [info] Not modifying existing installation license key.
Entrypoint | 2021-02-21 01:56:12 | [info] Setting data directory permissions.
Entrypoint | 2021-02-21 01:56:12 | [info] Starting launcher with uid:gid as foundry:foundry.
Launcher | 2021-02-21 01:56:12 | [info] Generating options.json file.
Launcher | 2021-02-21 01:56:12 | [info] Setting 'Admin Access Key'.
Launcher | 2021-02-21 01:56:12 | [info] Starting Foundry Virtual Tabletop.
FoundryVTT | 2021-02-21 01:56:13 | [error] A fatal error occurred while trying to start the Foundry Virtual Tabletop server
FoundryVTT | 2021-02-21 01:56:13 | [error] Foundry VTT cannot start in this directory which is already locked by another process.
Error: Foundry VTT cannot start in this directory which is already locked by another process.
    at _acquireLockFile (/home/foundry/resources/app/dist/init.js:1:7978)
    at async _initializeCriticalFunctions (/home/foundry/resources/app/dist/init.js:1:5151)
    at async initialize (/home/foundry/resources/app/dist/init.js:1:3572)

[MicahZoltu]

Worth noting, that after one more restarts it appears to have worked.