[Support] silman - Foundry Virtual Tabletop (felddy docker image)

[silman]

Support for FoundryVTT docker that uses felddy's docker hub image (much more robust than the current existing one provided by fithwum)

 

Application: FoundryVTT

Application Site: https://foundryvtt.com/

Docker Hub: https://github.com/felddy/foundryvtt-docker

Github: https://github.com/felddy/foundryvtt-docker

 

Please post any questions/issues relating to this docker in this thread and i will try and help.

Edited June 22, 2022 by silman

[silman]

Here is an example image of how to set it up using the USERNAME/PASSWORD method.

 

When using this method you do not need to specify a license key ever as it will be pulled from your account.

 

Note that with this method you really should specify a specific version, otherwise on container restarts it may automatically download the latest one, causing you to upgrade accidentally. While upgrading isn't usually an issue Foundry is still in very active development and upgrading to a new major version could break stuff.

 

The version specification method is very robust, you can specify just the major version (e.g., 9) and on container restart it will upgrade to the most recent 9.x.x version; you can speficy just the major and minor (e.g., 9.255) and on container restart it will upgrade to the most recent 9.255.x version; or you can specify an exact version (e.g., 9.255.0) and it will always use this one.

 

Specifying the directory to use for the container cache will make it re-use a previously downloaded copy, which will speed up container start. Make sure the directory is inside the persistent volume you map for the Game Data (e.g., /data/container_cache).

 

 

 

NOTE: Ignore the fact that i'm using /mnt/user/appstorage/ instead of the standard /mnt/user/appdata, it's for testing purposes. Also ignore the port is 30003 here but maps to 30000 internally. This is because i already had a service on external port 30000.

Edited March 13, 2022 by silman

[silman]

Here is an example of how to use the timed URL, you can use this in conjunction with the container cache so that when the timed-URL expires you still have the copy to use. 

 

You may specify a license key or enter one upon first startup of the container.

 

 

[silman]

The last method you can do is simply download the .zip of the Linux/NodeJS installation of Foundry and put it in the location of the container_cache variable. Then you do not need to use the timed-URL or the USERNAME/PASSWORD method.

 

This is much more manual and if you don't want to use the USERNAME/PASSWORD method it's still probably easier to use timed-URL in conjunction with the container_cache since it will automatically download it for you. Remember to fill out the FOUNDRY_VERSION when using CONTAINER_CACHE with the automatic download method as it will append that variable to the zip it downloads (NOTE: It does not check that the time-based download URL matches the version that you specify in FOUNDRY_VERSION, so make sure you get it right. If using USERNAME/PASSWORD it will use this variable to download the correct version).

 

The docker container will create the container cache directory if it doesnt exist, you can then copy files into it or let it download files into it for you.

 

Two things to note:

1) the user and group for the container_cache dir and all files inside must be set to 421(the id the container uses); you can run chown -R 421:421 <container_cache_dir> to set this if you created this directory yourself.

2) the release zips inside must be all lowercase format foundryvtt-x.xxx.zip where x.xxx is the major and minor versions.

Edited March 14, 2022 by silman

[d3fc0n0wltraps]

Hello!

 

I would love to tryout a new Foundry container but I'm running into an issue trying to get it running for the first time. At the moment I have a copy of the Linux/NodeJS installer of 9.238 so for simplicity sake I have set the version to that and added it into the container-cache which is mapped using your default recommended value, but it can't seem to locate that installer.

• Game Data Path is mapped to /mnt/user/AppData/Foundry/
• FOUNDRY_VERSION is set for 9.238
• CONTAINER_CACHE is set for  /data/container_cache

It definitely knows where it should look, and what version .zip it should be looking for, and that file definitely exists:

 

