Deploying on TrueNAS SCALE Bluefin - error saving cookiejar.json

[sbordeyne]

Bug description

I'm trying to deploy this container to my home NAS server running TrueNAS SCALE, using the TrueCharts "custom-app" helm chart.

The container fails to start because, even though the credentials provided are correct, the container is started as read-only, so the authentication cannot save the cookiejar.json file locally (at least that's what I assume is happening)

One solution would be to make the container use the /data volume for every read/write operation required (saving cookies, saving the version of foundry etc)

Steps to reproduce

• Setup TrueNAS SCALE on a machine
• Install the TrueCharts catalog
• Create a new "custom-app" app
• Configuration :
  • Container Repository : felddy/foundryvtt
  • Container Tag: release
  • PullPolicy: IfNotPresent
  • Environment Variables
    • FOUNDRY_USERNAME: dogeek
    • FOUNDRY_PASSWORD: <secret>
    • FOUNDRY_HOSTNAME: vtt.nas.dogeek.me
    • FOUNDRY_MINIFY_STATIC_FILES: true
    • FOUNDRY_PROXY_SSL: true
  • Service Type : ClusterIP
  • Service Ports : TCP 30000:30000
  • Storage : NFS Share :: localhost :: /mnt/apps/config/foundryvtt :: /data
  • Ingress
    • Host : vtt.nas.dogeek.me
    • Path : /
    • TLS Settings
      • Host: vtt.nas.dogeek.me
      • Certificate : cert, created through LetsEncrypt

Expected behavior

Container starts properly, files are stored in my ZFS apps ZPool, in the config dataset.

Container metadata

com.foundryvtt.version = "10.291"
org.opencontainers.image.authors = "[email protected]"
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

2023-03-04 13:41:16.947620+00:00Entrypoint | 2023-03-04 14:41:16 | [�[32minfo�[0m] Starting felddy/foundryvtt container v10.291.0
2023-03-04 13:41:16.950830+00:00Entrypoint | 2023-03-04 14:41:16 | [�[32minfo�[0m] No Foundry Virtual Tabletop installation detected.
2023-03-04 13:41:16.951321+00:00Entrypoint | 2023-03-04 14:41:16 | [�[32minfo�[0m] Using FOUNDRY_USERNAME and FOUNDRY_PASSWORD to authenticate.
2023-03-04 13:41:17.211499+00:00Authenticate | 2023-03-04 14:41:17 | [�[32minfo�[39m] Requesting CSRF tokens from https://foundryvtt.com
2023-03-04 13:41:18.152065+00:00Authenticate | 2023-03-04 14:41:18 | [�[31merror�[39m] Unable to authenticate: EROFS: read-only file system, open 'cookiejar.json'

Code of Conduct

• I agree to follow this project's Code of Conduct

[mattloehr]

Ran into this problem as well. Workaround: Make sure the custom-app runs as a user that has adequate permissions to Read | Write.

In the custom-app, put:

UID: 0 (Security and Permissions > "runAsUser")
GID: 0 (Security and Permissions >"runAsGroup")
PUID: 568
fsGroup: 568
Security and Permissions > Show Advanced Settings > [X] ReadOnly root Filesystem off

Note that the custom-app will default to UID:GID 568:568. This is a Builtin "Unprivileged Apps User". Other installs via truechart (e.g. pihole) will run as UID:GID 0:0 (root) and just have PUID 568. This seems to be the correct way to do this.

Problem I had: If you [X] Automatic Permissions the container will run chown at startup: This leaves me with quite the headache for permissions, when I want to drop data into /data/Data. Have to have rw permissions for that, but Automatic Permissions overrides that and 568 cant have smb. So manual chown it is... I think?

Also, it is a rather dirty workaround because this way, the custom-app will be able to write in the root filesystem. I dont think I want that. Your solution "to make the container use the /data volume for every read/write operation required (saving cookies, saving the version of foundry etc)" would be really good.

[felddy]

The current version of the image does not easily support a read-only root filesystem. I wouldn't consider this a bug, and I would be open to a feature request to support this use case. The change would require the revisiting of assumption about the ephemeral nature of the FoundryVTT install.

I'm going to convert this issue into a discussion so it can help others that may be using a runtime that defaults to read-only root filesystems.

See:

• https://docs.docker.com/engine/reference/commandline/run/#read-only