How to run CrashPlan 4.3 on a NAS (after the update “broke” it)

This is somewhat off-topic on this blog, but hey, I’m not gonna start a new blog for this.

Problem

Here’s the problem that I’m addressing in this post: since a couple of weeks, when CrashPlan 4.3 was released (and apparently updated itself automatically on my machines), I haven’t been able to connect to the CrashPlan installation on my NAS (a ReadyNAS Ultra 2). Whenever I started the CrashPlanDesktop.exe that is supposed to connect to the CrashPlan engine running headless on the NAS it just got stuck on the CrashPlan splash screen and nothing happened. The CrashPlan-engine itself was running fine and was doing its backup jobs as it always did. But I couldn’t access the interface anymore as I have done for years before. If you’re reading this, you probably know what I’m talking about because you have a similar issue.

If you are looking for instructions how to install CrashPlan on a NAS, this is not the post for you. This post assumes that all that has already been done a long time ago. If you want to get started, I suggest to google and make sure you find a post that is explicitly written for CrashPlan version 4.3 or later, precisely to avoid the kinds of issues that this post deals with. (Personally, I followed these instructions at the time, but they may be obsolete now)

So if you’re still reading on, you may also already have have found some information about how to fix this issue on the Synology NAS, but if you have a ReadyNAS like me, you can’t be sure that following those steps will actually help you. And I thought that it was a pretty complicated procedure, I tried to find a more promising way.

This comment by user sarme gave me hope that there is an easy way out: it simply stated that all s/he needed to do was “to copy the token from “‘/var/lib/crashplan/.ui_info’ and put it into ‘C:\ProgramData\CrashPlan\.ui_info'”. This is indeed very easy, but I was unsure whether I should just go ahead and do it, since the files in the ProgramDate\CrashPlan folder were obviously used by the local crashplan installation on my PC too, while I was just trying to fix the one on the NAS. And since there was all kinds of other information out there, especially that you’d need to identify which ports your headless CrashPlan is running on, it still took me a while to solve things. Now it’s fixed (as far as I can see) and that’s why I’m writing this post.

Solution

So what I needed to do to fix things was indeed to simply copy the content of “/var/lib/crashplan/.ui_info” on your NAS into “C:\ProgramData\CrashPlan\.ui_info” on your PC. It’s just a 41 character string in plain text. Now, the first problem I faced was that I couldn’t find the .ui_info because I didn’t see that it was in “C:\ProgramData…” and not “C:\Program Files\…”  (It was late at night). But of course that would never happen to you, so just forget about it.

Next thing was: careful as I am, I wanted to rename the existing .ui_info on my PC and create a new one with the token from the NAS, but Windows doesn’t seem to allow me to create a file starting with a dot (for windows, it’s just a file-type without a file name). So I ended up making a copy of the file as a backup and then opening the .ui_info in Notepad++, deleting what was in it and pasting in the token from the .ui_info on the NAS.

Next problem: I couldn’t save the file because it was being accessed by another program. So I had to completely close down CrashPlan on my PC (including the CrashPlantray.exe)  and then I was able to save.

When I then started the CrashPlanDesktop.exe (the one configured to connect to my NAS, not the one for my PC) it immediately connected as it should and I was relieved.

Open questions

I am still not sure what exactly happened, especially, I’m surprised that CrashPlan apparently managed to update itself on my NAS without me doing anything. And I also don’t understand what this thing about having to take care of the ports now is all about. Why was I able to solve things without doing anything related to ports? In fact, when I looked for the app.log file as described here, I did not even find it. Anyway, I’m not worried as long as things are working again. Just curious.

Advertisement