I am working with docker image 8.1.26 and I have having issues with my project setting disappearing after I do a docker compose down and when I do docker compose up -d I am missing the project setting.
Project-> Project Properties-> General-> Identity Providers
I am losing this setting
My compose volume mapping is - gw-data2:/usr/local/bin/ignition/data
Suggestions on how to resolve
This was a fresh install of 8.1.26 and was not an upgrade from previous version.
@kcollins1 any suggestions ?
This looks like permission issue.
Logs show
jvm 1 | 2023/04/03 08:20:11 | E [g.IgnitionProjectManager ] [15:20:11]: Unable to delete resource at /usr/local/bin/ignition/data/projects/HelpDesk/com.inductiveautomation.perspective/general-properties request-origin=172.18.0.1, session-user=mark.mcclure, session-project=HelpDesk, session-id=48C89BCC
jvm 1 | 2023/04/03 08:20:11 | E [g.IgnitionProjectManager ] [15:20:11]: Unable to create resource at /usr/local/bin/ignition/data/projects/HelpDesk/com.inductiveautomation.perspective/general-properties request-origin=172.18.0.1, session-user=mark.mcclure, session-project=HelpDesk, session-id=48C89BCC
jvm 1 | 2023/04/03 08:20:11 | E [g.IgnitionProjectManager ] [15:20:11]: Unable to delete resource at /usr/local/bin/ignition/data/projects/HelpDesk/com.inductiveautomation.perspective/page-config request-origin=172.18.0.1, session-user=mark.mcclure, session-project=HelpDesk, session-id=48C89BCC
jvm 1 | 2023/04/03 08:20:11 | E [g.IgnitionProjectManager ] [15:20:11]: Unable to create resource at /usr/local/bin/ignition/data/projects/HelpDesk/com.inductiveautomation.perspective/page-config request-origin=172.18.0.1, session-user=mark.mcclure, session-project=HelpDesk, session-id=48C89BCC
jvm 1 | 2023/04/03 08:20:11 | E [g.IgnitionProjectManager ] [15:20:11]: Unable to delete resource at /usr/local/bin/ignition/data/projects/HelpDesk/com.inductiveautomation.perspective/session-props request-origin=172.18.0.1, session-user=mark.mcclure, session-project=HelpDesk, session-id=48C89BCC
jvm 1 | 2023/04/03 08:20:11 | E [g.IgnitionProjectManager ] [15:20:11]: Unable to create resource at /usr/local/bin/ignition/data/projects/HelpDesk/com.inductiveautomation.perspective/session-props request-origin=172.18.0.1, session-user=mark.mcclure, session-project=HelpDesk, session-id=48C89BCC
jvm 1 | 2023/04/03 08:20:11 | I [Project ] [15:20:11]: Restarting gateway scripts... project=HelpDesk
Based on the logs, I agree, it looks like this is a result of a permissions issue. Note that for 8.1.26, the default user changed from root to ignition (i.e. non-root). See our User Migration guidance for basic migration of typical named volume setup.
This was a new 8.1.26 setup no migration. After I started up the gateway and got everything initialized I shut down the gateway and copied our project for another gateway to _data\projects folder on our volume and then started back up the gateway.
I did confirm that if I use the import projects from the exported zips of each of our projects the permission problem does not occur.
We are planning on pushing updates to the _data\projects folder from github. We may need to do something else to get the permission to update correctly. Ideas or suggestions?
@kcollins1 clearly permissions as when we copy the files over to the volume those show up with root permission instead of ignition. I am also seeing issues with my modules showing up as root.
volumes:
- ./modules/MQTT-Engine-signed.modl:/usr/local/bin/ignition/user-lib/modules/MQTT-Engine-signed.modl
- ./modules/MQTT-Distributor-signed.modl:/usr/local/bin/ignition/user-lib/modules/MQTT-Distributor-signed.modl
When I open a terminal to go to this folder I see root instead of ignition-rw-r--r-- 1 ignition ignition 454819 Mar 23 09:09 'Modbus Driver v2-module.modl'
-rwxrwxrwx 1 root root 35600953 Mar 29 11:44 MQTT-Distributor-signed.modl
-rwxrwxrwx 1 root root 37228093 Mar 29 11:45 MQTT-Engine-signed.modl
-rw-r--r-- 1 ignition ignition 3363108 Mar 23 09:09 Omron-Driver.modl
Is this the issue with the way we mounted as modifying the data on the mount show as root but not as ignition?
This is my data folder mount
- gw-data2:/usr/local/bin/ignition/data
Are you on a Linux host w/ Docker Engine or running under Docker Desktop (if so, what OS)?
If you're on Linux directly, bind-mounts should mirror the UID/GID of the files on the host (as they're directly mounted into the container). There are some extra layers at play if you're on Docker Desktop. Based on the looks of the above, my guess is that you're on Linux directly and the module files are currently owned by root.
I am on docker desktop for windows running wsl2 but will quickly be moving to K8 on Linux.
I thinking I need to send user: 2003:2003 in my compose file. I am looking at how this will work once I move to K8 as well. I am working on moving our Ignition from physical servers to containers behind K8.
@kcollins1 do I need to add ignition user into the /etc/sudoers.d ?
and then map?
When I run container as user: 2003: 2003 whoami does return ignition but on the volume map when I write files from outside the container it still writes files as root.
The only solution that I have come up with is to run 8.1.26 as user: "0:0" which I don't really want to do. I tried adding ignition to the sudoers.d/ignition and adding a map to that and this still did not allow me to save project that were copied directly to the PVC. I running Windows Docker desktop with WSL2 and this might be an issue with this setup.
It is a bit hard to track your exact configuration based on the snippets you've mentioned (and the wide variety of possible configurations out there). I will say that the goal of the 8.1.26 change is to go away from running as 0:0 (root).
This means, however, that you have to be thoughtful about file ownership/permissions when bind-mounting out to your host. When Ignition is running as an un-privileged user in a container, it needs read/write access to the files within the data folder. Usually this is done by aligning the UID/GID (2003) of the default installation with the files on your host. If you have more specialized needs, you usually have one of two options:
ignition user) to your required settings. Note that this used to be required to run as non-root since the Ignition installation was root-owned in <8.1.25. If you want to use a UID/GID other than 2003, this is still the approach to take.0:0 (root) and supply the IGNITION_UID and IGNITION_GID environment variables to have the entrypoint adjust ownership of the installation and associated data volume before then launching the gateway as that target user (i.e. non-root). Note that this won't be enough for Restricted pod security profile, but it might be useful in development contexts.While I'm having trouble providing a one-shot-one-kill answer for you, I do hope that this additional information helps.
I believe I am ok for now.
I suspect the issue is Windows Docker Desktop with WSL2 is not fully baked and has issue that when you write files to the volume through WSL2 that the user needs to align with what is needed inside the container.
Going to be moving off windows and into linux and see if I have issues. I highly suspect that I will need to create a derived image to align permission on the storage.