Docker configuration for UnRaid OS

Ignition
1

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

image
image2351×1388 134 KB

Has someone succeeded with making Ignition data persistence to work in UnRaid?

1 Like
2

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).

4

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

5

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

6

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.

1 Like
7

Thanks that worked! I'm not used to running my Docker containers as root.

8

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.

1 Like