Description
Mounting a custom config.ttl to /linkedfactory-pod/config.ttl does not result in that file being copied into /linkedfactory-pod/workspace/config.ttl at container startup as expected. The entrypoint script is supposed to copy the mounted config into workspace/, but the workspace keeps the image-default config. Deleting /linkedfactory-pod/workspace/config.ttl and restarting causes the mounted config to be copied and used.
Entrypoint reference:
|
cp -nv /linkedfactory-pod/config.ttl /linkedfactory-pod/workspace/ |
Example (from docker-compose)
services:
lf-pod-factory:
image: linkedfactory/linkedfactory-pod:1.2.0-SNAPSHOT
volumes:
- ./lf-pod-cli/config.ttl:/linkedfactory-pod/workspace/config.ttl # WORKS - Custom Config file
- ./lf-pod-cli/config.ttl:/linkedfactory-pod/config.ttl # DOESNT WORK - Custom Config file
How to reproduce / test
- Use the compose snippet above (mount custom
config.ttl to /linkedfactory-pod/config.ttl).
- Start the service:
docker compose up -d.
- Inspect inside the container:
cat /linkedfactory-pod/config.ttl (shows mounted file)
cat /linkedfactory-pod/workspace/config.ttl (shows image-default file, not the mounted one)
- Remove
/linkedfactory-pod/workspace/config.ttl and restart the container; the mounted config is then copied into workspace/ and used.
Observed
/linkedfactory-pod/config.ttl is the mounted file, but /linkedfactory-pod/workspace/config.ttl remains the image-default after startup.
Expected
- The entrypoint should copy the mounted
/linkedfactory-pod/config.ttl into /linkedfactory-pod/workspace/config.ttl at startup so the custom config is used without manual deletion.
Workaround
- Mount the config directly into the workspace path:
- ./lf-pod-cli/config.ttl:/linkedfactory-pod/workspace/config.ttl
Possible cause / hypothesis
- The image includes a default
workspace/config.ttl; the entrypoint may intentionally avoid overwriting an existing workspace config, so the copy is skipped if workspace/config.ttl already exists. Another possibility is bind-mount ordering or entrypoint logic that checks for workspace presence before copying.
Description
Mounting a custom
config.ttlto/linkedfactory-pod/config.ttldoes not result in that file being copied into/linkedfactory-pod/workspace/config.ttlat container startup as expected. The entrypoint script is supposed to copy the mounted config intoworkspace/, but the workspace keeps the image-default config. Deleting/linkedfactory-pod/workspace/config.ttland restarting causes the mounted config to be copied and used.Entrypoint reference:
linkedfactory-pod/docker/entrypoint.sh
Line 2 in c3fe6b3
Example (from docker-compose)
How to reproduce / test
config.ttlto/linkedfactory-pod/config.ttl).docker compose up -d.cat /linkedfactory-pod/config.ttl(shows mounted file)cat /linkedfactory-pod/workspace/config.ttl(shows image-default file, not the mounted one)/linkedfactory-pod/workspace/config.ttland restart the container; the mounted config is then copied intoworkspace/and used.Observed
/linkedfactory-pod/config.ttlis the mounted file, but/linkedfactory-pod/workspace/config.ttlremains the image-default after startup.Expected
/linkedfactory-pod/config.ttlinto/linkedfactory-pod/workspace/config.ttlat startup so the custom config is used without manual deletion.Workaround
- ./lf-pod-cli/config.ttl:/linkedfactory-pod/workspace/config.ttlPossible cause / hypothesis
workspace/config.ttl; the entrypoint may intentionally avoid overwriting an existing workspace config, so the copy is skipped ifworkspace/config.ttlalready exists. Another possibility is bind-mount ordering or entrypoint logic that checks for workspace presence before copying.