Restore configuration is broken about octoprint-docker

[LongLiveCHIEF]

The documentation for usage is there.

The stuff that's not documented that I mentioned is how to upgrade the new image to future versions of the new image, and we need the community's help with this due to the OctoPrint plugin ecosystem. That stuff was never documented before, and this image was never supported prior to this release. (There was also a statement to that effect in the README prior to this release)

Considering all that, any change was a breaking change, because it's impossible to know what users where doing.

We needed a stable baseline product to work from with a stable set of docs, so that I can field issues that come in over the first month or so and help determine what documentation is missing.

I'd recommend subscribing to the repo or to the releases from here on out so that you know when the documentation changes.

[ax42]

My issue here is not trying to restore a backup from a previously Dockerised version -- I'm trying to migrate from a Raspberry Pi installation to Docker using a backup/restore, and it's failing due to the pathname issue. Is there a workaround?

[ax42]

Observed the same.

[LongLiveCHIEF]

The latest version of the docker image is considered a breaking change from past docker images. I'm working with @foosel on the best way to publish this message.

The full changes are documented in the releases doc: https://github.com/OctoPrint/octoprint-docker/releases/tag/1.0.0

I'm also working on finalizing documentation on how docker users should go about standard things like installing plugins, upgrading, or backup/restores.

The best way with docker to backup/restore/upgrade is going to be the standard way of backing up container volumes with docker.

From this point moving forward, the OctoPrint native backup feature will likely work as expected again, however it will not be supported for docker users.

I have issue #22 open for tracking documentation on these pieces, and will close this issue in favor of that one.

If you want to help me explore ways of migrating backups from the old image to the new one, drop into discord.octoprint.org and i'll try to help you out. Volume mounting should be the way to go though, so I'd recommend going that route.

[frodoagu]

i know that, but for me the symlink to /home/octoprint/ is not working, i can't load the backup neither web interface nor docker volumes.. I guess that is because now the ~ is /root/ instead of /home/octoprint/
this is not working

  octoprint:
    image: octoprint/octoprint:latest
    restart: unless-stopped
    container_name: octoprint
    ports:
      - 5000:5000
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:octoprint.${DOMAIN}
      - traefik.port=5000
      - traefik.docker.network=http_network
    volumes:
      - ${VOLUMES_ROOT_PATH}/octoprint:/home/octoprint
    networks:
      - http_network

nor

  octoprint:
    image: octoprint/octoprint:latest
    restart: unless-stopped
    container_name: octoprint
    ports:
      - 5000:5000
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    labels:
      - traefik.enable=true
      - traefik.frontend.rule=Host:octoprint.${DOMAIN}
      - traefik.port=5000
      - traefik.docker.network=http_network
    volumes:
      - ${VOLUMES_ROOT_PATH}/octoprint:/root/.octoprint/
    networks:
      - http_network

[LongLiveCHIEF]

Correct. This is a breaking change, and that is one of those changes.

[LongLiveCHIEF]

Thanks for updating the comment to include your compose file. I notice that your port mapping is 5000:5000, which won't work with the new image. The container port is 80, so try doing 5000:80 (to keep traefik stuff intact)

[frodoagu]

thanks for your answer! i think the next time will be better to wait the documentation be completed to submit a breaking change
greetings!

[LongLiveCHIEF]

@ax42 I'm not really sure. backup/restore wasn't really meant to work as a way to migrate platforms. OctoPrint plugins are very tightly coupled with their installation environment. Your best bet is to hop on discord and start a discussion in the #support-misc channel.

Either this weekend or next, I'll be implementing the SUID/GUID features, which would probably resolve most of the path issues. If you do drop into the discord, I'm @CHIEFdotJS on there, and I'm going to be active all weekend and will help you work through that, as it will help me figure out some things to document as well as give me test cases for the SUID/GUID feature.

If you can't hop on discord, then my guess is that your best bet is to copy the configs, and then re-install plugins manually from thew new system. The new supported image includes a web-based config-editor, which will allow you to paste those configs in to the container environment. After that, just restart the container to restart OctoPrint with new configs.

[frodoagu]

My issue here is not trying to restore a backup from a previously Dockerised version -- I'm trying to migrate from a Raspberry Pi installation to Docker using a backup/restore, and it's failing due to the pathname issue. Is there a workaround?

i think one workaround could be extend the Docker image to create and set the default user to octoprint

i'm not sure anyway

[LongLiveCHIEF]

That's what the upcoming -minimal image will do, along with supporting dropping of privs by passing SUID/GUID env vars with the base image.

[frodoagu]

@LongLiveCHIEF the latest version still broken, please fix this!

[LongLiveCHIEF]

This is not broken, it was never intended to work for docker.