Here is the log traffic on start:

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [debug] Timezone set to: America/New_York

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [info] Starting felddy/foundryvtt container v9.255.0

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [debug] CONTAINER_VERBOSE set. Debug logging enabled.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [warn] FOUNDRY_VERSION has been manually set and does not match the container's version.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [warn] Expected 9.255 but found 9.238

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [warn] The container may not function properly with this version mismatch.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [info] No Foundry Virtual Tabletop installation detected.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [info] Using CONTAINER_CACHE: /data/container_cache

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Unable to install Foundry Virtual Tabletop!

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Either set FOUNDRY_RELEASE_URL.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Or set FOUNDRY_USERNAME and FOUNDRY_PASSWORD.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Or set CONTAINER_CACHE to a directory containing foundryvtt-9.238.zip

today at 5:02:54 PMContainer stopped

 

Am I doing something wrong or do you have any suggestions for starting a server from a pre-existing, older zip? Honestly I can't think of much reason to use an older installer (save for version-locking for module compatibility) but it would be convenient. 

[silman]

19 minutes ago, d3fc0n0wltraps said:

Hello!

 

I would love to tryout a new Foundry container but I'm running into an issue trying to get it running for the first time. At the moment I have a copy of the Linux/NodeJS installer of 9.238 so for simplicity sake I have set the version to that and added it into the container-cache which is mapped using your default recommended value, but it can't seem to locate that installer.

• Game Data Path is mapped to /mnt/user/AppData/Foundry/
• FOUNDRY_VERSION is set for 9.238
• CONTAINER_CACHE is set for  /data/container_cache

It definitely knows where it should look, and what version .zip it should be looking for, and that file definitely exists:

 

Here is the log traffic on start:

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [debug] Timezone set to: America/New_York

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [info] Starting felddy/foundryvtt container v9.255.0

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [debug] CONTAINER_VERBOSE set. Debug logging enabled.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [warn] FOUNDRY_VERSION has been manually set and does not match the container's version.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [warn] Expected 9.255 but found 9.238

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [warn] The container may not function properly with this version mismatch.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [info] No Foundry Virtual Tabletop installation detected.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [info] Using CONTAINER_CACHE: /data/container_cache

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Unable to install Foundry Virtual Tabletop!

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Either set FOUNDRY_RELEASE_URL.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Or set FOUNDRY_USERNAME and FOUNDRY_PASSWORD.

today at 4:58:35 PMEntrypoint | 2022-03-14 16:58:35 | [error] Or set CONTAINER_CACHE to a directory containing foundryvtt-9.238.zip

today at 5:02:54 PMContainer stopped

 

Am I doing something wrong or do you have any suggestions for starting a server from a pre-existing, older zip? Honestly I can't think of much reason to use an older installer (save for version-locking for module compatibility) but it would be convenient. 

Hi d3fc0n0wltraps,

 

That is super weird. I definitely tested this scenario (in fact i used 9.238 when i tested it!).

 

One thing you can try is to set the container tag to the version you want so instead of `felddy/foundryvtt:release`  you can try `felddy/foundryvtt:9.238` which will force it to always use that version, but you should not have to if you are using the container cache method. I was able to have the 9.238 zip in the container cache just like you did with the `release` tag and it worked fine.

 

I can imagine if the zip permissions aren't set right maybe the container can't access it? But i'm not sure, what permissions are set for the container_cache folder and the zip inside it? I actually had the container download the 9.238 version for me using USERNAME/PASSWORD method and then re-used it after deleting the username and password from the template to check that it was using that zip. So maybe the permissions set by it downloading it for me makes the difference?

 

Can you go to into the advanced settings for the template and change the `CONTAINER_VERBOSE` variable to true so we can take a deeper look at the logs.

Edited March 14, 2022 by silman

[d3fc0n0wltraps]

2 minutes ago, silman said:

Hi d3fc0n0wltraps,

 

That is super weird. I definitely tested this scenario (in fact i used 9.238 when i tested it!).

 

One thing you can try is to set the container tag to the version you want so instead of `felddy/foundryvtt:release`  you can try `felddy/foundryvtt:9.238` which will force it to always use that version, but you should not have to if you are using the container cache method.

 

