Docker not persistent
hakarune opened this issue · 14 comments
No volumes expose to create a persistent container that doesn't loose info on server reboot or docker recreate/upgrade.
Exposing /etc/cups volume could allow mapping and persistent behavior or symlink the require .conf files to a separate portion of the docker that is exposed
You can just use the --mount option on the command line if you want to mount /etc/cups as a volume.
I'm not sure to understand the issue here, can you elaborate?
Hi I had and still have the same issue! I did open an issue about it, but just didn't ever get it to work! Mounting /etc/cups as a volume causes the docker to not start! My 30 or so other docker images all mount config files fine and I tried 10 or so other cups docker images all would persist their data but wouldn't work for other reasons. So I resigned myself to having to run hp-setup and re-setup my printer everytime I reboot my server and then re-install printer drivers on any computer I use them on! Also had to disable updates for this docker and not back it up! It's a pain in the arse to be fair and would like a fix for the issue?
Can you elaborate a bit more on what exactly is the issue and why you cannot fix it using the mount option on the CLI? (share the error message or the logs, explain exactly what's going on, etc.)
Are you sure that the directory that you are mounting actually contains the required configuration files?
Please consult Docker website if you're not sure about how volumes works.
You can also have a look at this comment if you need some help with the setup.
Also, I am not sure to understand how hp-setup or re-setup is related in any way with the configuration of the cupsd service. Aren't these tools that you launch on your client machines?
Hi, thanks for quick response! Sorry I'm not an expert and don't use command line much! I'm using Unraid and it uses a template system, this is the docker run command it generates:
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='cupsd' --net='host' -e TZ="Europe/London" -e HOST_OS="Unraid" -e 'TCP_PORT_631'='631' -v '/var/run/dbus/':'/var/run/dbus/':'rw' -v '/mnt/cache/appdata/cupsd/log':'/var/log':'rw' -v '/mnt/user/appdata/cupsd/config/':'/config/cups':'rw' -v '/mnt/user/appdata/cupsd/hp/':'/config/hp':'rw' --device='/dev/bus/usb/' 'olbat/cupsd'
You'll see that I created 2 volumes for config files, I tried copying the contents of /etc/cups and /etc/hp into the volumes and i then changed the volume mounts to -v '/mnt/user/appdata/cupsd/config/':'/etc/cups etc. But the container wouldn't start!
You have to run hp-setup in the docker container and accept the license for the proprietary driver otherwise cups can't connect to the printer!
Here are some other containers that used to work but have got to old and I think wont connect to latest linux kernel, or didn't have drivers or avahi etc, but they persisted data without any problem: jacobalberty/cups, tigerj/cups-airprint, gmkey/cups-avahi-airprint, mnbf9rca/cups-google-print
Hope you have time to have a look at what they've done differently, so that config can be persisted.
Thanks,
Tim
Again, I think that the issue here has absolutely nothing to do with this image but rather with your runtime environment and the tool that you are using to run the container. I don't know Unraid but I suggest you to start with something simple like the CLI tools I mentioned above to understand what your issue is and fix it.
There is absolutely nothing in this image preventing you from using a volume to mount the configuration file. You need to dig a bit deeper and get a better understanding of Docker volumes, filesystem permissions, etc.
Providing support about Docker is way out of the scope of this repository. I suggest you to reach out to the Docker community if you need some help, for example on the Docker forum.
Of course, you are free to make a copy of the Dockerfile and patch it to fit your needs, possibly by following some of the examples you mentioned.
But the container wouldn't start!
That type of feedback doesn't really help with the debugging process. If you create other bug reports in the future (on this repository or any other places), I suggest you to provide some logs or error messages to help people understand where your issue is coming from.
man, do bind volume support and that's it.
what is not clear?
raised your image.
sketched printers into it.
deleted the container, for example when updating, or I want to transfer the container.
and the data and my entire setup was deleted along with the deletion of the container.
And with the volume, the data is on the host machine and that's it.
Hi Luc, Ok firstly there is nothing wrong with my runtime environment or the tool I use to run docker containers! As I said I currently run 24 containers and this is the only one that is a problem! I see someone else has joined this thread with the same issue!
I would have posted logs if I had them but it was months ago that I last tried this, so I had time last week and had another go! I ran the command as I posted before and then used docker cp to copy the files from etc/cups and etc/hp to the newly created volume on my host machine, so far so good. Then I stopped the container and changed the volume mapping from the host volume direct to /etc/cups and /etc/hp, this is where it failed to start before, but this time it worked!! But... (I know always a but! :) ) On a restart or update of the container it stops working, the printer is still there in the GUI but you get "filter failed" error, this error is because you have to accept the hp licence again! So when I run hp-setup in the console I only need to go as far through the setup as to say yes to the licence and can quit there as it has remembered the rest. Do you know where hplip stores the licence? Must be somewhere other than /etc/hp?
Cheers,
Tim
man, do bind volume support and that's it.
And with the volume, the data is on the host machine and that's it.
I'm not 100% sure to follow who you are talking to but I agree, just using a volume should solve the issue.
@mothy-tim I'm very not familiar with HP proprietary drivers (do you even need them?) but I guess you're right and they're writing some files in a directory that you do not mount as a volume.
Tools like strace might help you to find exactly which file are written by this tool when you execute it.
You could also create an image out of your working container once you're done doing some additional setup by using docker commit.
I agree, just using a volume should solve the issue.
Also, just in case this was not clear enough in this comment → no patch whatsoever is needed on this image to support volumes.
To use a volume with this image, you can just use the correct options when invoking the Docker CLI tool.
As mentioned before, all you need to set this up is to make an initial copy of the configuration files to the host (e.g. using docker cp) and correctly set the permissions for them to be readable by the cupsd daemon from the container (that most probably runs as root anyway, to be double checked).
Is the problem solved / Can I close the issue?
No answer, closing the issue.