# Bug in the docker container image ignition:8.\* preventing new volume mounts seeding properly

**URL:** <https://forum.inductiveautomation.com/t/bug-in-the-docker-container-image-ignition-8-preventing-new-volume-mounts-seeding-properly/111259>\
**Category:** Ignition\
**Tags:** ignition83, docker\
**Created:** [October 8, 2025, 3:11am UTC](https://forum.inductiveautomation.com/t/bug-in-the-docker-container-image-ignition-8-preventing-new-volume-mounts-seeding-properly/111259 "2025-10-08T03:11:59Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sean.liew](https://avatars.discourse-cdn.com/v4/letter/s/b9bd4f/32.png) [@sean.liew](https://forum.inductiveautomation.com/u/sean.liew)\
**Post date:** [October 8, 2025, 3:11am UTC](https://forum.inductiveautomation.com/t/bug-in-the-docker-container-image-ignition-8-preventing-new-volume-mounts-seeding-properly/111259/1 "2025-10-08T03:11:59Z")

</div>

Observed issues deploying on Kubernetes with persistent volumes. Documents indicate mounting volumes to **/usr/local/bin/ignition/data** however in doing so, this effectively hides existing clean templates which are presented in the same folder. The result is a failure to launch as certain clean template files cannot be found (being masked out by the mounted volume). We see errors like this:

> cannot stat '/usr/local/bin/ignition/data/gateway.xml\_clean': No such file or directory

In reviewing the **docker-entrypoint.sh** script in the container I can confirm that this is designed well to deal with a fresh mounted volume and seeding it with a clean template folder. It functions as it should but providing the mounted volume is under **/usr/local/bin/ignition/data** and the default clean template data folder is under **/usr/local/bin/ignition/data\_clean.** This should really only require a few lines to change in the **Dockerfile**.

Note, if an ephemeral instance is required (no volume mounts), then this works fine. The entrypoint script will initialise a new running instance with the default clean template files correctly.

A hack workaround I needed to implement is to mount to **/data** and then override the default entrypoint script run to be replaced with the following:

```python
  # Move the default clean template data folder to where its supposed to be
  mv ${IGNITION_INSTALL_LOCATION}/data ${IGNITION_INSTALL_LOCATION}/data_clean;

  # Create a symlink /usr/local/bin/ignition/data pointing to our persistent
  # volume
  ln -s /data ${IGNITION_INSTALL_LOCATION}/data;

  # Resume original entrypoint to do the rest
  docker-entrypoint.sh;

```

Creating this topic to share the workaround and to hopefully chase up a simple fix.

---

<div class="post-metadata">

**Author:** ![Eric\_Knorr](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/eric_knorr/32/53150_2.png) [@Eric\_Knorr](https://forum.inductiveautomation.com/u/Eric_Knorr)\
**Post date:** [October 8, 2025, 7:23pm UTC](https://forum.inductiveautomation.com/t/bug-in-the-docker-container-image-ignition-8-preventing-new-volume-mounts-seeding-properly/111259/2 "2025-10-08T19:23:02Z")

</div>

Hey @sean.liew, good analysis of the issue! While I don't have all the past context for why this is the way it is, it seems to be the same root cause as the Docker bind-mount scenario [discussed here](https://forum.inductiveautomation.com/t/unable-to-mount-ignition-data-folder-in-an-external-volume-using-docker/64928) - the volume mount masks the clean template files.

The official [Ignition Helm Chart](https://charts.ia.io/) handles this exact scenario in Kubernetes using an init container to seed the persistent volume before the main container starts. This is the Kubernetes-native pattern we recommend. You can see the specific implementation [here in the StatefulSet template](https://github.com/inductiveautomation/ignition-helm-chart/blob/447c084be4373821fc0d5987f12093a583072c89/ignition/templates/statefulset.yaml#L205C11-L205C46).

If you're building custom manifests and your symlink workaround is working well, that's a valid solution. Otherwise, the Helm chart handles this for you automatically.