Having issues getting data persistence to work using the volume tags in an UnRaid operation system. The information in the Ignition Manual - Docker (Docker Image - Ignition User Manual 8.1 - Ignition Documentation) under the section Preserving Gateway State' was insufficient for a path configuration in the UnRaid Docker setup.
My best guess per this screenshot
Has someone succeeded with making Ignition data persistence to work in UnRaid?
My guess is that you're running into issues with the initial files under the data folder getting "stomped" by the bind-mount. For the moment, you might try using kcollins/ignition image that has a built-in alternative mount path (/data) that will copy the initial content from the data volume into place during first-launch.
Past that, keep in mind that there may be permissions issues with the volume you're mounting--you can align the UID/GIDs being used with the IGNITION_UID and IGNITION_GID environment variables (to match what you might need on that preserved volume, i.e. /mnt/user/appdata/ignition/data in your example).
Has anyone worked this out? Trying to get the container running in Unraid and having the same issues as the original poster with non-persistent data
Also can't seem to get a new container running with UnRAID.
Using the following environment variables:
- IGNITION_UID=99
- IGNITION_GID=100
And getting the following error while running the compose file:
ignition-gateway | /usr/local/bin/docker-entrypoint.sh: line 629: /usr/local/bin/ignition/data/init.properties: Permission denied
In order to use the IGNITION_UID and IGNITION_GID variables, you also need to start the container as root. You'll probably see a warning like this in your container logs:
init | 2024/04/22 13:44:14 | WARNING: IGNITION_UID='999' and IGNITION_GID='999' are ignored when not running as root (uid=0), detected uid=2003
Add user: 0:0 to the service and see if that helps.
Thanks that worked! I'm not used to running my Docker containers as root.
I don't blame you, you shouldn't run as root if possible! Thankfully, with this strategy, only the entrypoint script is run as root; from there, gosu handles root stepdown to launch the gateway as the target UID. The alternative is to align the volume ownership/permissions with our images built-in UID/GID of 2003.