d3fc0n0wltraps

Found my issue - I had been previously playing with disk mappings and mover. This broke my maria container in such a way that it would start without error and "accept" connections, but those connections would just hang forever instead of actually succeeding or failing. I wouldn't expect Romm to handle this any more gracefully than it already did - even MySQLWorkbench would lock up waiting trying to access my maria container So, false alarm, please disregard. Fixed my maria container

I haven't messed with Romm in a little while - it was working fine on 3.x previously - and today trying to use it the WebUI doesn't work. Looking in my logs I see the following; INFO: [init][2024-06-22 12:58:07] Starting up, please wait... INFO: [init][2024-06-22 12:58:12] starting redis-server 11:C 22 Jun 2024 12:58:12.814 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 11:C 22 Jun 2024 12:58:12.814 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 11:C 22 Jun 2024 12:58:12.814 * Redis version=7.2.4, bits=64, commit=00000000, modified=0, pid=11, just started 11:C 22 Jun 2024 12:58:12.814 * Configuration loaded 11:M 22 Jun 2024 12:58:12.815 * monotonic clock: POSIX clock_gettime 11:M 22 Jun 2024 12:58:12.815 * Running mode=standalone, port=6379. 11:M 22 Jun 2024 12:58:12.815 * Server initialized 11:M 22 Jun 2024 12:58:12.816 * Loading RDB produced by version 7.2.4 11:M 22 Jun 2024 12:58:12.816 * RDB age 122447 seconds 11:M 22 Jun 2024 12:58:12.816 * RDB memory usage when created 11.05 Mb 11:M 22 Jun 2024 12:58:12.856 * Done loading RDB, keys loaded: 16, keys expired: 2. 11:M 22 Jun 2024 12:58:12.857 * DB loaded from disk: 0.042 seconds 11:M 22 Jun 2024 12:58:12.857 * Ready to accept connections tcp INFO: [RomM][2024-06-22 12:58:14] Connecting to redis in /backend/bin/alembic... INFO: [RomM][2024-06-22 12:58:14] Redis connection established in /backend/bin/alembic! And it just waits forever after that. No failure to connect to maria, etc., I did try the changes listed by ktfcaptain and those unfortunately did not make a difference.

Hey @fithwum, love the container. I was deploying another instance today and noticed that the logo is requested from a gitlab that is currently unreachable. It looks like you maintain your icon repo over on github as well so I just updated the container config to reference that. Not sure if this is the result of an intentional migration or what-have-you, just though I'd bring it to your attention.

Sure - to be more clear - the current template targets :latest, which means 3.X, so it is completely broken by default and will break if anyone deployed it previously and then updates it now that 3.0 is released (what happened to me). The template doesn't take into account any of the requirements. Your instructions are great for anyone that wants to use 3.X, my recommendation is only for people that are comfortable on the last 2.X release and want the CA template to work again.

Alternatively, just use the current CA template and set it to target zurdi15/romm:2.3.1 At least for me that most recent legacy version scratches all my itches.

That container doesn't share mappings with anything else, and it doesn't matter if the container is mapped via FUSE or not (I haven't gotten around to setting up exclusive share yet). It's a non-issue at this point, anyway. I just had to let it stop for longer by changing the stop->backup->start behavior

I seem to be having an issue with this vs. the original appdata backup: 'file has changed' as experience by several other people in the thread: [13.01.2024 09:25:55][❌][FoundryVTT10] tar creation failed! Tar said: tar: /mnt/user/AppData/FoundryVTT10/data/Data/modules/JB2A_DnD5e/Library/Generic/Impact/GroundCrackFrostImpact_01_Regular_White_600x600.webm: file changed as we read it; tar: /mnt/user/AppData/FoundryVTT10/data/Data/modules/JB2A_DnD5e/Library/Generic/Impact: file changed as we read it; tar: /mnt/user/AppData/FoundryVTT10/data/Data/modules/JB2A_DnD5e/Library/Generic: file changed as we read it; tar: /mnt/user/AppData/FoundryVTT10/data/Data/modules/JB2A_DnD5e/Library: file changed as we read it; tar: /mnt/user/AppData/FoundryVTT10/data/Data/modules/JB2A_DnD5e: file changed as we read it; tar: /mnt/user/AppData/FoundryVTT10/data/Data/modules: file changed as we read it; tar: /mnt/user/AppData/FoundryVTT10/data/Data: file changed as we read it; tar: /mnt/user/AppData/FoundryVTT10/data: file changed as we read it id: 89a9402e-820c-47c8-b066-a6a8baae4ee8 While it isn't reliably that file, it is reliably that folder that has a "changed as we read it". Any recommendations for finding what is touching that file with the docker stopped? That container doesn't share mappings with anything else, and it doesn't matter if the container is mapped via FUSE or not (I haven't gotten around to setting up exclusive share yet). Editing to add: I changed the backup type from "stop, backup, start container" to "stop all containers, backup, start all containers" and that seems to have given whatever process enough time to let go of those files before the plugin tries to touch it. I have noticed in the past that that particular container isn't receptive to being restarted from the gui. It need to be stopped - wait - restarted. I don't know how to explain that behavior from a docker POV but it certainly seems to track with this. Either way issue seems to be resolved for me. When this happened to me, it was because the appdata source paths are case sensitive. By default the plugin looks for paths of So it didn't automatically believe my paths (/mnt/user/AppData and /mnt/cache/AppData) were internal volumes. I just added my paths to appdata source(s):

Excellent! Thank you very much!

Hi Fithwum, Thanks for you work on this! I am running into an issue where I would like to run multiple instances and they all try to grab port 30000. Would it be possible to update it to use a specified port? Thank you!

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!

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.

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

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.

Have you had any luck finding a solution? I'm having a similar issue since the update. I'm using nginx proxy manager and when I don't give it :8080 after the reverse proxied URL I get failure to render / odd behavior: I also can't interact with the date picker to change the timeline I'm looking at, etc. If I go to the proxied URL and add :8080 to it, everything runs fine. I've looked through the documentation but all I can really find is information on getting HTTPS rewriting to work with nginx. Edit to the edit: NGINX Proxy Manager needed a custom location at root pointing to my proxied URL with the host-side port. Everything is working fine now. I'm going to leave the other screenshot/description up in case anyone else comes across this post with a similar issue.