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.

Join the Conversation

191 Comments

  1. Thanks for the great instructions to restore crash plan backup on my disk station. First use of terminal and ssh made very easy. time to learn more uses of terminal now.

  2. Just want to confirm that with the small adjustment to put quotes around *.jar this fix worked great. I ran:

    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar run.conf -d /var/packages/CrashPlan/target/bin/
    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar lang/* -d /var/packages/CrashPlan/target/
    And renamed the upgrade.sh to upgrade.sh.old

    After that I could start the package again.

    Thanks for this great guide.

  3. Just a side comment: Crashplan 3.7.0 changed the way the ui.property file is handled on OSX. Before most used the approach to have a copy of the CP application bundle and changed the ui.property file in there. so you have multiple CP copies pointing to all your Synology NAS boxes or other servers you want to manage the CP service remotely.
    No dice with 3.7.0 anymore if you have more than one CP running.
    Now there is a copy in ~/Library/Application Support/CrashPlan/ui.properties that is written by the client every time it exits. And of course it has the higher prio than the one you keep in the bundle. So if you go mad (like me) when you try out your three copies of CP on your Mac and all connect to the same box despite having different ui.property files in the app bundle: look no further and go to ~/Library/Application Support/CrashPlan/ui.properties and edit it there.
    Unfortunately you can’t keep multiple commented (#) lines with the needed ServiceHost entry because the client is so clever as to tidy up the file every exit. So you have to modify it before starting and switching the entries every time.
    Not so great improvement. OTOH I understand that CP doesn’t support this officially.

  4. Looks like your write-up fixed this issue on my DS412+! Thanks SO MUCH for the clear, concise instructions!

  5. /var/packages/CrashPlan/target/upgrade$ unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar *.jar -d /var/packages/CrashPlan/target/lib/
    caution: filename not matched: 1388728800370.jar
    Archive: /var/packages/CrashPlan/target/upgrade/1388728800370.jar

  6. Thanks Bernhard!

    Based on your finding I replicated the ui.property file in the Library to one for my local CrashPlan and one for my Synology.
    Then I wrote 2 applescripts to copy one of these over the original ui.property and then start CrashPlan. Works perfectly fine for me. Compared to the previous version the only caveat is that you cannot run both CrashPlan clients simultaneously. Posting the scripts here for everyone’s reference.

    Please replace USERNAME with your username and make sure you name the duplicate ui.properties files identical to the ones mentioned in the scripts.

    CRASHPLAN SYNOLOGY
    on ApplicationIsRunning(appName)
    tell application “System Events” to set appNameIsRunning to exists (processes where name is appName)
    return appNameIsRunning
    end ApplicationIsRunning

    if ApplicationIsRunning(“CrashPlan”) then
    display alert “CrashPlan already running, unable to start twice”
    quit
    end if
    try
    set mySource to “/Users/USERNAME/Library/Application Support/CrashPlan/ui.properties Synology”
    set myDestination to “/Users/USERNAME/Library/Application Support/CrashPlan/ui.properties”
    set myCopy to “cp -v ” & quoted form of mySource & ” ” & quoted form of myDestination
    set myAnswer to do shell script myCopy with administrator privileges
    on error
    set myAnswer to “Could not copy file, wrong CrashPlan might start”
    display dialog myAnswer
    end try

    tell application “CrashPlan” to activate

    CRASHPLAN MAC
    on ApplicationIsRunning(appName)
    tell application “System Events” to set appNameIsRunning to exists (processes where name is appName)
    return appNameIsRunning
    end ApplicationIsRunning

    if ApplicationIsRunning(“CrashPlan”) then
    display alert “CrashPlan already running, unable to start twice”
    quit
    end if
    try
    set mySource to “/Users/USERNAME/Library/Application Support/CrashPlan/ui.properties local”
    set myDestination to “/Users/USERNAME/Library/Application Support/CrashPlan/ui.properties”
    set myCopy to “cp -v ” & quoted form of mySource & ” ” & quoted form of myDestination
    set myAnswer to do shell script myCopy with administrator privileges
    on error
    set myAnswer to “Could not copy file, wrong CrashPlan might start”
    display dialog myAnswer
    end try

    tell application “CrashPlan” to activate

    Export these to the Applications folder and run the script instead of the CrashPlan package…

  7. For those getting filename not matched errors – make sure you are logging in as root and not admin. The password is the same.

  8. Thank you very much, this works very well! (Except for me overlooking the root requirement the first attempt ;-))

  9. I am having the same issue as Arto: “Crashplan finishes Synchronization, Analyzes the next file to be backed up and then crashes. It restarts and begins to analyze and then crashes. Any help would be greatly appreciated.”
    Only in my case it starts synchronisation, completes it once right after the fix, stops because of full system scan and then stops. From then on it’s a loop of starting and stopping. i’m using a DS214se. Can anyone please help? Running out of ideas…
    Thanks!

  10. I am having a similar issue to what Arto described:
    IN the first launch after the installation of the fix, Crashplan Synchronises, finishes Synchronization, Starts upload, stops upload due to full system scan and then then crashes. It restarts and begins to analyze and then crashes again. The client on my mac crashes too, whenever Crashplan stops on my Synology.

    I am using a Synology DS214se

    Please help, as I heavily depend on the backups… Thank you!

  11. When running this command:
    ls -l /var/packages/CrashPlan/target/upgrade/1388728800370.*

    My NAS throws back this error message:

    ls: invalid option — ‘ ‘
    BusyBox v1.16.1 (2015-01-07 14:56:57 CST) multi-call binary.

    What did I do wrong?

  12. ‘unzip’ didn’t work for me. Errored that the 1388 jar didn’t check out. Updated the unzip to use jar -cvf and the rest of it seems to have taken just fine. Thanks for the tip, fingers crossed, at least it is running now.

  13. Crashplan is running again, but the GUI says (at both destinations and fot the 1st time) ‘licenselimit reached’, but it is backing up to the local destination. (remote is down at the moment)

Leave a comment

Your email address will not be published. Required fields are marked *