[BUG] Switching from `:latest` to `:minimal` fails with `/usr/local/bin/docker-entrypoint.sh: 8: exec: octoprint: not found`

[adelton]

Describe the bug

I have a working setup with podman and docker.io/octoprint/octoprint:latest. I've realized I did not have it hardened with --read-only but I hit #279 when I tried to enable it. That made me realize there is docker.io/octoprint/octoprint:minimal which might be perfest as I don't have a webcam anyway and I'm OK with the limitations listed at https://github.com/OctoPrint/octoprint-docker/blob/master/docs/using_the_minimal_image.md.

However, switching the existing installation (volume) from :latest to :minimal leads to a failed start of the container with message

/usr/local/bin/docker-entrypoint.sh: 8: exec: octoprint: not found

I've reproduced the issue on separate machine with fresh volumes.

Container Details

please run `docker inspect --format '{{ index .Config.Labels "org.opencontainers.image.created"}}' octoprint/octoprint:<tag_you_are_using>' and list the date returned.

$ podman inspect --format '{{ index .Config.Labels "org.opencontainers.image.created"}}' docker.io/octoprint/octoprint:latest
2024-11-05T09:21:10.037Z
$ podman inspect --format '{{ index .Config.Labels "org.opencontainers.image.created"}}' docker.io/octoprint/octoprint:minimal
2024-11-05T09:21:10.037Z

To Reproduce
Steps to reproduce the behavior:

1. podman volume create octoprint
2. podman run --rm -v octoprint:/octoprint -p 8080:5000 --name octoprint docker.io/octoprint/octoprint:latest
3. Check on http://localhost:8080/ on the host that the UI works.
4. Pres Ctrl-C.
5. podman run --rm -v octoprint:/octoprint -p 8080:5000 --name octoprint docker.io/octoprint/octoprint:minimal
6. See /usr/local/bin/docker-entrypoint.sh: 8: exec: octoprint: not found

Expected behavior
No error.

I would expect the same behaviour as I get with fresh

$ podman volume create octoprint-minimal
$ podman run --rm -v octoprint-minimal:/octoprint -p 8080:5000 --name octoprint docker.io/octoprint/octoprint:minimal

just with the existing OctoPrint configuration and data preserved.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[shuhaowu]

Same problem for me. The issue is the instructions of mounting a volume at /octoprint. This doesn't work because the octoprint binary is installed at /octoprint/plugins/bin/octoprint. Instead, we should be mounting a volume to /octoprint/octoprint which has all the data.

Also need to ensure the volume mounted in is read/writable by user 1000 as that is what the default user is.

[adelton]

In docker.io/octoprint/octoprint:minimal the binary (well, the python script which does from octoprint import main and sys.exit(main())) is indeed at /octoprint/plugins/bin/octoprint, while in docker.io/octoprint/octoprint:latest it is in /usr/local/bin/octoprint. Is there a specific reason why the minimal image couldn't use the /usr/local/bin/octoprint location as well?

The problem with mounting the volume to /octoprint/octoprint instead of /octoprint is that the /octoprint/plugins directory now won't be on the volume, making it impossible to install any plugins, won't it?

Overall, when upgrading from one image version to a new one (even within :latest or withing :minimal), I'd expect the "core" OctoPrint to upgrade to the new version, while the plugins in volume to stay in their respective versions, and the admin having the ability to upgrade them after considering the impact of such upgrade.