EDIT Note: I discovered I can save other domains, just not the default domain. Maybe this is intentional.
I am setting up a Docker appliance. I have my Docker compose file created, and I can start up the appliance and work with it in every way possible. The problem I'm having is saving changed configurations for the default domain.
Now, before you jump on the answer too quickly, I've run out of the internet searching for a solution. There are many examples of using Docker Compose, but none of them show they can save a configuration. It seems one can only *use* the configurations, and, they've pre-configured the entire working configurations in the auto-startup.cfg file (which I can do, but this is now a mission for me if it is possible).
I do have my config, cert, and local file systems mounted external to the container, and have performed the "chmod -R 777 config local cert" to all of those directories on my host. The appliance is successfully writing into those directories. That is, it was able to write the webgui-privkey and webgui-sscert into the cert directory. It created the "luna_config" subdirectory structure under the local directory. And, at the very least, it is reading my auto-startup.cfg and auto-user.cfg files from the config directory as evidenced by unique ports and comments in the configurations.
Yet, no matter what, when I try to persist it, I can very briefly see it create and remove a temporary file within the config directory. That is when I get the dreaded error:
20250923T021404.693Z [0x8100000f][system][critic] : tid(9791): Failed to save configuration to 'config:///auto-startup.cfg'
20250923T021404.694Z [0x8100003c][mgmt][critic] domain(default): tid(9791): Domain configuration not saved.
20250923T021404.695Z [0x810000d2][cli][error] : tid(813): Saving configuration failed - File rename failed..
20250923T021404.695Z [0x81000224][cli][error] : tid(813): === Line 2: write memory
20250923T021404.721Z [0x00d30003][mpgw][error] mpgw(rest-mgmt-int): tid(29919)[error][172.20.0.1] gtid(e505164b68d2025b000003f7): Rejected by filter; SOAP fault sent
I've tried changing the user in the docker compose file from "root" to "drouter" to no avail. Of course, when I do that, I lose SSH access to the appliance, which is not ideal.
I get I can likely solve it with "docker run". Is there some limitation of using Docker compose? If not, what am I missing?
Here is my docker compose if it helps:
services:
datapower:
image: icr.io/cpopen/datapower/datapower-limited:10.6.4.0
container_name: datapower
restart: unless-stopped
user: root
ports:
- "9090:9090" # WebGUI
- "9022:2022" # SSH
- "5550:5550" # XMI
- "5554:5554" # REST
environment:
DATAPOWER_ACCEPT_LICENSE: "true"
DATAPOWER_INTERACTIVE: "true"
DATAPOWER_LOG_COLOR: "true"
DATAPOWER_LOG_STDOUT: "true"
DATAPOWER_ADMIN_PASSWORD: "admin"
DATAPOWER_INSTANCE: "default"
volumes:
- ./config/default.cfg:/opt/ibm/datapower/drouter/config/default.cfg
- ./config/auto-user.cfg:/opt/ibm/datapower/drouter/config/auto-user.cfg
- ./config/auto-startup.cfg:/opt/ibm/datapower/drouter/config/auto-startup.cfg
- ./config:/opt/ibm/datapower/drouter/config
- ./local:/opt/ibm/datapower/drouter/local
- ./cert:/opt/ibm/datapower/root/secure/usrcerts
Please note: As suggested in some internet related responses I should mount to "/drouter/config" (etc) rather than "/opt/ibm/drouter/config", I can tell you the appliance doesn't seem to allow access at all when I try that. It is also counter to the docker appliance documentation at IBM itself. With the above docker compose, everything works *except* saving the configuration.