# Pre-loading configuration FileAlreadyExistsException in ignition 8.3.2

**URL:** <https://forum.inductiveautomation.com/t/pre-loading-configuration-filealreadyexistsexception-in-ignition-8-3-2/113241>\
**Category:** Ignition\
**Tags:** ignition83\
**Created:** [January 13, 2026, 10:54am UTC](https://forum.inductiveautomation.com/t/pre-loading-configuration-filealreadyexistsexception-in-ignition-8-3-2/113241 "2026-01-13T10:54:40Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![filip.persson](https://avatars.discourse-cdn.com/v4/letter/f/91b2a8/32.png) [@filip.persson](https://forum.inductiveautomation.com/u/filip.persson)\
**Post date:** [January 13, 2026, 10:54am UTC](https://forum.inductiveautomation.com/t/pre-loading-configuration-filealreadyexistsexception-in-ignition-8-3-2/113241/1 "2026-01-13T10:54:40Z")

</div>

The problem I’ve encountered is preloading configurations.

This error can be replicated by creating an image and copy the pre defined config files into the file destination, by doing:  
`COPY --chown=2003:2003 adfs/config.json /usr/local/bin/ignition/data/config/resources/core/ignition/identity-provider/adfs/`  
`COPY --chown=2003:2003 adfs/resource.json /usr/local/bin/ignition/data/config/resources/core/ignition/identity-provider/adfs/`

When the container is Running with that image with the preloaded configurations it throws this exception:  
`java.nio.file.FileAlreadyExistsException: Resource collection path '/usr/local/bin/ignition/data/config/resources/core' exists but is not empty`

How do we solve this?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [January 13, 2026, 4:35pm UTC](https://forum.inductiveautomation.com/t/pre-loading-configuration-filealreadyexistsexception-in-ignition-8-3-2/113241/2 "2026-01-13T16:35:32Z")

</div>

The `core` collection is expected to be owned and managed entirely by the Ignition gateway instance.

If you want to "pre load" configuration, you should do so via the `external` resource collection, which is treated as immutable by the gateway and loaded _before_ other sources as a base.

Some general background on how Ignition resources are encoded:

> [@Ignition internal Folder Structure](https://forum.inductiveautomation.com/t/ignition-internal-folder-structure/110717/2):
>
> I thought we had some kind of reference page for this in the manual, but all I found was this, which is not quite the full story: This old post of mine goes into more detail, though is a bit out of date: Basically: projects/ has an ignorable .resources/ folder. All other folders in projects/ will be scanned - if they contain a valid project.json manifest, then they make up an Ignition project. The name of the project will be the literal name of the folder on disk. Below each project direc…

Concrete advice on what you're trying to do:

> [@Ignition 8.3 GIT Deployment Best Practices](https://forum.inductiveautomation.com/t/ignition-8-3-git-deployment-best-practices/109355/2):
>
> You'll probably have to wait a while for complete guides to become available. For now, I'll mention that files created in the external "resource collection" (also known as mode or just collection; roughly analogous to a "project") are guaranteed to go untouched by Ignition and will be treated as immutable. If you want to preconfigure/deploy gateways from source control, that's going to be your preferred avenue - essentially, duplicate the nested folder structure from data/config/resources/core…

And some diagrams showing the single inheritance tree used for gateway configuration:

> [@Deployment modes override and rename to override with another type?](https://forum.inductiveautomation.com/t/deployment-modes-override-and-rename-to-override-with-another-type/111339/3):
>
> Deployment modes can change anything (though it's not necessarily recommended). If it helps, think of it as a single project inheritance tree. If you're in the dev mode, you're consuming external -\> system -\> core, then whatever dev defines, and then potentially overridden by anything local: Tree External External System System External-\>System Core Core System-\>Core Dev Dev Core-\>Dev Test Test Core-\>Test Prod Prod Core-\>Prod Local Local …
