CrashPlan and CrashPlan Pro on Synology using Docker

Important Note
Code42 has removed headless functionality in the latest v6 release of CrashPlan for Small Business (formerly CrashPlan Pro). Existing docker instances may still continue to run for a while, but this ultimately marks the death of any sort of CrashPlan backup for Synology.
https://support.code42.com/CrashPlan/6/Get_started/Changes_to_the_Code42_app_in_version_6

I recommend using BackBlaze B2 with Synology’s Cloud Sync application. There are some drawbacks (e.g. you can’t cloud sync the same folders with different services), but ultimately it is fairly priced and works well.

Archive Content:
Synology introduced Docker to the DSM in version 5+, which has opened up new ways of running some applications in Synology. Not all Synology boxes have enough resources to run docker, check if your Synology NAS can run Docker here.  Using Mike Tabor’s excellent tutorial post I was able to get CrashPlan up and running on my 713+ DiskStation. However, his tutorial only covers the basic CrashPlan application, and not CrashPlanPRO. I’ve written up a quick and dirty guide to get CrashPlan or CrashPlanPRO working on docker in Synology.

Prepare the Synology NAS for Docker

  • Login to Synology, go to Package Center
  • Uninstall CrashPlan from Package Center (if previously installed)
  • Install Docker in Package Center
  • Connect to Synology via SSH as a user with Admin privileges

Get the latest Docker Images for CrashPlan or CrashPlanPRO

First, we will pull a CrashPlan or CrashPlanPRO image from docker hub.  Note that if connected via DSM6, we will need to start the session with “sudo su”, or add “sudo” before each of the docker commands:

If using CrashPlan

If using CrashPlanPRO:

Create and run CrashPlan container using the image.

If multiple volumes need to be specified, add another -v statement after the first one e.g. “-v /volume2/:/volume2”

If using CrashPlan:

If using CrashPlanPRO:

Wait until the container has fully started up (typically less than 2 minutes)

Get the GUID from CrashPlan

In the same SSH session, enter into a bash session for the container:

The command prompt will now take place inside the container. You may see an error which is safe to ignore for now: “ERRO[0000] Unable to connect to local syslog daemon”. In the bash session, enter the following command to get the headless key

It will output something similar to the following. The first number is the port used, 4243. After the comma, the guid key is listed, then the IP for the Synology NAS. In this example below, the “4fx72835-3fcd-4319-afd5-698212c77ba7” key should be recorded to connect to the system with CrashPlan from a desktop machine

4243,4fx72835-3fcd-4319-afd5-698212c77ba7,0.0.0.0

Update the workstation to connect to CrashPlan running in Docker

.ui_info

If using Windows, update C:\ProgramData\CrashPlan\.ui_info with the guid recorded in the command above, and the IP address of the Synology NAS. If on a Mac, the path is /Library/Application Support/CrashPlan/.ui_info.  For example:

4243,4fx72835-3fcd-4319-afd5-698212c77ba7,10.0.0.99

ui.properties

If using Windows, update C:\Program Files\CrashPlan\conf\ui.properties and ensure serviceHost is enabled and pointing to the Synology NAS. On a Mac, this path is typically /Library/Application Support/CrashPlan/conf/.ui_info.  For example:

serviceHost=10.0.0.99

Connect to CrashPlan

After connecting successfully to the CrashPlan instance, adopt a previous computer (if applicable) to ensure the backup history and settings are retained.

If you have large backup sets and memory needs to be adjusted, double click the CrashPlan logo in the top right of the program and apply a custom command. In the example command below, the memory usage is increased to 2GB in order to work with very large file sets. Do not increase this value beyond what is available on the Synology NAS.  More information on this command can be found here.

java mx 2048, restart

Troubleshooting

CrashPlan on Docker can’t see my files

Sometimes the mapping for the root volume doesn’t seem to stick for sub shares in the container. To fix this, stop the container and edit it in Docker. Add each share used in CrashPlan backups to the container and mount them the same way they were referenced originally. For example, if CrashPlan backs up files on a share named “Photo” on volume1, then add that share to the container with a mount path of “/volume1/Photo”.

CrashPlan Updated to v4.8 and now my docker image is broken

The following reply by reddit user ajr6037 has a solution: https://www.reddit.com/r/synology/comments/550806/best_crashplan_docker_image/d87beo9

Talking to my house – Amazon Alexa (Echo) and SmartThings

Amazon recently competed their Alexa/Echo integration with SmartThings after previously integrating a number of other home automation hubs like Wink and Hue. I jumped on it as soon as it was available in the Alexa iOS app.

Setting up SmartThings with Amazon Alexa (Echo)

