Keyring file cannot be created

[hbierik]

Recently I upgraded my Synology DSM to latest version 7.2.64570. As a result of this upgrade the docker-icloudpd stopped working. So I decided to create a new container but now it looks like it cannot store the keyring file anymore.

I'm not sure if it is relevant but during the creation of the container I also discovered that in the latest Synology DSM it is no longer possible to mount a homes folder to a container e.g. /volume1/homes/Daphne/Photos (whilst this was possible in previous DSM). So this issue might be related to this change because as a result of specifying a user and user_id it apparently still tries to store the keyring file in /home/Daphne/.local/share/python_keyring.

[boredazfcuk]

It's always stored the keyring file into /home/${user}/.local/share/python_keyring. This script links that directory to /config/python_keyring so the keyring will end up there.

[hbierik]

What you describe is exactly what I see if I open a command shell from within the container. I was even able to create a file in that folder so that folder is writable which is also stated during the --Initialize execution but still I get the same errors that for some reasons it is not able to create the keyring file.

I even tried removing with removing the /home/Daphne/.local/share/python_keyring before executing the --Initialize but the result is the same and the symbolic link to /config/python_keyring is nicely recreated.

[boredazfcuk]

I found that it's possible to store the keying file directly in /config last night by setting a system variable XDG_HOME_DIRECTORY (or something like that). I've pushed a new container which sets this now, so none of the link stuff is required anymore and it will write directly to /config/python_container.

Give that a go and see what happens. One user has already reported that their container is getting further now, although, I don't know how you'd get around the other option of it not allowing home directories to be mounted... possibly by using the :z flag on the container mount, but that could also render the system inoperable, so not advisable unless you are capable enough to recover from that position. I don't have a Synology device so cannot test it myself.

[hbierik]

Thanks for trying a new method to store the keyring but apparently a Synology does not like your new method. For unclear reasons it now starts complaining about permission denied: '/root/.local as you can see in the screenshot.

Two clarify the home directory mounting. I decided to mount another folder to be used as home directory because Synology no longer allows a docker container to access the /homes/ folder so I simply switched to a folder which was accessible.

[boredazfcuk]

The latest container shouldn't even access ~/.local anymore due to the XDG_DATA_HOME variable being set. The keyring application uses this variable to define its working directory.

Another thing I notice in your log is that it is attempting to access /root/.local. The script should switch users so that it runs as the user specified in the user and user_id variables... unless you have those set to root and 0?

[hbierik]

It is working now. Yesterday I simply pressed the update button to upgrade my container to the latest version. But apparently with this update the new XDG_DATA_HOME variable is not automatically created.

This is how the environment settings of the upgraded container looked like:

After creating a new container the following environment settings appeared:

With the XDG_DATA_HOME variable set it is now able to store the keyring file. Many thanks for helping me!

[boredazfcuk]

Great stuff. Thanks for letting me know. Hopefully clears up the error for others too.