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. These steps worked for me. If you’re also having the issue that you can’t connect from your Mac to the headless Crashplan service, try to add the serviceHost to ~/Libraries/Application Support/Crashplan/ui.properties file instead.

  2. FWIW, when I used the unzip command to extract the *.jar files from the archive, I got the error “caution: filename not matched: 1388728800370.jar”. Extracting swt*.jar worked, but I had to I manually extracted c42_protolib.jar and com.backup42.desktop.jar. Once I got past this, it all worked fine.

  3. @Rob i got the same error “caution: filename not matched: 1388728800370.jar” and followed your instructions, however i don’t see com.backup42.desktop.jar. Can you clarify?

  4. Great. You should probably put *.jar etc. within quotes to keep the shell from expanding the wildcard, so the first unzip line would be unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar “*.jar” -d /var/packages/CrashPlan/target/lib/

  5. @Jomy

    I’m at work at the moment so I can’t confirm the names exactly, but I did an unzip -l 1388728800370.jar to list the files in the archive. I looked for the .jar files and manually extracted the ones with multiple periods (.) and used swt*.jar wildcard for the others. My recollection is that there were 4 .jar files within the main .jar files.

  6. Having the same issue as Rob. When running the first line I receive “caution: filename not matched: jna-3.2.5.jar”. If anyone can help I would greatly appreciate it. Need to finish my initial backup have 403GB our of 7.8TB remaning!

  7. Could it be that *.jar is expanded if you’re in a folder with .jar-files? Since the commands given in the post do not require you to be in a specific folder, maybe you should just go to an empty temporary folder while running these commands. For me with the default ash busybox shell from Synology it worked perfectly when following the steps.

  8. For those having trouble with expanding the .jar files from the archive here’s an alternative that accomplishes the same thing:

    If you attempted to run the 3.6.4 version you should have a folder in your upgrade directory that looks like 1388728800370.nnnnnnnnnn where nnnnnnnn will be a random set of numbers assigned to each installation.

    cd 1388728800370.nnnnnnnnnnnn

    Now all of the files that you need from the .jar file are already expanded here. Just copy them to the correct location:

    cp -p *.jar ../../lib/
    cp -p run.conf ../../bin
    cp -p lang/* ../..

    Then while still in the same directory

    mv upgrade.sh upgrade.sh.old

    Finally, for some to get the GUI client working you need to install the 3.7 version of Crashplan and then in the Crashplan program directory locate the conf subdirectory. In that directory edit the ui.properties file. Uncomment the ServiceHost line and replace 127.0.0.1 with your Diskstation server IP. Also, you can disable the Crashplan service on the workstation where you installed the GUI client if you won’t be running Crashplan to backup that system.

  9. Hi compuaidcanada.

    Was able to get passed that initial error but now running into mv: can’t rename “/var/packages/CrashPlan/target/upgrade/1388728800370.1421177155499/upgrade.sh : No such file or directory”. Any help again would be greatly appreciated.

    Thank you for all your work.

  10. I get this message when I try to run the command:

    caution: filename not matched: 1388728800370.jar

    I looks like It matches to me.

  11. I get the same error as Arto.
    Any help would be appreciated.
    Here is the error message test from the command line. I also receive a pop up window,

    mv: can’t rename ‘/var/packages/CrashPlan/target/upgrade/1388728800370.1421076070186/upgrade.sh’: No such file or directory

  12. when you get this errror message with the first unzip command:
    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar *.jar -d /var/packages/CrashPlan/target/lib/

    caution: filename not matched: 1388728800370.jar

    try this as a workaround:
    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar swt.jar -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar swt-64.jar -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar c42_protolib.jar -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar com.backup42.desktop.jar -d /var/packages/CrashPlan/target/lib/

  13. Wow, thank you, thank you, thank you! Perfectly fixed my Crashplan problem on Synology DS1513+! Very happy my backups are working again!

  14. Works perfect! Mucho grassyass, folks!

    Christopher: your ls -l output will show the .jar file first, then below that is a path:

    /var/packages/CrashPlan/target/upgrade/1388728800370.somenumber:
    drwxr-xr-x 2 root root 4096 Jan 14 01:28 META-INF
    drwxr-xr-x 2 root root 4096 Jan 14 17:20 lang
    -rw-r–r– 1 root root 7580 Jan 14 17:32 upgrade.log
    -rw-r–r– 1 root root 7580 Jan 14 17:28 upgrade.log.old
    -rw-r–r– 1 root root 87 Jan 14 01:28 upgrade.properties
    -rw-r–r– 1 root root 6701 Jan 14 17:30 upgrade.sh.

    you will:

    =mv /var/packages/CrashPlan/target/upgrade/1388728800370.somenumber/upgrade.sh /var/packages/CrashPlan/target/upgrade/1388728800370.somenumber/upgrade.sh.old

  15. Thank You very much for this fix, its always the pits when Crashplan stops working and I have no idea where to go.

  16. I get this on the 2nd to last step. Can anyone help? Syntax error?

    mv /var/packages/CrashPlan/target/upgrade/1388728800370.1421376657531/upgrade.sh
    BusyBox v1.16.1 (2015-01-07 15:00:31 CST) multi-call binary.

    Usage: mv [OPTIONS] SOURCE DEST
    or: mv [OPTIONS] SOURCE… DIRECTORY

    Rename SOURCE to DEST, or move SOURCE(s) to DIRECTORY

    Options:
    -f Don’t prompt before overwriting
    -i Interactive, prompt before overwrite

  17. Thank you so much! These steps worked perfectly and I had never SSHed into my new Synology before. Brought back memories from my youth running Unix. But thanks for finding the fix and posting the steps. My backup are running again!

  18. A suggestion for Eric
    The last two steps are actual one long command not two.
    I think you entered line number two and hit return before entering space and the rest of the command on line three.
    Just after the end of the second step type a space then the third line
    so just after…./upgrade.sh /var/packages/CrashPlan/target/upgrade/……

  19. For some reason I haven’t had any luck. 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.

  20. One thing I noticed is that in the run.conf file (located in /volume1/@appstore/CrashPlan/bin/) the Java Xmx value keeps resetting to 1024 when I used to have it set at 1536. Now my backup is currently sitting at 7.6TB and i have about 200GB to go and I believe this is now the issue. Can anyone look into why the value keeps resetting to 1024? I’m not a linux expert by any means so my knowledge is pretty limited.

Leave a comment

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