As with other SmartThings integrations, the first step will request an OAUTH login to SmartThings, and allow the user to select which devices can be shared with Alexa. At this time, only switch type devices (including virtual switches) appear to be supported. Sensors, complex/multi-types like thermostats, and modes are not supported at this time. After selecting the devices to grant permission, run the discover devices command on Alexa to enables them in the app as well as Alexa voice control. Amazon Alexa also allows the grouping of different devices to make it easier to turn several switches off or on at the same time.

Amazon Alexa device groups SmartThings devices in Amazon Alexa

How well does it work?

As mentioned above, mode changes and phrases are not supported out of the box with this integration, so I’ve been using virtual switches and the “Big Switch for Hello Home Phrases” app (an example of usage here) to create switches that control the mode. So now I can say “Alexa, turn on goodnight”, which will trigger the virtual switch to run “Goodnight!” on SmartThings.

I’ve been using SmartThings with Z-wave switches to control lights and other items. The response time with Echo/Alexa has been quite good – a voice command takes effect in roughly a second. See the following video for a simple z-wave switch demo I recorded – note that Alexa seems to do well with natural speaking pace, rather than other systems which can sometimes hitch between keywords and commands.

Voice control has been a mixed bag over the last few years.  I have had mixed results from a number of different offerings.  However, I’ve been pleasantly surprised at how well Alexa does with voice commands. I’ve been yelling commands from all over the house for a couple of days and Alexa has yet to get a single command wrong. I’m very impressed so far.

Fixing CrashPlan 4.3.0 on Synology

CrashPlan Issue For Synology – Fixing the 4.3.0 update

If your Synology NAS can run docker, you may want to consider an alternative to the CrashPlan package. See here: CrashPlan and CrashPlan Pro on Synology using Docker

Note, see bottom of page for information on DSM 6 and CrashPlan 4.6.0

Recently CrashPlan updated to version 1427864400430, which broke the CrashPlan package Patters had created for Synology installations again. They then (July 2nd?) released 1427864410430 as well, which means that if your CrashPlan installation on Synology broke with version 1427864400430, you will need to upgrade, wait for it to break again, and then fix with version 1427864410430. In general the fix process has been the same over the last few breaks, and I’ve outlined those steps below for the latest version.

There is one major change introduced from CrashPlan. Starting with the 1427864400430 update, a guid (think of it as a key) is needed to securely log into the headless client. Thanks to Mathew Stocks, I’ve made those instructions available as well.

The log for the failing CrashPlan package would look something like this for a failing 1427864400430 upgrade:

Upgrades available at central.crashplan.com:443
Downloading a new version of CrashPlan.
Download of upgrade complete – version 1427864400430.
Installing upgrade – version 1427864400430
Upgrade installed – version 1427864400430
CrashPlan stopped, version 4.2.0, GUID 559750658046558476

If the package was attempted to start again, it would write a line similar to the following, and then stop:

Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1427864400430.

Note that the following instructions are for the 1427864410430 upgrade, which is the latest (as of July 2nd, 2015) update. If your Synology didn’t make it to this version, run the following steps, but substitute “1427864400430” where there are any references to “1427864410430”.

Connect as root to SSH

First, connect to Synology using SSH and the root account (uses admin password).  Connecting as the admin account will give you permission failures!

In SSH, run commands to extract the update

In SSH, run unique command to cleanup the package

The next command will be different for everyone, as part of the file path is randomized.  In this case, you will need to see what your path is first by running ls, and then editing the second statement below, replacing whatevervalue with the rest of  your path:

Start CrashPlan package, check log

After the above completes, you should be able to start the CrashPlan package again in Synology and get it running once more. The log should show:

CrashPlan started, version 4.3.0 GUID 559750658046558476

Get the headless key from the .ui_info file

While connected to SSH as root, run the following command to get the headless key file. The funky formatting of this command is because the file does not contain the special newline character:

The command will output a line similar to the following (everyone’s will be different):
4243,13d436c0-230a-4242-b258-574e60e62a9f

Update .ui_info on the computer connecting to Synology

