# DB Driver JAR File Location **URL:** \ **Category:** Ignition\ **Created:** [June 10, 2025, 3:07pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232 "2025-06-10T15:07:09Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![wpmccormick](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/wpmccormick/32/13940_2.png) [@wpmccormick](https://forum.inductiveautomation.com/u/wpmccormick)\ **Post date:** [June 10, 2025, 3:07pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232/1 "2025-06-10T15:07:09Z")
Is it possible that the docker image for 8.1.43 recently changed such that my Oracle DB driver must now be found here? > /usr/local/bin/ignition/user-lib/jdbc and not here: > /usr/local/bin/ignition/user-lib/jdbc-bundled ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [June 10, 2025, 3:36pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232/2 "2025-06-10T15:36:47Z")
For Ignition 8.1.x, you can place your database driver JAR's directly into place under `${IGNITION_INSTALL_LOCATION}/user-lib/jdbc`. The technique used for this can vary based on your needs; some examples might be: - building a derived image - bind-mounting files directly - mapping a volume to this folder (with this, you're locking in the versions of JDBC JARs, similar to what is done with a traditional installation). The location has not changed across Ignition 8.1.x. Ignition on Docker, unless so configured (using one of the techniques mentioned above), will use the built-in JDBC JARs to the latest versions (from the image). On a standard installation, upgrades leave your existing JDBC JARs in place. The `.../user-lib/jdbc-bundled` folder of a normal installation is where Installer places updated distributions of the JARs that Ignition ships with. They're here for reference only, and not loaded by Ignition. * * * I'll note that we've improved this "wrinkle" with the upcoming Ignition 8.3.0. In there, JDBC drivers will be defined (JARs and their associated database driver configuration JSON) in the configuration stored in the `data` volume. You'll no longer have to take specialized actions in your Docker container configuration to persist additional JAR files. Let me know if I can help further with any challenges you're having. ---
**Author:** ![wpmccormick](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/wpmccormick/32/13940_2.png) [@wpmccormick](https://forum.inductiveautomation.com/u/wpmccormick)\ **Post date:** [June 10, 2025, 4:49pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232/3 "2025-06-10T16:49:09Z")
Actually, retracting my solution because I have a dozen or so containers that for, the past several months have been loading the JAR from a `jdbc-bundled` mapped vol. And then all of a sudden, the mapped vol needs to be just `jdbc`. ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [June 10, 2025, 5:04pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232/4 "2025-06-10T17:04:15Z")
I can assert that JARs have never loaded from `jdbc-bundled`. Is it possible that you launched the containers, installed the JARs through the web UI and ran them that way for some time? If you only stopped/started the containers, everything might be fine until you recreated the container (such as for upgrading to a newer version). At that time, the `user-lib/jdbc` folder would revert to that from the image and you might end up in that situation. The correct fix (all along) is to persist `user-lib/jdbc` in order to have files there live across container lifecycle events. ---
**Author:** ![wpmccormick](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/wpmccormick/32/13940_2.png) [@wpmccormick](https://forum.inductiveautomation.com/u/wpmccormick)\ **Post date:** [June 10, 2025, 5:16pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232/5 "2025-06-10T17:16:42Z")
Hmmm ... strange. I have personally downed these containers, with volumes and purged unused vols many, many times; I think everything but pull a new image. they all have ```python volumes: ./third-party-modules/drivers/oracle-jdbc11.jar:/usr/local/bin/ignition/user-lib/jdbc-bundled/oracle-jdbc11.jar ``` But now no bueno. I tried loading the driver through the web interface as well (this how I figured out where it's happiest), and it did not survive even container restarts. ---
**Author:** ![kcollins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kcollins/32/19646_2.png) [@kcollins](https://forum.inductiveautomation.com/u/kcollins)\ **Post date:** [June 10, 2025, 5:29pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232/6 "2025-06-10T17:29:01Z")
The only other thing I can think of is that GWBK restore will populate the `user-lib/jdbc` folder with files from the backup (if present). If you're always seeding these containers from a GWBK, that could explain the behavior (until now, perhaps when your GWBK might not already contain your oracle JDBC JAR). ---
**Author:** ![wpmccormick](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/wpmccormick/32/13940_2.png) [@wpmccormick](https://forum.inductiveautomation.com/u/wpmccormick)\ **Post date:** [June 10, 2025, 5:31pm UTC](https://forum.inductiveautomation.com/t/db-driver-jar-file-location/107232/7 "2025-06-10T17:31:28Z")
Yea, I think that might explain things. From a container where this is not an issue: ```python root@1B-EPMS1:/usr/local/bin/ignition# cd user-lib/ root@1B-EPMS1:/usr/local/bin/ignition/user-lib# ll total 56 drwxr-xr-x 1 ignition ignition 4096 Jun 5 19:34 ./ drwxr-xr-x 1 ignition ignition 4096 Jun 5 19:33 ../ drwxr-xr-x 3 ignition ignition 4096 Jun 5 19:34 cls/ drwxr-xr-x 1 ignition ignition 4096 Jun 5 19:33 jdbc/ drwxr-xr-x 2 ignition ignition 4096 Jun 5 19:33 jdbc-bundled/ drwxr-xr-x 1 ignition ignition 4096 Jun 5 19:33 modules/ drwxr-xr-x 1 ignition ignition 12288 Jun 5 19:33 pylib/ root@1B-EPMS1:/usr/local/bin/ignition/user-lib# ll jdbc && ll jdbc-bundled/ total 10332 drwxr-xr-x 1 ignition ignition 4096 Jun 5 19:33 ./ drwxr-xr-x 1 ignition ignition 4096 Jun 5 19:34 ../ -rw-r--r-- 1 ignition ignition 207774 Aug 20 2024 commons-dbcp2-2.8.0.jar -rw-r--r-- 1 ignition ignition 141192 Aug 20 2024 commons-pool2-2.10.0.jar -rw-r--r-- 1 ignition ignition 621971 Jun 5 19:33 mariadb-java-client-2.7.3.jar -rw-r--r-- 1 ignition ignition 1346940 Jun 5 19:33 mssql-jdbc-9.4.0.jre11.jar -rw-r--r-- 1 ignition ignition 7199197 Jun 5 19:33 ojdbc11.jar -rw-r--r-- 1 ignition ignition 1039047 Jun 5 19:33 postgresql-42.3.3.jar total 7044 drwxr-xr-x 2 ignition ignition 4096 Jun 5 19:33 ./ drwxr-xr-x 1 ignition ignition 4096 Jun 5 19:34 ../ -rw-rw-r-- 1 ignition ignition 7199197 Apr 29 19:28 oracle-jdbc11.jar ```