When/how did you get any errors? I can’t reproduce them.
I did notice that the shutdown script does not work how it should … it no longer prints to log to stdout for tracing by docker logs
The errors occurred when I tried to start a new container or restart with different runtime parameters. Cannot remember exactly. I was grinding through and not paying as much attention as I should. I mostly use a docker-compose file to create the container. It’s possible that I fat fingered something procedurally and ‘fixed’ something that did not need fixing.
I can go back and try again with the original syntax later tonight / tomorrow and see if I can reproduce. The error message was something about unexpected } – and mentioned the file openLuup_reload_for_docker so that’s what led me to suspect the syntax on the function definition.
One other thing - and I need to dig a little more: the volume declarations in the Dockerfile … My understanding (could easily be flawed) is that they end up being created at container creation time with a random named (for the volume). But what happens if you later delete the container and create a new one - do not these volumes get recreated? If that’s the case the date (from the previous container ) would not carry over to the new one. So I’m thinking it may be better to create named volumes the docker run command, or mount bind to folders on the host. Thoughts?
Nevermind, I linted the script(s) and they had errors anyhow. No curly braces though.
Your understanding of volumes is more or less correct. Volumes are created automatically by Docker when the container starts - at least for the volumes specified in the Dockerfile, unless a mount or bind is specified for the volume. This is a so called unnamed volume. The volumes however are not deleted when the container is removed.
So your data will be preserved. Just hard to find.
Thing is that the volumes that are created by Docker at startup of a container, are unnamed, so hard to recognize. You can, as I do in the composefile (or using docker volume create) manually create a named volume to mount with a container. The difference is that Docker only copies the data from the image to the volume in case of creation of an unnamed volume. When you bind or mount a volume, Docker does not do this.
At least, that was the case. Apparently, recently Docker changed. It also copies data to a newly created empty volume.
And that is what the composefile is using. It creates empty volumes for ludl (/etc/cmh-ludl/), logs and backups. At startup, the contents of the openLuup image is copied into the ludl volume. As long as this volume is used with a container, the data should be preserved. Updating openLuup in that case should happen via the auto-update feature of openLuup itself, not by installing a new image. A new image is only required to get environment bufixes and security updates.
The script openLuup_reload_for_docker had curly braces in the function declaration. Are we talking at cross purposes ?
You can, as I do in the composefile (or using `docker volume create`) manually create a named volume to mount with a container.
I was not using your compose file – so I best go take another look !
Again - thanks for taking this on and doing such a great job !!!
I meant to say that the linter did not complain about curly braces, but that there were a few other issues. One of which was the use of the keyword ‘function’, which apparently is allowed in bash, but not in sh.
Hi @vwout
Looking at your username it?s clear which one is yours, but it was interesting to see other Docker options for openluup listed too.
slightlyaskew/openluup
DOCKER - openLuup Container
vwout/openluup
DOCKER - Automated Build Ready to use openLuup environment with AltUI based on Debian with mountpoints for custom plugins.
airedale/openluup
DOCKER
I’m going to use Container Station on my QNAP NAS to install the Docker image, I believe the approach will be similar to Synology’s Container Station too ?
Are there any specific commands I should look to enter when creating the Openluup container?
Yep 
I decided to roll my own image since the others are big, undocumented and not updated recently.
The image is usable without any particular configuration, though you do want to map at last the exposed port 3480 to be able to access AltUI.
I don’t see this being configured in the screenshots. Maybe it is automatic on Qnap (I don’t own one), but you might want to check this in the advanced settings. The container does not have any other configuration that you must set. And I think you can reduce the amount of memory. OpenLuup does not need 8GB
There should not be that much difference between using it on any Docker host. The only thing is that to use persistent data stores for openLuup, logs and backups, you probably have to use the command line, just like on Synology. Qnap also does not seem to offer the use of named mounts via their UI.
Hi guys,
I’m running openluup in vbox now and want to migrate to docker, because of some strange behavior in openluup/AltUI. What is the easiest way to restore my setup in the docker container?
I don’t want to copy all files, because then I will probably have the same issues? The issue seems related to AltUI.
I know I need the user_data.json of course, but that is probably not enough.
Any suggestions?
Most likely reason for strange behavior is a rogue plugin. Do you have plugins installed?
Migrating configuration is the easy part, your dependency on plugins is the complicating part here since there is no way to automatically install plugins.
When you have the user_data.json, you can provide this to docker when you start the container for the first time, see the documentation on GitHub - vwout/docker-openluup: Dockerized openLuup environment with AltUI, or in the docker-compose file at docker-openluup/docker-compose.yml at master · vwout/docker-openluup · GitHub.
Openluup will import the data provided by the user_data.json as specified in the environment variable USER_DATA_JSON into its configuration. Any functionality depending on plugins won’t work until the plugins are installed.
I don’t know whether configuration related to not available plugins will survive, or when the configuration is kept when plugins are installed. This will require some experimentation.
If you know which plugins you need and which files are related to these plugins, you can try exporting these from vbox and storing them in a directory. Bind this directory as /etc/cmh-lu/ and openluup will load the plugins right from the start.
The good news is that you can try as many times as you want. As long as you keep your vbox configuration as is, you can recreate the openluup container as many times as you want.
I would recommend using a volume for at last the openluup environment, that is /etc/cmh-ludl/.
[quote=“vwout, post:30, topic:199649”]Most likely reason for strange behavior is a rogue plugin. Do you have plugins installed?
Migrating configuration is the easy part, your dependency on plugins is the complicating part here since there is no way to automatically install plugins.
When you have the user_data.json, you can provide this to docker when you start the container for the first time, see the documentation on GitHub - vwout/docker-openluup: Dockerized openLuup environment with AltUI, or in the docker-compose file at docker-openluup/docker-compose.yml at master · vwout/docker-openluup · GitHub.
Openluup will import the data provided by the user_data.json as specified in the environment variable USER_DATA_JSON into its configuration. Any functionality depending on plugins won’t work until the plugins are installed.
I don’t know whether configuration related to not available plugins will survive, or when the configuration is kept when plugins are installed. This will require some experimentation.
If you know which plugins you need and which files are related to these plugins, you can try exporting these from vbox and storing them in a directory. Bind this directory as /etc/cmh-lu/ and openluup will load the plugins right from the start.
The good news is that you can try as many times as you want. As long as you keep your vbox configuration as is, you can recreate the openluup container as many times as you want.
I would recommend using a volume for at last the openluup environment, that is /etc/cmh-ludl/.[/quote]
Yes I have multiple plugins installed. I understand that will be the tricky part. Maybe I will try to migrate in the near future, but there is no hurry anymore, because I have mij vbox running quite well again.
Thanks for the docker! I will definitely be using it in the near future. Probably when someone else has migrated successfully with plugins 