Calibre loses configuration upon container restart

[rcarmo]

---

Expected Behavior

I should be able to restart the container without losing the Calibre configuration

Current Behavior

When I restart the container, Calbre has lost all its configuration (library location, e-mail server settings, UI layout preferences, e-reader model, etc.) and I have to reconfigure everything again, even though I have a persistent /config folder and no permissions issues.

Steps to Reproduce

1. Deploy container as linuxserver/calibre:latest, with /config correctly mapped to the Synology filesystem and a separete /books volume with exactly the same permissions
2. Configure once.
3. Restart the container in an attempt to diagnose #54 and #51
4. Calibre displays the startup screen again:

Environment

OS: Synology DSM CPU architecture: x86_64 How docker service was installed:

Standard Synology package

Command used to create docker container (run/create/compose/screenshot)

Screenshot of Synology GUI, since it keeps getting requested (note that PASSWORD is set and visible, which is a bad practice):

Volume section, which worked in the previous base image:

Docker logs

Docker log UI in Synology

[j0nnymoe]

Delete the 'HOME=/root` environment variable and this should fix it.

[rcarmo]

I just tried that, fhanks, but it does not work. Calibre comes up again showing "/root" as the location for my books, and seems to completely ignore /config no matter what I do.

I've checked the modification dates for the docker/calibre folder I have mapped to /config and the only files that were modified today are Xrdp logs, so I'm assuming it's writing the configuration someplace else:

(edit: in case there are further doubts, yes, I checked inside .config. .local. etc. newest changes are a week old, before updating to the new base image)

[rcarmo]

I have been digging around a bit inside the new container image, and I think the init script has a bug, because of the following.

This is what I can see when I restart the container and Calibre is auto-started. Note that it is possible to get a terminal window going now (not sure if by design or just leaving Openbox with defaults, but I'll skip the possible security issues for the moment), and that I can see what file descriptors the first instance of Calibre tries to open (or, rather, the ones it has open that very moment):

The interesting thing is that if I kill that Calibre instance and start a fresh one from the terminal the new one does, in fact, start correctly and opens the right files from the right places:

So the configuration is now persisted, but the initial Calibre instance does not even try to get it for some reason - which leads me to the conclusion the init script is flawed somehow.

(Also, at least now I can try to rebuild the rather complex configuration I had for the previous base image, since that got overwritten somehow during all these tests and I will need to recover it from a Synology snapshot...)

So please check what is going on when the initial instance is launched. I can try to strace the process or figure out its starting environment, but I suppose more testing is required at your end...

(edit: fixed second image)

[aptalca]

Delete the var HOME=/root and recreate the container.

https://github.com/linuxserver/docker-calibre/issues/48#issuecomment-823335892

[rcarmo]

Delete the var HOME=/root and recreate the container.

#48 (comment)

Maybe it wasn't obvious, but I already did that. Twice.

(Synology has an option to "clear" the container in the UI that I use upon every update, which does a docker rm).

[j0nnymoe]

Fresh pull of this container has the correct home dir: Just testing the restart issue.

[j0nnymoe]

Just tested a fresh deployment here and all is ok. With the Synology GUI you need to be deleted the container then recreate it manually with the newest images you pull.

[j0nnymoe]

[rcarmo]

Delete the var HOME=/root and recreate the container. #48 (comment)

Maybe it wasn't obvious, but I already did that. Twice.

(Synology has an option to "clear" the container in the UI that I use upon every update, which does a docker rm).

Maybe my original point did not get across. I already did that.

[aptalca]

As much as we would like to take your word for it, we can't. Post docker arguments and logs as requested. The one screenshot you posted shows the car incorrectly set as HOME=/root. Also make sure you pull the latest image before recreating the container.

Plenty of syno users here and they are all able to retrieve the logs and arguments with no issues.

[j0nnymoe]

Delete the var HOME=/root and recreate the container. #48 (comment)

Maybe it wasn't obvious, but I already did that. Twice. (Synology has an option to "clear" the container in the UI that I use upon every update, which does a docker rm).

Maybe my original point did not get across. I already did that.

You need to be deleting and recreating the container with the latest image pulled. I did this on our syno box and it's worked fine.

[rcarmo]

You don't need to delete the container. If you right-click on it and do "clear", Synology does a docker rm. However, in my case, that has not cleared up the issue yet. I will try pulling the image again, but your debug step is equivalent to mine (except that I don't have to re-enter the config).

[j0nnymoe]

Issue is, it's not clearing the environment variables like you would expect with docker-compose which is why your HOME shows /root instead of config.

[rcarmo]

I have already removed that as well. Please read the comments more thoroughly.

On 8 May 2021, at 18:30, j0nnymoe @.***> wrote:

Issue is, it's not clearing the environment variables like you would expect with docker-compose which is why your HOME shows /root instead of config.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/linuxserver/docker-calibre/issues/55#issuecomment-835438844, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC7327EMBYA3MQRQPRGVLTTMVYKZANCNFSM44NJIUPQ.

[j0nnymoe]

Yea I am reading them 😊

[j0nnymoe]

Try recreating the container without doing the "clear" option. This is an issue with how the synology docker gui works and not the container. I've confirmed the container retains its settings.

[rcarmo]

I have already done that, so I am now waiting for my NAS to reboot.

On 8 May 2021, at 18:34, j0nnymoe @.***> wrote:

Try recreating the container without doing the "clear" option. This is an issue with how the synology docker gui works and not the container. I've confirmed the container retains its settings.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/linuxserver/docker-calibre/issues/55#issuecomment-835440203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC7322U6WXU7URNCYED3W3TMVYZDANCNFSM44NJIUPQ.

[pparedes1]

I was having this same issue on my synology and had not noticed that the container's HOME variable was pointing to /root so I had to delete and recreate the container (as other have suggested). Actually I re-created the container using docker-compose but had to change all my variables to the minimum. The OP perfers not using docker-compose and seems to be having issues with either re-creating the container or his configuration folder that might have been messed up with the upgrade. Two suggestions:

1) Create a new blank config folder or just rename the current docker/calibre folder and re-create docker/config folder

• You can go through the set up once and close down the container and restart. If your settings are saved you can move things like plugins from your renamed config folder as needed.

2) Confirm the details of your container by sharing the parameters for the running container. If you have ssh access, can you post the details of the following command?

docker run --rm -v/var/run/docker.sock:/var/run/docker.sock assaflavie/runlike calibre-test

This assumes the name of the container is 'calibre-test' per the screen shot but you can change name below if it's called something else.