I can imagine if the zip permissions aren't set right maybe the container can't access it? But i'm not sure, what permissions are set for the container_cache folder and the zip inside it?

 

Can you go to into the advanced settings for the template and change the `CONTAINER_VERBOSE` variable to true so we can take a deeper look at the logs.

 

Happy to! Thanks for the assist and rapid reply. Log traffic doesn't seem too dissimilar, save for no longer notifying about the version mismatch (for obvious reason)

 

Entrypoint | 2022-03-14 17:26:28 | [[34mdebug[0m] Timezone set to: America/New_York
Entrypoint | 2022-03-14 17:26:28 | [[32minfo[0m] Starting felddy/foundryvtt container v9.238.0
Entrypoint | 2022-03-14 17:26:28 | [[34mdebug[0m] CONTAINER_VERBOSE set. Debug logging enabled.
Entrypoint | 2022-03-14 17:26:28 | [[32minfo[0m] No Foundry Virtual Tabletop installation detected.
Entrypoint | 2022-03-14 17:26:28 | [[32minfo[0m] Using CONTAINER_CACHE: /data/container_cache
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Unable to install Foundry Virtual Tabletop!
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Either set set FOUNDRY_RELEASE_URL.
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Or set FOUNDRY_USERNAME and FOUNDRY_PASSWORD.
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Or set CONTAINER_CACHE to a directory containing foundryvtt-9.238.zip

 

I have also tried this with a 9.255 zip (the person I host the server for was able to get it to me) and I see identical behavior (after setting the appropriate variables and tags back to 9.255.)

 

I'm going to admit ignorance here and just paste the result of ls -l, as file permissions in Linux are.... not my strong suit. Is there a way I can be more helpful/informative?

 

root@Tower:/mnt/user/AppData# ls -l Foundry
total 0
drwxrwxrwx 1 root root 80 Mar 14 17:13 container_cache/

 

root@Tower:/mnt/user/AppData/Foundry# ls -l container_cache/
total 379264
-rw-rw-rw- 1 d3fc0 users 193850047 Mar 14 17:02 FoundryVTT-9.255.zip
-rw-rw-rw- 1 d3fc0 users 194511363 Dec 27 11:59 foundryvtt-9.238.zip

[silman]

5 minutes ago, d3fc0n0wltraps said:

 

Happy to! Thanks for the assist and rapid reply. Log traffic doesn't seem too dissimilar, save for no longer notifying about the version mismatch (for obvious reason)

 

Entrypoint | 2022-03-14 17:26:28 | [[34mdebug[0m] Timezone set to: America/New_York
Entrypoint | 2022-03-14 17:26:28 | [[32minfo[0m] Starting felddy/foundryvtt container v9.238.0
Entrypoint | 2022-03-14 17:26:28 | [[34mdebug[0m] CONTAINER_VERBOSE set. Debug logging enabled.
Entrypoint | 2022-03-14 17:26:28 | [[32minfo[0m] No Foundry Virtual Tabletop installation detected.
Entrypoint | 2022-03-14 17:26:28 | [[32minfo[0m] Using CONTAINER_CACHE: /data/container_cache
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Unable to install Foundry Virtual Tabletop!
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Either set set FOUNDRY_RELEASE_URL.
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Or set FOUNDRY_USERNAME and FOUNDRY_PASSWORD.
Entrypoint | 2022-03-14 17:26:28 | [[31merror[0m] Or set CONTAINER_CACHE to a directory containing foundryvtt-9.238.zip

 

I have also tried this with a 9.255 zip (the person I host the server for was able to get it to me) and I see identical behavior (after setting the appropriate variables and tags back to 9.255.)

 

I'm going to admit ignorance here and just paste the result of ls -l, as file permissions in Linux are.... not my strong suit. Is there a way I can be more helpful/informative?

 

root@Tower:/mnt/user/AppData# ls -l Foundry
total 0
drwxrwxrwx 1 root root 80 Mar 14 17:13 container_cache/

 

root@Tower:/mnt/user/AppData/Foundry# ls -l container_cache/
total 379264
-rw-rw-rw- 1 d3fc0 users 193850047 Mar 14 17:02 FoundryVTT-9.255.zip
-rw-rw-rw- 1 d3fc0 users 194511363 Dec 27 11:59 foundryvtt-9.238.zip

 

hmm yeah i can't tell anything obviously wrong with that, i'm not able to access my server right now so i can't compare what my permissions are. 

 

One thing i can suggest is to move those pre-downloaded zips somewhere else, then ask the person who has the Foundry key to generate a timed-URL, copy that into RELEASE_URL and keep CONTAINER_CACHE set, make sure to set FOUNDRY_VERSION to the version of the release that the timed-URL was generated from. Then start up the container (before the timed URL expires) and let it download it for you, then you can go into the container_cache directory and see what the permissions are for it. My guess is that the user and group IDs will be different.

 

Just something to try, i know it's not nearly as convenient as copying in a pre-existing ZIP that you had on hand but maybe if we figure out what the container is doing we can mimic it.

[d3fc0n0wltraps]

1 hour ago, silman said:

 

hmm yeah i can't tell anything obviously wrong with that, i'm not able to access my server right now so i can't compare what my permissions are. 

 

One thing i can suggest is to move those pre-downloaded zips somewhere else, then ask the person who has the Foundry key to generate a timed-URL, copy that into RELEASE_URL and keep CONTAINER_CACHE set, make sure to set FOUNDRY_VERSION to the version of the release that the timed-URL was generated from. Then start up the container (before the timed URL expires) and let it download it for you, then you can go into the container_cache directory and see what the permissions are for it. My guess is that the user and group IDs will be different.

 

Just something to try, i know it's not nearly as convenient as copying in a pre-existing ZIP that you had on hand but maybe if we figure out what the container is doing we can mimic it.

 

Thanks for the suggestion. I'll try that and update as I can.

 

Edited to add - looks resolved.

 

I noticed in your entrypoint.sh that it creates the container_cache folder if none exists. Previously I had created it and loaded the files into it.

 

When your script creates it, it sets:

root@Tower:/mnt/user/AppData/Foundry# ls -ld container_cache/
drwxr-xr-x 1 421 421 40 Mar 14 19:17 container_cache//

 

So, I removed my container_cache folder, started it (let it fail), then moved the zip into it and started it again.

 

And it starts up fine now. So, lesson learned.

Edited March 14, 2022 by d3fc0n0wltraps
preventing doublepost

[silman]

Great to see it was resolved! I will add this to the third post about container cache.

 

I just got home and started testing it. I found two things:

1) the user and group for the container_cache dir and all files inside must be set to 421 (the id the container uses);  you can run chown -R 421:421 container_cache

2) the file must be all lowercase format foundryvtt-x.xxx.zip

 

I will add this to the third post about the container cache method.\

 

Thanks for bringing this to my attention!

Edited March 14, 2022 by silman

[d3fc0n0wltraps]

12 minutes ago, silman said:

Great to see it was resolved! I will add this to the third post about container cache.

 

I just got home and started testing it. I found two things:

1) the user and group for the container_cache dir and all files inside must be set to 421 (the id the container uses);  you can run chown -R 421:421 container_cache

2) the file must be all lowercase format foundryvtt-x.xxx.zip

 

I will add this to the third post about the container cache method.\

 

Thanks for bringing this to my attention!

 

You're too fast! I was just coming back to the thread to say, testing it up to 9.255 that it is case sensitive on the zip. Thanks again for your work on this and the support!

[Wolbaz]

What is the benefit to switching to this container over the existing FoundryVTT container?

[silman]

6 hours ago, Wolbaz said:

What is the benefit to switching to this container over the existing FoundryVTT container?

The fithwum one is very basic and very manual. You have to install/unzip the foundry version yourself into the appdata. Moreover it does not handle the options lock file very well and i found many times where it got stuck with a world loaded if i didnt return to setup before shutting down the container. This container avoids that by not storing those files (unless you tell it to preserve them), it's much more robust all around in my experience - having used the fithum container for the past few months and now this one very recently.

 

This container has multiple methods to automatically download a specific or latest version (using either username/password auth or a time based release URL) and can cache the download for you so container restarts don't need to redownload, it lets you configure the admin password and license key from the template, it let's you configure the containers GID and UID, the local and remote host names so the in-app join link is correct, it lets you set the default language for the foundry app, it lets you can configure proxy settings, and provide custom SSL certs if you want, lets you minify the javascript or disable minification for module development, lets you configure Universal Plug and Play, automatically launch a specified world, and lastly let's you provide it scripts (from a list of URLs and/or local scripts) to run after boot-up (This is particularly useful for those who use a certain radioactive module, as there are scripts out there to automatically install it and change the necessary javascript file in the app).

 

Feel free to learn more here: https://github.com/felddy/foundryvtt-docker

[Wolbaz]

Thank you! I'll be switching over shortly, I just was apprehensive because I just finished setting up my first world and I didn't want to redo things.

[silman]

13 minutes ago, Wolbaz said:

Thank you! I'll be switching over shortly, I just was apprehensive because I just finished setting up my first world and I didn't want to redo things.

 

Moving over is easy! You can delete all the other stuff in the appdata folder besides the 'data' folder (the folder containing Data, Logs, and Config dirs) and then just point your Game Data Path to that data folder. Then you can delete the fithwum docker (and image) and start up this one.

Edited March 16, 2022 by silman

[Wolbaz]

I found that I have issue with trying to put just '9' in the version number. Doing so gives me the following: 

today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [debug] Timezone set to: GMT-4
today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [info] Starting felddy/foundryvtt container v9.255.0
today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [debug] CONTAINER_VERBOSE set.  Debug logging enabled.
today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [warn] FOUNDRY_VERSION has been manually set and does not match the container's version.
today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [warn] Expected 9.255 but found 9
today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [warn] The container may not function properly with this version mismatch.
today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [info] No Foundry Virtual Tabletop installation detected.
today at 9:07:44 AMEntrypoint | 2022-03-19 09:07:44 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
today at 9:07:45 AMAuthenticate | 2022-03-19 09:07:45 | [debug] Saving cookies to: cookiejar.json
today at 9:07:45 AMAuthenticate | 2022-03-19 09:07:45 | [info] Requesting CSRF tokens from https://foundryvtt.com
today at 9:07:45 AMAuthenticate | 2022-03-19 09:07:45 | [debug] Fetching: https://foundryvtt.com
today at 9:07:45 AMAuthenticate | 2022-03-19 09:07:45 | [info] Logging in as: wolbaz
today at 9:07:45 AMAuthenticate | 2022-03-19 09:07:45 | [debug] Fetching: https://foundryvtt.com/auth/login/
today at 9:07:46 AMAuthenticate | 2022-03-19 09:07:46 | [debug] Community URL: /community/wolbaz
today at 9:07:46 AMAuthenticate | 2022-03-19 09:07:46 | [info] Successfully logged in as: wolbaz
today at 9:07:46 AMEntrypoint | 2022-03-19 09:07:46 | [info] Using authenticated credentials to download release.
today at 9:07:46 AMReleaseURL | 2022-03-19 09:07:46 | [debug] Loading cookies from: cookiejar.json
today at 9:07:46 AMReleaseURL | 2022-03-19 09:07:46 | [info] Fetching S3 pre-signed release URL for build 9...
today at 9:07:46 AMReleaseURL | 2022-03-19 09:07:46 | [debug] Fetching: https://foundryvtt.com/releases/download?build=9&platform=linux
today at 9:07:47 AMfile:///home/foundry/get_release_url.js:50
today at 9:07:47 AM        throw new Error(`Unexpected response ${response.statusText}`);
today at 9:07:47 AM              ^
today at 9:07:47 AM
today at 9:07:47 AMError: Unexpected response Not Found
today at 9:07:47 AM    at fetchReleaseURL (file:///home/foundry/get_release_url.js:50:15)
today at 9:07:47 AM    at processTicksAndRejections (node:internal/process/task_queues:96:5)
today at 9:07:47 AM    at async main (file:///home/foundry/get_release_url.js:70:24)
today at 9:07:47 AM    at async file:///home/foundry/get_release_url.js:81:24
today at 9:07:50 AMContainer stopped

 

Restarting with 9.255 works, however, so I'll just do that.

 

Leaving version number blank also gives an issue:

 

today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [debug] Timezone set to: GMT-4
today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [info] Starting felddy/foundryvtt container v9.255.0
today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [debug] CONTAINER_VERBOSE set.  Debug logging enabled.
today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [warn] FOUNDRY_VERSION has been manually set and does not match the container's version.
today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [warn] Expected 9.255 but found 
today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [warn] The container may not function properly with this version mismatch.
today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [info] No Foundry Virtual Tabletop installation detected.
today at 9:10:05 AMEntrypoint | 2022-03-19 09:10:05 | [info] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
today at 9:10:05 AMAuthenticate | 2022-03-19 09:10:05 | [debug] Saving cookies to: cookiejar.json
today at 9:10:05 AMAuthenticate | 2022-03-19 09:10:05 | [info] Requesting CSRF tokens from https://foundryvtt.com
today at 9:10:05 AMAuthenticate | 2022-03-19 09:10:05 | [debug] Fetching: https://foundryvtt.com
today at 9:10:06 AMAuthenticate | 2022-03-19 09:10:06 | [info] Logging in as: wolbaz
today at 9:10:06 AMAuthenticate | 2022-03-19 09:10:06 | [debug] Fetching: https://foundryvtt.com/auth/login/
today at 9:10:07 AMAuthenticate | 2022-03-19 09:10:07 | [debug] Community URL: /community/wolbaz
today at 9:10:07 AMAuthenticate | 2022-03-19 09:10:07 | [info] Successfully logged in as: wolbaz
today at 9:10:07 AMEntrypoint | 2022-03-19 09:10:07 | [info] Using authenticated credentials to download release.
today at 9:10:07 AMReleaseURL | 2022-03-19 09:10:07 | [debug] Loading cookies from: cookiejar.json
today at 9:10:07 AMReleaseURL | 2022-03-19 09:10:07 | [error] Unable to extract build number from version: 
today at 9:10:07 AMfile:///home/foundry/get_release_url.js:68
today at 9:10:07 AM        throw new Error(`Unable to extract build number from version: ${foundry_version}`);
today at 9:10:07 AM              ^
today at 9:10:07 AM
today at 9:10:07 AMError: Unable to extract build number from version: 
today at 9:10:07 AM    at main (file:///home/foundry/get_release_url.js:68:15)
today at 9:10:07 AM    at file:///home/foundry/get_release_url.js:81:30
today at 9:10:07 AM    at file:///home/foundry/get_release_url.js:82:3
today at 9:10:07 AM    at ModuleJob.run (node:internal/modules/esm/module_job:195:25)
today at 9:10:07 AM    at async Promise.all (index 0)
today at 9:10:07 AM    at async ESMLoader.import (node:internal/modules/esm/loader:337:24)
today at 9:10:07 AM    at async loadESM (node:internal/process/esm_loader:88:5)
today at 9:10:07 AM    at async handleMainPromise (node:internal/modules/run_main:61:12)
today at 9:10:17 AMContainer stopped

 

[Ikthayt]

On 3/16/2022 at 7:07 PM, silman said:

 

Moving over is easy! You can delete all the other stuff in the appdata folder besides the 'data' folder (the folder containing Data, Logs, and Config dirs) and then just point your Game Data Path to that data folder. Then you can delete the fithwum docker (and image) and start up this one.

I currently use the fithwum container and have two different mappings; one for the data (my worlds, uploads, modules, compendiums, etc.), one for the actual VTT software.  

/foundry/data <--> /mnt/user/Foundry/
/foundry/fvtt <--> /mnt/user/appdata/FoundryVTT

 

Did this just to keep the appdata folder reasonable, as it is on the SSD cache array and my data folder is on the storage array (data folder is nearing 40GB at this point, so don't need all that on the cache).  The server running from the appdata folder is fine though.

 

 Thoughts?  I'm not totally stuck on this - just made sense at the time with fithwum's config. 

[silman]

32 minutes ago, Ikthayt said:

I currently use the fithwum container and have two different mappings; one for the data (my worlds, uploads, modules, compendiums, etc.), one for the actual VTT software.  

/foundry/data <--> /mnt/user/Foundry/
/foundry/fvtt <--> /mnt/user/appdata/FoundryVTT

 

Did this just to keep the appdata folder reasonable, as it is on the SSD cache array and my data folder is on the storage array (data folder is nearing 40GB at this point, so don't need all that on the cache).  The server running from the appdata folder is fine though.

 

 Thoughts?  I'm not totally stuck on this - just made sense at the time with fithwum's config. 

 

I had a similar setup. with this container just point the data folder at your /mnt/user/Foundry. The felddy container itself downloads and runs the foundry app so it's all within the docker.img.

 

Look at my second post in this thread and you will see Game Data Path pointing to /mnt/appstorage/Foundry. I use `appstorage` as my unraid share on HDD (not cache/SSD) which persistently stores data used by `appdata` (which only stores docker apps necessary persistent files). So all extra media specific to my docker apps is on HDD (since it can get quite large, as you know).

[dotsonic]

I'm in the process of evaluating UnRaid as a replacement for my aging Synology where I currently host a few FoundryVTT campaigns.  For the most part, the initial setup is working with a few minor issues that I feel are more likely UnRaid related:

 

• I can't seem to save Configuration changes.  For example, I would like to set a default campaign but it doesn't seem to stick.  In my other Docker setup I simply set the CONTAINER_PRESERVE_CONFIG = true variable which made the admin.txt and configuration persistent between restarts.  Is that not possible with this implementation?  I attempted to add the variable but it doesn't seem to change the behavior.
• With my current setup, I have an SMB share that points to my /data directory so I can directly edit world files if necessary.  I was able to set the folder permissions to allow Read/Write for my account.  Is that possible using UnRaid?  It appears that the permissions are reset on the /data folder (which I have pathed to /mnt/appstorage/foundryvtt) whenever the server restarts. 
• Is there a reason to use the APP over the standard docker in UnRaid outside of the helpful pre-mapping of docker variables?
• I see above that the container is running as user 421.  Is that why the /appdata/foundryvtt folder is listed as owned by UNKNOWN?

 

Update 5/9/22

I decided to download the docker image directly from docker hub (https://hub.docker.com/r/felddy/foundryvtt) and configure it manually.  That worked better for my system.

 

Settings:

 

/data: /mnt/user/appdata/foundryvtt/

FOUNDRY_USERNAME: [my account name for foundryvtt.com]

FOUNDRY_PASSWORD: [my password for foundryvtt.com]

CONTAINER_PRESERVE_CONFIG: true
FOUNDRY_ADMIN_KEY: [initial admin password for my FoundryVTT docker]
FOUNDRY_UID: 99

FOUNDRY_GID: 100
Port: 30000 -> 30000

 

The biggest win was configuring the container to run as the nobody account  (UID:99, DIP:100) which set the correct ownership for the /data path.  Now settings are saved after cycling the container.  I was also able to remove my foundryvtt.com username and password after pulling the initial install (it pulled the latest version automatically).

 

Hope that helps others.

 

Edited May 9, 2022 by dotsonic

[Libberator]

For the life of me, I have gone through the forums, the documentation, the logs, and I can't figure out why the docker isn't caching the foundry downloads.

 

I've run chown to make sure it had access, tried making the container_cache myself, tried leaving it to the installer, etc. It never makes the file, and if I put a .zip in there, it doesn't see it.

 

Am I missing an obvious flag? I don't even know where it is holding it while the docker runs, only to lose the data on restart. I am fairly new to hosting dockers, so maybe this is an obvious fix, any ideas?

[zer0ish]

On 11/27/2022 at 1:05 PM, Libberator said:

For the life of me, I have gone through the forums, the documentation, the logs, and I can't figure out why the docker isn't caching the foundry downloads.

 

I've run chown to make sure it had access, tried making the container_cache myself, tried leaving it to the installer, etc. It never makes the file, and if I put a .zip in there, it doesn't see it.

 

Am I missing an obvious flag? I don't even know where it is holding it while the docker runs, only to lose the data on restart. I am fairly new to hosting dockers, so maybe this is an obvious fix, any ideas?

 

For the game files and everything you want to be kept persistent you have to use the "Game Data Path:"
This location in the Template will = "User Data Path" inside of FoundryVTT Config.
 

So as an example for me:

In FoundryVTT Config, I have: User Data Path = /data

In Unraid FoundryVTT template, I have: /mnt/user/appdata/FoundryVTT/

 

So all my FoundryVTT persistent things, like logs, worlds, images, downloads all go in here /mnt/user/appdata/FoundryVTT/ which correlates to /data in the config

I've never lost anything after a reboot or upgrade with this setup.

 

I also have all the folders and docs in my FoundryVTT Appdata folder owner as nobody, I had to change it to that since I transferred my old Windows 10 install to Unraid.

 

Hope this helps.

[thymon]

Hello,

 

Since update v9 to v1O. I have an error message :

FoundryVTT | 2022-12-26 14:20:16 | [error] Software license verification failed. Please confirm your Foundry Virtual Tabletop software license

 

[acdn01]

Hi! I've just installed Unraid and am trying to copy the Foundry data from my old installation to the docker container. When I log in to the Foundry set up screen, none of my modules, systems, or worlds appear--I am prompted to install a system and set up a new world as though none of that info was there. I have copied my old Foundry data into the data/ folder, but it does not appear when I start the container.

 

How do I get the container to recognize the Foundry data I copied over?

 

Edit with Solution:

To ensure that your pre-existing Foundry data is recognized by the Docker app:

1. Create the directory to map to /data. The path I used was /mnt/usr/cache/FoundryVTT/data/
2. Install the docker container.
3. Copy your pre-existing Foundry data from wherever you saved it to the directory you created in step 1.

 

So if anyone else makes the same basic mistake I did, hopefully this helps.

Edited January 9, 2023 by acdn01

[dodgypast]

I'm having a problem installing modules on a new install.

 

I've tried a few and I get the following error for every module I try:
 

The requested manifest at "https://bitbucket.org/rpgframework-cloud/shadowrun6-eden/downloads/system-staging.json" did not provide system manifest data.

 

I have posted it as an issue on Github here:
https://github.com/felddy/foundryvtt-docker/issues/565

 

Edited January 11, 2023 by dodgypast
Add Github issue post

[serhan]

Hi, 

 

I am fairly new to Unraid but trying to get this running. 

 

I have once seen the Foundry screen in the webui, I closed the docker thinking I will set things up later. Now I cannot see anything on the webui, just an error. 

 

The logs say:

 

* The requested URL returned error: 403

 

Can anyone offer any guidance on why I can't see seem to access?

 

EDIT:
 

I found at least a problem. My download link had timed out from Foundry. Now I am not getting any errors but still can't see anything on the webui!

Edited February 3, 2023 by serhan
Updated issue