/var/crashplan/id/.ui_info does not persist over time and remote connections fail

[Jaco1960]

According to the comments in entrypoint.sh the idea is that the account info for remote UI connections found in /var/crashplan/id/.ui_info pertains over time. This is actually not working in this way. When the docker auto-updates crashplan and/or is restarted the authentication token in the file is updated and the service host IP is changed to 127.0.0.1, effectively no longer allowing to remotely connect to the crashplan engine. I can change the service host IP back to 0.0.0.0 by modifying the my.service.xml which allows me to connect again using a new authentication token. Is there a way to make the authentication token and service host IP pertinent?

[blankster]

I've exactly the same problem and no "chmod" attempts worked. In theory it should be possible to set the immutable attribute IMHO but this command is "inside" the docker not available. Any ideas?

[JrCs]

Retrieve the token before trying to connect to the container.
This is what i do to connect remotely to the GUI.
Do a ssh host 'docker exec crashplancontainer cat /var/crashplan/id/.ui_info' to retrieve the current token.

[blankster]

Thanks a lot for your feedback @JrCs and in general your fantastic work!

I'm not a docker expert, so I didn't know how to access stuff inside the docker container beside starting a bash according https://miketabor.com/run-crashplan-docker-synology-nas/ which is mentioning your docker container.

Questions:
1: As Synology needs regularly updates and often restarted I need to use often a new "access token" to connect the client on my PC with crashplan on the server. I know now how to get this token/hash as easy as possible but still don't know a way to keep the token/hash the same. Is this default behavior of Crashplan and can't prevented because of it's architecture or do we need still to find a way to make the file .ui_info immutable to keep the same token/hash?
2: What's about the IP? 127.0.0.1 needs also to be changed every time to 0.0.0.0 to allow access? Isn't this possible to "lock" it?

Disclaimer: Mike's guide is only a startinig point. He forgets to mention quite a few things:

• Docker needs to have access to the volumes/shares what needs to be set in the docker container settings
• .ui_info needs to be edited, because it used the IP 127.0.0.1 what allows only local connections (costed me hours to find this out) and needs to be modified as mentioned above to 0.0.0.0 to allow for example the connection from PC to the headless Crashplan instance on Synology
• .ui_info needs to be read out each time to get the right token/hash otherwise is access also impossible and this hash needs to be set each time (after every restart of the docker container) on the PC too

[JrCs]

@blankster
1: you can't stick the token to a "default" value. It's crashplan behaviour and you can't prevent it for create a new one.
2: i think you can replace the listen ip from the crashplan GUI from 127.0.0.1 to 0.0.0.0.
You can also publish the 4243 port (the port of the GUI if i remember well) to your NAS ip with adding the flags -p 4243:4243to the docker run. Then you can connect directly to crashplan using your NAS ip.

[blankster]

Thanks for your answers @JrCs!

1. I can't find it at https://support.code42.com/CrashPlan/4/Configuring/Using_CrashPlan_On_A_Headless_Computer but I'm quite sure I even read on Crashplan's information pages that at least under windows it's possible to set .ui_info to read-only (it's clear that this is only the client). On windows this works with the read-only attribute. On Linux/Docker chmodding doesn't help but as far as I've read there should be the command "chattr" to make it immutable (via +i flag). Did you ever tried to lock it via this approach? Is this not possible because of security or what's the point here?
2. I didn't found this setting and think you mean:
   

The setting itself I only can find in .ui_info to change (and beeing forced to restart the crashplan deamon/service inside the docker). I know there would be also the possibility to create a SSH tunnel to the NAS and connect then "localy" to it, but if possible I try to keep the things "easy"...

[JrCs]

1. Never try the chattr option. Can you try ?
2. For the GUI perhaps we need to modify the XML file. In my case i'm using a ssh tunnel to get the value of .ui_info and to connect to the GUI port of crashplan, but i didn't use windows so it's easier.

[JrCs]

Is it working now with the latest docker image ?

[haysclark]

@JrCs I am having a similar issue. How are you restarting your containers if they need to be shutdown. For instance, I had to add another virtual drive to be backup. Are you just commiting the docker image and rebooting the previous commit with new params? or can you start from scratch utilizing the state in /var/crashplan?

I am still debugging the issue. But in general, I was hoping that the /var/crashplan folder would persist all critical setup data, but despite the data persisting a fresh crashplan docker container does not boot up and work. IT looks like some value in /var/crashplan/id/.ui_info get overwritten. I often see a new GUID, and changed port number.

[JrCs]

If you use the volumes describe in the README all the critical data must be persist on the host, and you can restart the container anytime you want.
But be sure to use the latest version (use a docker pull to be sure)

[estiller]

I have just encountered this issue as well. Whenever I have to stop the container in order to add mounted volumes, the .ui_info file on the server is modified after restart with a new token, and the ip 0.0.0.0 is changed to 127.0.0.1.

[estiller]

Well, after some more research I figured out at least my issue. I am posting here since it might be related and help someone else.
I had an issue where whenever I had to stop the container in order to add mounted volumes, the .ui_info file on the server was modified after restart with a new token, and the ip 0.0.0.0 was changed to 127.0.0.1. This caused the experience to be pretty bad.
It turns out that this happened because after installing the docker container I adopted the backup set of an older version which was configured in a conventional way (not headless). This caused the "my.service.xml" file to be restored and have the tag set to 127.0.0.1, disallowing remote connections. The solution was to edit this file and set the tag to 0.0.0.0. Once this is done and the container is restarted, the .ui_info file is overwritten with correct data and is not changed again afterwards.