On the computer where you are connecting to CrashPlan on Synology, go to the .ui_info file under the CrashPlan directory. NOTE: I had to manually upgrade my computer’s version of CrashPlan (via https://www.code42.com/crashplan/thankyou/) in order to see the .ui_info file.

Typically on Windows, this will be found under:
C:\ProgramData\CrashPlan\.ui_info

Or on a Mac in the following location (need to have finder set to show hidden files):
/Library/Application Support/CrashPlan/.ui_info

Enter in the new key in the file, replacing the current value, and save it. You should now able able to connect to the headless client. Note that you may need to also update the values in ui.properties again if you had to upgrade CrashPlan.

CrashPlan 4.6.0

There are some tools referenced in the comments for this page which might make upgrades easier for some people. But I’ll also give the latest files & paths using the original instructions above – the following commands can be used for v4.6.0:

unzip -o /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "*.jar" -d /var/packages/CrashPlan/target/lib/
unzip -o /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "lang/*" -d /var/packages/CrashPlan/target/

Find latest package folder:
ls -l /var/packages/CrashPlan/target/upgrade/1435813200460_382.*

Replace the whatevervalue with the folder name:
mv /var/packages/CrashPlan/target/upgrade/1435813200460_382.whatevervalue/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435813200460_382.whatevervalue/upgrade.sh.old

Synology DSM v6

I don’t recommend upgrading to v6 at this time (March 2016) if you do not have an Intel based CPU in your Synology NAS as there have been issues reported with the java packages in the comments here as well as on Patter’s page. If you do have an Intel based CPU you will need to use 7z commands on DSM6 instead of zip commands. Examples for CrashPlan 4.6.0:
sudo 7z e -y -o/var/packages/CrashPlan/target/lib /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "*.jar"
sudo 7z e -y -o/var/packages/CrashPlan/target/lang /var/packages/CrashPlan/target/upgrade/1435813200460_382.jar "lang/*"

Fixing CrashPlan 4.2.0 on Synology after DSM 5.2 update

The latest round of updates from CrashPlan (4.3.0) has broken the CrashPlan package on Synology again. Please see http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/ for the newest instructions.

Archived information for 4.2:

After installing Synology DSM 5.2, CrashPlan recently pushed an update (4.2.0) which broke the CrashPlan package Patters had created for Synology. The log for the failing CrashPlan package would look something like this:

CrashPlan started, version 3.7.0, GUID 559750658046558476
Upgrades available at central.crashplan.com:443
Downloading a new version of CrashPlan.
Download of upgrade complete – version 1425276000420.
Installing upgrade – version 1425276000420
Upgrade installed – version 1425276000420
CrashPlan stopped, version 3.7.0, GUID 559750658046558476

If the package was attempted to start again, it would write a line similar to the following, and then stop:

Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1425276000420.

This seemed to be similar to the previous issue seen in 3.7.0, so I used the following steps to fix crashplan on my synology box: Note that this will likely be fixed by Patters soon, this is just a workaround if your CrashPlan install has stopped as a result of the 4.2.0 update.

Connect as root to SSH

First, connect to Synology using SSH and the root account (uses admin password).  Connecting as the admin account will not give you enough permissions.

In SSH, run commands to extract the update

In SSH, run unique command to cleanup the package

The next command will be different for everyone, as part of the file path is randomized.  In this case, you will need to see what your path is first by running ls, and then editing the second statement below, replacing whatevervalue with the rest of  your path:

Start CrashPlan package, check log

After the above completes, you should be able to start the CrashPlan package again in Synology and get it running once more. The log should show:

CrashPlan started, version 4.2.0 GUID 559750658046558476

Fixing CrashPlan on Synology after the 3.7.0 update (Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1388728800370. )

If you recently upgraded to DSM 5.2 and had CrashPlan break, this is likely due to the CrashPlan 4.2.0 update. Please see http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/

NOTE: This manual fix should no longer be needed after the 0029 update from Patters:

0029 Updated to CrashPlan version 3.7.0, improved detection of temp folder (prevent use of /var/@tmp), added support for Annapurna Alpine AL514 CPU (armhf) in DS2015xs, added support for Marvell Armada 375 CPU (armhf) in DS215j, abandoned practical efforts to try to support Code42’s upgrade scripts, abandoned inotify support (realtime backup) on PowerPC after many failed attempts with self-built and pre-built jtux and jna libraries, back-merged older libffi support for old PowerPC binaries after it was removed in 0028 re-write

Archive content:
CrashPlan recently pushed an update (3.7.0) to all clients which broke the CrashPlan package Patters had created for Synology. The log for the failing CrashPlan package would look something like this:

CrashPlan started, version 3.6.4, GUID 574956158631543214
Upgrades available at central.crashplan.com:443
Downloading a new version of CrashPlan.
Download of upgrade complete – version 1388728800370.
Installing upgrade – version 1388728800370
Upgrade installed – version 1388728800370
CrashPlan stopped, version 3.6.4, GUID 574956158631543214

If the package was attempted to start again, it would write a line similar to the following, and then stop:

Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1388728800370.

After some investigation by Stig, Casper, and Harv on the comments for the package a working solution was found to manually install the update files and disable the failing upgrade.sh file. Note that this will likely be fixed by Patters soon, this is just a workaround if your CrashPlan install has stopped as a result of the 3.7.0 update.

1. First, connect to Synology using SSH and the root account (uses admin password).  Connecting as the admin account will not give you enough permissions.
2. Run the following commands:

 
3. The next command will be different for everyone, as part of the file path is randomized.  In this case, you will need to see what your path is first by running ls, and then editing the second statement below, replacing whatevervalue with the rest of  your path:

4. After the above completes, you should be able to start the CrashPlan package again in Synology and get it running once more.