CrashPlan packages for Synology NAS

6,692 Replies

UPDATE – CrashPlan For Home (green branding) was retired by Code 42 Software on 22/08/2017. See migration notes below to find out how to transfer to CrashPlan for Small Business on Synology at the special discounted rate.

CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient, particularly against the threat of ransomware.

There are now only two product versions:

Small Business: CrashPlan PRO (blue branding). Unlimited cloud backup subscription, $10 per device per month. Reporting via Admin Console. No peer-to-peer backups
Enterprise: CrashPlan PROe (black branding). Cloud backup subscription typically billed by storage usage, also available from third parties.

The instructions and notes on this page apply to both versions of the Synology package.

CrashPlanPRO-Windows

CrashPlan is a Java application which can be difficult to install on a NAS. Way back in January 2012 I decided to simplify it into a Synology package, since I had already created several others. It has been through many versions since that time, as the changelog below shows. Although it used to work on Synology products with ARM and PowerPC CPUs, it unfortunately became Intel-only in October 2016 due to Code 42 Software adding a reliance on some proprietary libraries.

Licence compliance is another challenge – Code 42’s EULA prohibits redistribution. I had to make the Synology package use the regular CrashPlan for Linux download (after the end user agrees to the Code 42 EULA). I then had to write my own script to extract this archive and mimic the Code 42 installer behaviour, but without the interactive prompts of the original.

Synology Package Installation

In Synology DSM’s Package Center, click Settings and add my package repository:
The repository will push its certificate automatically to the NAS, which is used to validate package integrity. Set the Trust Level to Synology Inc. and trusted publishers:
Now browse the Community section in Package Center to install CrashPlan:

The repository only displays packages which are compatible with your specific model of NAS. If you don’t see CrashPlan in the list, then either your NAS model or your DSM version are not supported at this time. DSM 5.0 is the minimum supported version for this package, and an Intel CPU is required.
Since CrashPlan is a Java application, it needs a Java Runtime Environment (JRE) to function. It is recommended that you select to have the package install a dedicated Java 8 runtime. For licensing reasons I cannot include Java with this package, so you will need to agree to the licence terms and download it yourself from Oracle’s website. The package expects to find this .tar.gz file in a shared folder called ‘public’. If you go ahead and try to install the package without it, the error message will indicate precisely which Java file you need for your system type, and it will provide a TinyURL link to the appropriate Oracle download page.
To install CrashPlan PRO you will first need to log into the Admin Console and download the Linux App from the App Download section and also place this in the ‘public’ shared folder on your NAS.
If you have a multi-bay NAS, use the Shared Folder control panel to create the shared folder called public (it must be all lower case). On single bay models this is created by default. Assign it with Read/Write privileges for everyone.
If you have trouble getting the Java or CrashPlan PRO app files recognised by this package, try downloading them with Firefox. It seems to be the only web browser that doesn’t try to uncompress the files, or rename them without warning. I also suggest that you leave the Java file and the public folder present once you have installed the package, so that you won’t need to fetch this again to install future updates to the CrashPlan package.
CrashPlan is installed in headless mode – backup engine only. This will configured by a desktop client, but operates independently of it.
The first time you start the CrashPlan package you will need to stop it and restart it before you can connect the client. This is because a config file that is only created on first run needs to be edited by one of my scripts. The engine is then configured to listen on all interfaces on the default port 4243.

CrashPlan Client Installation

Once the CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.
The Linux CrashPlan PRO client must be downloaded from the Admin Console and placed in the ‘public’ folder on your NAS in order to successfully install the Synology package.
By default the client is configured to connect to the CrashPlan engine running on the local computer. Run this command on your NAS from an SSH session:
echo `cat /var/lib/crashplan/.ui_info`
Note those are backticks not quotes. This will give you a port number (4243), followed by an authentication token, followed by the IP binding (0.0.0.0 means the server is listening for connections on all interfaces) e.g.:
4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0 port,--------------token-----------------,binding
Copy this token value and use this value to replace the token in the equivalent config file on the computer that you would like to run the CrashPlan client on – located here:
C:\ProgramData\CrashPlan\.ui_info (Windows)
“/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for all users)
“~/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for single user)
/var/lib/crashplan/.ui_info (Linux)
You will not be able to connect the client unless the client token matches on the NAS token. On the client you also need to amend the IP address value after the token to match the Synology NAS IP address.
so using the example above, your computer’s CrashPlan client config file would be edited to:
4243,9ac9b642-ba26-4578-b705-124c6efc920b,192.168.1.100
assuming that the Synology NAS has the IP 192.168.1.100
If it still won’t connect, check that the ServicePort value is set to 4243 in the following files:
C:\ProgramData\CrashPlan\conf\ui_(username).properties (Windows)
“/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for all users)
“~/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for single user)
/usr/local/crashplan/conf (Linux)
/var/lib/crashplan/.ui_info (Synology) – this value does change spontaneously if there’s a port conflict e.g. you started two versions of the package concurrently (CrashPlan and CrashPlan PRO)
As a result of the nightmarish complexity of recent product changes Code42 has now published a support article with more detail on running headless systems including config file locations on all supported operating systems, and for ‘all users’ versus single user installs etc.
You should disable the CrashPlan service on your computer if you intend only to use the client. In Windows, open the Services section in Computer Management and stop the CrashPlan Backup Service. In the service Properties set the Startup Type to Manual. You can also disable the CrashPlan System Tray notification application by removing it from Task Manager > More Details > Start-up Tab (Windows 8/Windows 10) or the All Users Startup Start Menu folder (Windows 7).
To accomplish the same on Mac OS X, run the following commands one by one:
```
sudo launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist
sudo mv /Library/LaunchDaemons/com.crashplan.engine.plist /Library/LaunchDaemons/com.crashplan.engine.plist.bak
```
The CrashPlan menu bar application can be disabled in System Preferences > Users & Groups > Current User > Login Items

Migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO)

Leave the regular green branded CrashPlan 4.8.3 Synology package installed.
Go through the online migration using the link in the email notification you received from Code 42 on 22/08/2017. This seems to trigger the CrashPlan client to begin an update to 4.9 which will fail. It will also migrate your account onto a CrashPlan PRO server. The web page is likely to stall on the Migrating step, but no matter. The process is meant to take you to the store but it seems to be quite flakey. If you see the store page with a $0.00 amount in the basket, this has correctly referred you for the introductory offer. Apparently the $9.99 price thereafter shown on that screen is a mistake and the correct price of $2.50 is shown on a later screen in the process I think. Enter your credit card details and check out if you can. If not, continue.
Log into the CrashPlan PRO Admin Console as per these instructions, and download the CrashPlan PRO 4.9 client for Linux, and the 4.9 client for your remote console computer. Ignore the red message in the bottom left of the Admin Console about registering, and do not sign up for the free trial. Preferably use Firefox for the Linux version download – most of the other web browsers will try to unpack the .tgz archive, which you do not want to happen.
Configure the CrashPlan PRO 4.9 client on your computer to connect to your Syno as per the usual instructions on this blog post.
Put the downloaded Linux CrashPlan PRO 4.9 client .tgz file in the ‘public’ shared folder on your NAS. The package will no longer download this automatically as it did in previous versions.
From the Community section of DSM Package Center, install the CrashPlan PRO 4.9 package concurrently with your existing CrashPlan 4.8.3 Syno package.
This will stop the CrashPlan package and automatically import its configuration. Notice that it will also backup your old CrashPlan .identity file and leave it in the ‘public’ shared folder, just in case something goes wrong.
Start the CrashPlan PRO Synology package, and connect your CrashPlan PRO console from your computer.
You should see your protected folders as usual. At first mine reported something like “insufficient device licences”, but the next time I started up it changed to “subscription expired”.
Uninstall the CrashPlan 4.8.3 Synology package, this is no longer required.
At this point if the store referral didn’t work in the second step, you need to sign into the Admin Console. While signed in, navigate to this link which I was given by Code 42 support. If it works, you should see a store page with some blue font text and a $0.00 basket value. If it didn’t work you will get bounced to the Consumer Next Steps webpage: “Important Changes to CrashPlan for Home” – the one with the video of the CEO explaining the situation. I had to do this a few times before it worked. Once the store referral link worked and I had confirmed my payment details my CrashPlan PRO client immediately started working. Enjoy!

Notes

The package uses the intact CrashPlan installer directly from Code 42 Software, following acceptance of its EULA. I am complying with the directive that no one redistributes it.
The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 512MB). This can be overridden in a persistent way if you are backing up large backup sets by editing /var/packages/CrashPlan/target/syno_package.vars. If you are considering buying a NAS purely to use CrashPlan and intend to back up more than a few hundred GB then I strongly advise buying one of the models with upgradeable RAM. Memory is very limited on the cheaper models. I have found that a 512MB heap was insufficient to back up more than 2TB of files on a Windows server and that was the situation many years ago. It kept restarting the backup engine every few minutes until I increased the heap to 1024MB. Many users of the package have found that they have to increase the heap size or CrashPlan will halt its activity. This can be mitigated by dividing your backup into several smaller backup sets which are scheduled to be protected at different times. Note that from package version 0041, using the dedicated JRE on a 64bit Intel NAS will allow a heap size greater than 4GB since the JRE is 64bit (requires DSM 6.0 in most cases).
If you need to manage CrashPlan from a remote location, I suggest you do so using SSH tunnelling as per this support document.
The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache. Upgrades can now take place without requiring a login from the client afterwards.
If you remove the package completely and re-install it later, you can re-attach to previous backups. When you log in to the Desktop Client with your existing account after a re-install, you can select “adopt computer” to merge the records, and preserve your existing backups. I haven’t tested whether this also re-attaches links to friends’ CrashPlan computers and backup sets, though the latter does seem possible in the Friends section of the GUI. It’s probably a good idea to test that this survives a package reinstall before you start relying on it. Sometimes, particularly with CrashPlan PRO I think, the adopt option is not offered. In this case you can log into CrashPlan Central and retrieve your computer’s GUID. On the CrashPlan client, double-click on the logo in the top right and you’ll enter a command line mode. You can use the GUID command to change the system’s GUID to the one you just retrieved from your account.
The log which is displayed in the package’s Log tab is actually the activity history. If you are trying to troubleshoot an issue you will need to use an SSH session to inspect these log files:
/var/packages/CrashPlan/target/log/engine_output.log
/var/packages/CrashPlan/target/log/engine_error.log
/var/packages/CrashPlan/target/log/app.log
When CrashPlan downloads and attempts to run an automatic update, the script will most likely fail and stop the package. This is typically caused by syntax differences with the Synology versions of certain Linux shell commands (like rm, mv, or ps). The startup script will attempt to apply the published upgrade the next time the package is started.
Although CrashPlan’s activity can be scheduled within the application, in order to save RAM some users may wish to restrict running the CrashPlan engine to specific times of day using the Task Scheduler in DSM Control Panel:

Note that regardless of real-time backup, by default CrashPlan will scan the whole backup selection for changes at 3:00am. Include this time within your Task Scheduler time window or else CrashPlan will not capture file changes which occurred while it was inactive:
If you decide to sign up for one of CrashPlan’s paid backup services as a result of my work on this, please consider donating using the PayPal button on the right of this page.

Package scripts

For information, here are the package scripts so you can see what it’s going to do. You can get more information about how packages work by reading the Synology 3rd Party Developer Guide.

installer.sh

#!/bin/sh

#--------CRASHPLAN installer script
#--------package maintained at pcloadletter.co.uk


DOWNLOAD_PATH="http://download2.code42.com/installs/linux/install/${SYNOPKG_PKGNAME}"
CP_EXTRACTED_FOLDER="crashplan-install"
OLD_JNA_NEEDED="false"
[ "${SYNOPKG_PKGNAME}" == "CrashPlan" ] && DOWNLOAD_FILE="CrashPlan_4.8.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_4.*_Linux.tgz"
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
  CP_EXTRACTED_FOLDER="${SYNOPKG_PKGNAME}-install"
  OLD_JNA_NEEDED="true"
  [ "${WIZARD_VER_483}" == "true" ] && { CPPROE_VER="4.8.3"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_480}" == "true" ] && { CPPROE_VER="4.8.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_470}" == "true" ] && { CPPROE_VER="4.7.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_460}" == "true" ] && { CPPROE_VER="4.6.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_452}" == "true" ] && { CPPROE_VER="4.5.2"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_450}" == "true" ] && { CPPROE_VER="4.5.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_441}" == "true" ] && { CPPROE_VER="4.4.1"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_430}" == "true" ] && CPPROE_VER="4.3.0"
  [ "${WIZARD_VER_420}" == "true" ] && CPPROE_VER="4.2.0"
  [ "${WIZARD_VER_370}" == "true" ] && CPPROE_VER="3.7.0"
  [ "${WIZARD_VER_364}" == "true" ] && CPPROE_VER="3.6.4"
  [ "${WIZARD_VER_363}" == "true" ] && CPPROE_VER="3.6.3"
  [ "${WIZARD_VER_3614}" == "true" ] && CPPROE_VER="3.6.1.4"
  [ "${WIZARD_VER_353}" == "true" ] && CPPROE_VER="3.5.3"
  [ "${WIZARD_VER_341}" == "true" ] && CPPROE_VER="3.4.1"
  [ "${WIZARD_VER_33}" == "true" ] && CPPROE_VER="3.3"
  DOWNLOAD_FILE="CrashPlanPROe_${CPPROE_VER}_Linux.tgz"
fi
DOWNLOAD_URL="${DOWNLOAD_PATH}/${DOWNLOAD_FILE}"
CPI_FILE="${SYNOPKG_PKGNAME}_*.cpi"
OPTDIR="${SYNOPKG_PKGDEST}"
VARS_FILE="${OPTDIR}/install.vars"
SYNO_CPU_ARCH="`uname -m`"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
[ "${SYNO_CPU_ARCH}" == "armv5tel" ] && SYNO_CPU_ARCH="armel"
[ "${SYNOPKG_DSM_ARCH}" == "armada375" ] && SYNO_CPU_ARCH="armv7l"
[ "${SYNOPKG_DSM_ARCH}" == "armada38x" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "comcerto2k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine4k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "monaco" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "rtd1296" ] && SYNO_CPU_ARCH="armhf"
NATIVE_BINS_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-${SYNO_CPU_ARCH}.tar.xz"   
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
OLD_JNA_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-old-${SYNO_CPU_ARCH}.tar.xz"   
OLD_JNA_FILE="`echo ${OLD_JNA_URL} | sed -r "s%^.*/(.*)%\1%"`"
INSTALL_FILES="${DOWNLOAD_URL} ${NATIVE_BINS_URL}"
[ "${OLD_JNA_NEEDED}" == "true" ] && INSTALL_FILES="${INSTALL_FILES} ${OLD_JNA_URL}"
TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
#the Manifest folder is where friends' backup data is stored
#we set it outside the app folder so it persists after a package uninstall
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
LOG_FILE="${SYNOPKG_PKGDEST}/log/history.log.0"
UPGRADE_FILES="syno_package.vars conf/my.service.xml conf/service.login conf/service.model"
UPGRADE_FOLDERS="log cache"
PUBLIC_FOLDER="`synoshare --get public | sed -r "/Path/!d;s/^.*\[(.*)\].*$/\1/"`"
#dedicated JRE section
if [ "${WIZARD_JRE_CP}" == "true" ]; then
  DOWNLOAD_URL="http://tinyurl.com/javaembed"
  EXTRACTED_FOLDER="ejdk1.8.0_151"
  #detect systems capable of running 64bit JRE which can address more than 4GB of RAM
  [ "${SYNOPKG_DSM_ARCH}" == "x64" ] && SYNO_CPU_ARCH="x64"
  [ "`uname -m`" == "x86_64" ] && [ ${SYNOPKG_DSM_VERSION_MAJOR} -ge 6 ] && SYNO_CPU_ARCH="x64"
  if [ "${SYNO_CPU_ARCH}" == "armel" ]; then
    JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
    JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
  elif [ "${SYNO_CPU_ARCH}" == "armv7l" ]; then
    JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
    JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
  elif [ "${SYNO_CPU_ARCH}" == "armhf" ]; then
    JAVA_BINARY="ejdk-8u151-linux-armv6-vfp-hflt.tar.gz"
    JAVA_BUILD="ARMv6/ARMv7 Linux - VFP, HardFP ABI, Little Endian 1"
  elif [ "${SYNO_CPU_ARCH}" == "ppc" ]; then
    #Oracle have discontinued Java 8 for PowerPC after update 6
    JAVA_BINARY="ejdk-8u6-fcs-b23-linux-ppc-e500v2-12_jun_2014.tar.gz"
    JAVA_BUILD="Power Architecture Linux - Headless - e500v2 with double-precision SPE Floating Point Unit"
    EXTRACTED_FOLDER="ejdk1.8.0_06"
    DOWNLOAD_URL="http://tinyurl.com/java8ppc"
  elif [ "${SYNO_CPU_ARCH}" == "i686" ]; then
    JAVA_BINARY="ejdk-8u151-linux-i586.tar.gz"
    JAVA_BUILD="x86 Linux Small Footprint - Headless"
  elif [ "${SYNO_CPU_ARCH}" == "x64" ]; then
    JAVA_BINARY="jre-8u151-linux-x64.tar.gz"
    JAVA_BUILD="Linux x64"
    EXTRACTED_FOLDER="jre1.8.0_151"
    DOWNLOAD_URL="http://tinyurl.com/java8x64"
  fi
fi
JAVA_BINARY=`echo ${JAVA_BINARY} | cut -f1 -d'.'`
source /etc/profile


pre_checks ()
{
  #These checks are called from preinst and from preupgrade functions to prevent failures resulting in a partially upgraded package
  if [ "${WIZARD_JRE_CP}" == "true" ]; then
    synoshare -get public > /dev/null || (
      echo "A shared folder called 'public' could not be found - note this name is case-sensitive. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Please create this using the Shared Folder DSM Control Panel and try again." >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    )

    JAVA_BINARY_FOUND=
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz ] && JAVA_BINARY_FOUND=true
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar ] && JAVA_BINARY_FOUND=true
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.tar ] && JAVA_BINARY_FOUND=true
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.gz ] && JAVA_BINARY_FOUND=true
     
    if [ -z ${JAVA_BINARY_FOUND} ]; then
      echo "Java binary bundle not found. " >> $SYNOPKG_TEMP_LOGFILE
      echo "I was expecting the file ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Please agree to the Oracle licence at ${DOWNLOAD_URL}, then download the '${JAVA_BUILD}' package" >> $SYNOPKG_TEMP_LOGFILE
      echo "and place it in the 'public' shared folder on your NAS. This download cannot be automated even if " >> $SYNOPKG_TEMP_LOGFILE
      echo "displaying a package EULA could potentially cover the legal aspect, because files hosted on Oracle's " >> $SYNOPKG_TEMP_LOGFILE
      echo "server are protected by a session cookie requiring a JavaScript enabled browser." >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    fi
  else
    if [ -z ${JAVA_HOME} ]; then
      echo "Java is not installed or not properly configured. JAVA_HOME is not defined. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    fi

    if [ ! -f ${JAVA_HOME}/bin/java ]; then
      echo "Java is not installed or not properly configured. The Java binary could not be located. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    fi

    if [ "${WIZARD_JRE_SYS}" == "true" ]; then
      JAVA_VER=`java -version 2>&1 | sed -r "/^.* version/!d;s/^.* version \"[0-9]\.([0-9]).*$/\1/"`
      if [ ${JAVA_VER} -lt 8 ]; then
        echo "This version of CrashPlan requires Java 8 or newer. Please update your Java package. "
        exit 1
      fi
    fi
  fi
}


preinst ()
{
  pre_checks
  cd ${TEMP_FOLDER}
  for WGET_URL in ${INSTALL_FILES}
  do
    WGET_FILENAME="`echo ${WGET_URL} | sed -r "s%^.*/(.*)%\1%"`"
    [ -f ${TEMP_FOLDER}/${WGET_FILENAME} ] && rm ${TEMP_FOLDER}/${WGET_FILENAME}
    wget ${WGET_URL}
    if [[ $? != 0 ]]; then
      if [ -d ${PUBLIC_FOLDER} ] && [ -f ${PUBLIC_FOLDER}/${WGET_FILENAME} ]; then
        cp ${PUBLIC_FOLDER}/${WGET_FILENAME} ${TEMP_FOLDER}
      else     
        echo "There was a problem downloading ${WGET_FILENAME} from the official download link, " >> $SYNOPKG_TEMP_LOGFILE
        echo "which was \"${WGET_URL}\" " >> $SYNOPKG_TEMP_LOGFILE
        echo "Alternatively, you may download this file manually and place it in the 'public' shared folder. " >> $SYNOPKG_TEMP_LOGFILE
        exit 1
      fi
    fi
  done
 
  exit 0
}


postinst ()
{
  if [ "${WIZARD_JRE_CP}" == "true" ]; then
    #extract Java (Web browsers love to interfere with .tar.gz files)
    cd ${PUBLIC_FOLDER}
    if [ -f ${JAVA_BINARY}.tar.gz ]; then
      #Firefox seems to be the only browser that leaves it alone
      tar xzf ${JAVA_BINARY}.tar.gz
    elif [ -f ${JAVA_BINARY}.gz ]; then
      #Chrome
      tar xzf ${JAVA_BINARY}.gz
    elif [ -f ${JAVA_BINARY}.tar ]; then
      #Safari
      tar xf ${JAVA_BINARY}.tar
    elif [ -f ${JAVA_BINARY}.tar.tar ]; then
      #Internet Explorer
      tar xzf ${JAVA_BINARY}.tar.tar
    fi
    mv ${EXTRACTED_FOLDER} ${SYNOPKG_PKGDEST}/jre-syno
    JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
    [ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
    #change owner of folder tree
    chown -R root:root ${SYNOPKG_PKGDEST}
  fi
   
  #extract CPU-specific additional binaries
  mkdir ${SYNOPKG_PKGDEST}/bin
  cd ${SYNOPKG_PKGDEST}/bin
  tar xJf ${TEMP_FOLDER}/${NATIVE_BINS_FILE} && rm ${TEMP_FOLDER}/${NATIVE_BINS_FILE}
  [ "${OLD_JNA_NEEDED}" == "true" ] && tar xJf ${TEMP_FOLDER}/${OLD_JNA_FILE} && rm ${TEMP_FOLDER}/${OLD_JNA_FILE}

  #extract main archive
  cd ${TEMP_FOLDER}
  tar xzf ${TEMP_FOLDER}/${DOWNLOAD_FILE} && rm ${TEMP_FOLDER}/${DOWNLOAD_FILE} 
  
  #extract cpio archive
  cd ${SYNOPKG_PKGDEST}
  cat "${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}"/${CPI_FILE} | gzip -d -c - | ${SYNOPKG_PKGDEST}/bin/cpio -i --no-preserve-owner
  
  echo "#uncomment to expand Java max heap size beyond prescribed value (will survive upgrades)" > ${SYNOPKG_PKGDEST}/syno_package.vars
  echo "#you probably only want more than the recommended 1024M if you're backing up extremely large volumes of files" >> ${SYNOPKG_PKGDEST}/syno_package.vars
  echo "#USR_MAX_HEAP=1024M" >> ${SYNOPKG_PKGDEST}/syno_package.vars
  echo >> ${SYNOPKG_PKGDEST}/syno_package.vars

  cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/CrashPlanEngine ${OPTDIR}/bin
  cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/run.conf ${OPTDIR}/bin
  mkdir -p ${MANIFEST_FOLDER}/backupArchives    
  
  #save install variables which Crashplan expects its own installer script to create
  echo TARGETDIR=${SYNOPKG_PKGDEST} > ${VARS_FILE}
  echo BINSDIR=/bin >> ${VARS_FILE}
  echo MANIFESTDIR=${MANIFEST_FOLDER}/backupArchives >> ${VARS_FILE}
  #leave these ones out which should help upgrades from Code42 to work (based on examining an upgrade script)
  #echo INITDIR=/etc/init.d >> ${VARS_FILE}
  #echo RUNLVLDIR=/usr/syno/etc/rc.d >> ${VARS_FILE}
  echo INSTALLDATE=`date +%Y%m%d` >> ${VARS_FILE}
  [ "${WIZARD_JRE_CP}" == "true" ] && echo JAVACOMMON=${JRE_PATH}/bin/java >> ${VARS_FILE}
  [ "${WIZARD_JRE_SYS}" == "true" ] && echo JAVACOMMON=\${JAVA_HOME}/bin/java >> ${VARS_FILE}
  cat ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/install.defaults >> ${VARS_FILE}
  
  #remove temp files
  rm -r ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}
  
  #add firewall config
  /usr/syno/bin/servicetool --install-configure-file --package /var/packages/${SYNOPKG_PKGNAME}/scripts/${SYNOPKG_PKGNAME}.sc > /dev/null
  
  #amend CrashPlanPROe client version
  [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ] && sed -i -r "s/^version=\".*(-.*$)/version=\"${CPPROE_VER}\1/" /var/packages/${SYNOPKG_PKGNAME}/INFO

  #are we transitioning an existing CrashPlan account to CrashPlan For Small Business?
  if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ]; then
    if [ -e /var/packages/CrashPlan/scripts/start-stop-status ]; then
      /var/packages/CrashPlan/scripts/start-stop-status stop
      cp /var/lib/crashplan/.identity ${PUBLIC_FOLDER}/crashplan-identity.bak
      cp -R /var/packages/CrashPlan/target/conf/ ${OPTDIR}/
    fi  
  fi

  exit 0
}


preuninst ()
{
  `dirname $0`/stop-start-status stop

  exit 0
}


postuninst ()
{
  if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
    source ${SYNOPKG_PKGDEST}/syno_package.vars
  fi
  [ -e ${OPTDIR}/lib/libffi.so.5 ] && rm ${OPTDIR}/lib/libffi.so.5

  #delete symlink if it no longer resolves - PowerPC only
  if [ ! -e /lib/libffi.so.5 ]; then
    [ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
  fi

  #remove firewall config
  if [ "${SYNOPKG_PKG_STATUS}" == "UNINSTALL" ]; then
    /usr/syno/bin/servicetool --remove-configure-file --package ${SYNOPKG_PKGNAME}.sc > /dev/null
  fi

 exit 0
}


preupgrade ()
{
  `dirname $0`/stop-start-status stop
  pre_checks
  #if identity exists back up config
  if [ -f /var/lib/crashplan/.identity ]; then
    mkdir -p ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
    for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
      if [ -f ${OPTDIR}/${FILE_TO_MIGRATE} ]; then
        cp ${OPTDIR}/${FILE_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE}
      fi
    done
    for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
      if [ -d ${OPTDIR}/${FOLDER_TO_MIGRATE} ]; then
        mv ${OPTDIR}/${FOLDER_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig
      fi
    done
  fi

  exit 0
}


postupgrade ()
{
  #use the migrated identity and config data from the previous version
  if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf/my.service.xml ]; then
    for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
      if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ]; then
        mv ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ${OPTDIR}/${FILE_TO_MIGRATE}
      fi
    done
    for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
    if [ -d ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ]; then
      mv ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ${OPTDIR}
    fi
    done
    rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
    rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig
    
    #make CrashPlan log entry
    TIMESTAMP="`date "+%D %I:%M%p"`"
    echo "I ${TIMESTAMP} Synology Package Center updated ${SYNOPKG_PKGNAME} to version ${SYNOPKG_PKGVER}" >> ${LOG_FILE}
  fi
  
  exit 0
}

start-stop-status.sh

#!/bin/sh

#--------CRASHPLAN start-stop-status script
#--------package maintained at pcloadletter.co.uk


TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan" 
ENGINE_CFG="run.conf"
PKG_FOLDER="`dirname $0 | cut -f1-4 -d'/'`"
DNAME="`dirname $0 | cut -f4 -d'/'`"
OPTDIR="${PKG_FOLDER}/target"
PID_FILE="${OPTDIR}/${DNAME}.pid"
DLOG="${OPTDIR}/log/history.log.0"
CFG_PARAM="SRV_JAVA_OPTS"
JAVA_MIN_HEAP=`grep "^${CFG_PARAM}=" "${OPTDIR}/bin/${ENGINE_CFG}" | sed -r "s/^.*-Xms([0-9]+)[Mm] .*$/\1/"` 
SYNO_CPU_ARCH="`uname -m`"
TIMESTAMP="`date "+%D %I:%M%p"`"
FULL_CP="${OPTDIR}/lib/com.backup42.desktop.jar:${OPTDIR}/lang"
source ${OPTDIR}/install.vars
source /etc/profile
source /root/.profile


start_daemon ()
{
  #check persistent variables from syno_package.vars
  USR_MAX_HEAP=0
  if [ -f ${OPTDIR}/syno_package.vars ]; then
    source ${OPTDIR}/syno_package.vars
  fi
  USR_MAX_HEAP=`echo $USR_MAX_HEAP | sed -e "s/[mM]//"`

  #do we need to restore the identity file - has a DSM upgrade scrubbed /var/lib/crashplan?
  if [ ! -e /var/lib/crashplan ]; then
    mkdir /var/lib/crashplan
    [ -e ${OPTDIR}/conf/var-backup/.identity ] && cp ${OPTDIR}/conf/var-backup/.identity /var/lib/crashplan/
  fi

  #fix up some of the binary paths and fix some command syntax for busybox 
  #moved this to start-stop-status.sh from installer.sh because Code42 push updates and these
  #new scripts will need this treatment too
  find ${OPTDIR}/ -name "*.sh" | while IFS="" read -r FILE_TO_EDIT; do
    if [ -e ${FILE_TO_EDIT} ]; then
      #this list of substitutions will probably need expanding as new CrashPlan updates are released
      sed -i "s%^#!/bin/bash%#!$/bin/sh%" "${FILE_TO_EDIT}"
      sed -i -r "s%(^\s*)(/bin/cpio |cpio ) %\1/${OPTDIR}/bin/cpio %" "${FILE_TO_EDIT}"
      sed -i -r "s%(^\s*)(/bin/ps|ps) [^w][^\|]*\|%\1/bin/ps w \|%" "${FILE_TO_EDIT}"
      sed -i -r "s%\`ps [^w][^\|]*\|%\`ps w \|%" "${FILE_TO_EDIT}"
      sed -i -r "s%^ps [^w][^\|]*\|%ps w \|%" "${FILE_TO_EDIT}"
      sed -i "s/rm -fv/rm -f/" "${FILE_TO_EDIT}"
      sed -i "s/mv -fv/mv -f/" "${FILE_TO_EDIT}"
    fi
  done

  #use this daemon init script rather than the unreliable Code42 stock one which greps the ps output
  sed -i "s%^ENGINE_SCRIPT=.*$%ENGINE_SCRIPT=$0%" ${OPTDIR}/bin/restartLinux.sh

  #any downloaded upgrade script will usually have failed despite the above changes
  #so ignore the script and explicitly extract the new java code using the chrisnelson.ca method 
  #thanks to Jeff Bingham for tweaks 
  UPGRADE_JAR=`find ${OPTDIR}/upgrade -maxdepth 1 -name "*.jar" | tail -1`
  if [ -n "${UPGRADE_JAR}" ]; then
    rm ${OPTDIR}/*.pid > /dev/null
 
    #make CrashPlan log entry
    echo "I ${TIMESTAMP} Synology extracting upgrade from ${UPGRADE_JAR}" >> ${DLOG}

    UPGRADE_VER=`echo ${SCRIPT_HOME} | sed -r "s/^.*\/([0-9_]+)\.[0-9]+/\1/"`
    #DSM 6.0 no longer includes unzip, use 7z instead
    unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -d ${OPTDIR}/lib/ || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -o${OPTDIR}/lib/ > /dev/null
    unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -d ${OPTDIR} || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -o${OPTDIR} > /dev/null
    mv ${UPGRADE_JAR} ${TEMP_FOLDER}/ > /dev/null
    exec $0
  fi

  #updates may also overwrite our native binaries
  [ -e ${OPTDIR}/bin/libffi.so.5 ] && cp -f ${OPTDIR}/bin/libffi.so.5 ${OPTDIR}/lib/
  [ -e ${OPTDIR}/bin/libjtux.so ] && cp -f ${OPTDIR}/bin/libjtux.so ${OPTDIR}/
  [ -e ${OPTDIR}/bin/jna-3.2.5.jar ] && cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib/
  if [ -e ${OPTDIR}/bin/jna.jar ] && [ -e ${OPTDIR}/lib/jna.jar ]; then
    cp -f ${OPTDIR}/bin/jna.jar ${OPTDIR}/lib/
  fi

  #create or repair libffi.so.5 symlink if a DSM upgrade has removed it - PowerPC only
  if [ -e ${OPTDIR}/lib/libffi.so.5 ]; then
    if [ ! -e /lib/libffi.so.5 ]; then
      #if it doesn't exist, but is still a link then it's a broken link and should be deleted first
      [ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
      ln -s ${OPTDIR}/lib/libffi.so.5 /lib/libffi.so.5
    fi
  fi

  #set appropriate Java max heap size
  RAM=$((`free | grep Mem: | sed -e "s/^ *Mem: *\([0-9]*\).*$/\1/"`/1024))
  if [ $RAM -le 128 ]; then
    JAVA_MAX_HEAP=80
  elif [ $RAM -le 256 ]; then
    JAVA_MAX_HEAP=192
  elif [ $RAM -le 512 ]; then
    JAVA_MAX_HEAP=384
  elif [ $RAM -le 1024 ]; then
    JAVA_MAX_HEAP=512
  elif [ $RAM -gt 1024 ]; then
    JAVA_MAX_HEAP=1024
  fi
  if [ $USR_MAX_HEAP -gt $JAVA_MAX_HEAP ]; then
    JAVA_MAX_HEAP=${USR_MAX_HEAP}
  fi   
  if [ $JAVA_MAX_HEAP -lt $JAVA_MIN_HEAP ]; then
    #can't have a max heap lower than min heap (ARM low RAM systems)
    $JAVA_MAX_HEAP=$JAVA_MIN_HEAP
  fi
  sed -i -r "s/(^${CFG_PARAM}=.*) -Xmx[0-9]+[mM] (.*$)/\1 -Xmx${JAVA_MAX_HEAP}m \2/" "${OPTDIR}/bin/${ENGINE_CFG}"
  
  #disable the use of the x86-optimized external Fast MD5 library if running on ARM and PPC CPUs
  #seems to be the default behaviour now but that may change again
  [ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
  if [ "${SYNO_CPU_ARCH}" != "i686" ]; then
    grep "^${CFG_PARAM}=.*c42\.native\.md5\.enabled" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
     || sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1 -Dc42.native.md5.enabled=false\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
  fi

  #move the Java temp directory from the default of /tmp
  grep "^${CFG_PARAM}=.*Djava\.io\.tmpdir" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
   || sed -i -r "s%(^${CFG_PARAM}=\".*)\"$%\1 -Djava.io.tmpdir=${TEMP_FOLDER}\"%" "${OPTDIR}/bin/${ENGINE_CFG}"

  #now edit the XML config file, which only exists after first run
  if [ -f ${OPTDIR}/conf/my.service.xml ]; then

    #allow direct connections from CrashPlan Desktop client on remote systems
    #you must edit the value of serviceHost in conf/ui.properties on the client you connect with
    #users report that this value is sometimes reset so now it's set every service startup 
    sed -i "s/<serviceHost>127\.0\.0\.1<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${OPTDIR}/conf/my.service.xml"
    #default changed in CrashPlan 4.3
    sed -i "s/<serviceHost>localhost<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${OPTDIR}/conf/my.service.xml"
    #since CrashPlan 4.4 another config file to allow remote console connections
    sed -i "s/127\.0\.0\.1/0\.0\.0\.0/" /var/lib/crashplan/.ui_info
     
    #this change is made only once in case you want to customize the friends' backup location
    if [ "${MANIFEST_PATH_SET}" != "True" ]; then

      #keep friends' backup data outside the application folder to make accidental deletion less likely 
      sed -i "s%<manifestPath>.*</manifestPath>%<manifestPath>${MANIFEST_FOLDER}/backupArchives/</manifestPath>%" "${OPTDIR}/conf/my.service.xml"
      echo "MANIFEST_PATH_SET=True" >> ${OPTDIR}/syno_package.vars
    fi

    #since CrashPlan version 3.5.3 the value javaMemoryHeapMax also needs setting to match that used in bin/run.conf
    sed -i -r "s%(<javaMemoryHeapMax>)[0-9]+[mM](</javaMemoryHeapMax>)%\1${JAVA_MAX_HEAP}m\2%" "${OPTDIR}/conf/my.service.xml"

    #make sure CrashPlan is not binding to the IPv6 stack
    grep "\-Djava\.net\.preferIPv4Stack=true" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
     || sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1 -Djava.net.preferIPv4Stack=true\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
   else
    echo "Check the package log to ensure the package has started successfully, then stop and restart the package to allow desktop client connections." > "${SYNOPKG_TEMP_LOGFILE}"
  fi

  #increase the system-wide maximum number of open files from Synology default of 24466
  [ `cat /proc/sys/fs/file-max` -lt 65536 ] && echo "65536" > /proc/sys/fs/file-max

  #raise the maximum open file count from the Synology default of 1024 - thanks Casper K. for figuring this out
  #http://support.code42.com/Administrator/3.6_And_4.0/Troubleshooting/Too_Many_Open_Files
  ulimit -n 65536

  #ensure that Code 42 have not amended install.vars to force the use of their own (Intel) JRE
  if [ -e ${OPTDIR}/jre-syno ]; then
    JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
    [ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
    sed -i -r "s|^(JAVACOMMON=).*$|\1\${JRE_PATH}/bin/java|" ${OPTDIR}/install.vars
    
    #if missing, set timezone and locale for dedicated JRE   
    if [ -z ${TZ} ]; then
      SYNO_TZ=`cat /etc/synoinfo.conf | grep timezone | cut -f2 -d'"'`
      #fix for DST time in DSM 5.2 thanks to MinimServer Syno package author
      [ -e /usr/share/zoneinfo/Timezone/synotztable.json ] \
       && SYNO_TZ=`jq ".${SYNO_TZ} | .nameInTZDB" /usr/share/zoneinfo/Timezone/synotztable.json | sed -e "s/\"//g"` \
       || SYNO_TZ=`grep "^${SYNO_TZ}" /usr/share/zoneinfo/Timezone/tzname | sed -e "s/^.*= //"`
      export TZ=${SYNO_TZ}
    fi
    [ -z ${LANG} ] && export LANG=en_US.utf8
    export CLASSPATH=.:${OPTDIR}/jre-syno/lib

  else
    sed -i -r "s|^(JAVACOMMON=).*$|\1\${JAVA_HOME}/bin/java|" ${OPTDIR}/install.vars
  fi

  source ${OPTDIR}/bin/run.conf
  source ${OPTDIR}/install.vars
  cd ${OPTDIR}
  $JAVACOMMON $SRV_JAVA_OPTS -classpath $FULL_CP com.backup42.service.CPService > ${OPTDIR}/log/engine_output.log 2> ${OPTDIR}/log/engine_error.log &
  if [ $! -gt 0 ]; then
    echo $! > $PID_FILE
    renice 19 $! > /dev/null
    if [ -z "${SYNOPKG_PKGDEST}" ]; then
      #script was manually invoked, need this to show status change in Package Center      
      [ -e ${PKG_FOLDER}/enabled ] || touch ${PKG_FOLDER}/enabled
    fi
  else
    echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" > "${SYNOPKG_TEMP_LOGFILE}"
    echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" >&2
    exit 1
  fi
}

stop_daemon ()
{
  echo "I ${TIMESTAMP} Stopping ${DNAME}" >> ${DLOG}
  kill `cat ${PID_FILE}`
  wait_for_status 1 20 || kill -9 `cat ${PID_FILE}`
  rm -f ${PID_FILE}
  if [ -z ${SYNOPKG_PKGDEST} ]; then
    #script was manually invoked, need this to show status change in Package Center
    [ -e ${PKG_FOLDER}/enabled ] && rm ${PKG_FOLDER}/enabled
  fi
  #backup identity file in case DSM upgrade removes it
  [ -e ${OPTDIR}/conf/var-backup ] || mkdir ${OPTDIR}/conf/var-backup 
  cp /var/lib/crashplan/.identity ${OPTDIR}/conf/var-backup/
}

daemon_status ()
{
  if [ -f ${PID_FILE} ] && kill -0 `cat ${PID_FILE}` > /dev/null 2>&1; then
    return
  fi
  rm -f ${PID_FILE}
  return 1
}

wait_for_status ()
{
  counter=$2
  while [ ${counter} -gt 0 ]; do
    daemon_status
    [ $? -eq $1 ] && return
    let counter=counter-1
    sleep 1
  done
  return 1
}


case $1 in
  start)
    if daemon_status; then
      echo ${DNAME} is already running with PID `cat ${PID_FILE}`
      exit 0
    else
      echo Starting ${DNAME} ...
      start_daemon
      exit $?
    fi
  ;;

  stop)
    if daemon_status; then
      echo Stopping ${DNAME} ...
      stop_daemon
      exit $?
    else
      echo ${DNAME} is not running
      exit 0
    fi
  ;;

  restart)
    stop_daemon
    start_daemon
    exit $?
  ;;

  status)
    if daemon_status; then
      echo ${DNAME} is running with PID `cat ${PID_FILE}`
      exit 0
    else
      echo ${DNAME} is not running
      exit 1
    fi
  ;;

  log)
    echo "${DLOG}"
    exit 0
  ;;

  *)
    echo "Usage: $0 {start|stop|status|restart}" >&2
    exit 1
  ;;

esac

install_uifile & upgrade_uifile

[
  {
    "step_title": "Client Version Selection",
    "items": [
      {
        "type": "singleselect",
        "desc": "Please select the CrashPlanPROe client version that is appropriate for your backup destination server:",
        "subitems": [
          {
            "key": "WIZARD_VER_483",
            "desc": "4.8.3",
            "defaultValue": true
          },          {
            "key": "WIZARD_VER_480",
            "desc": "4.8.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_470",
            "desc": "4.7.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_460",
            "desc": "4.6.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_452",
            "desc": "4.5.2",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_450",
            "desc": "4.5.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_441",
            "desc": "4.4.1",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_430",
            "desc": "4.3.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_420",
            "desc": "4.2.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_370",
            "desc": "3.7.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_364",
            "desc": "3.6.4",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_363",
            "desc": "3.6.3",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_3614",
            "desc": "3.6.1.4",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_353",
            "desc": "3.5.3",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_341",
            "desc": "3.4.1",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_33",
            "desc": "3.3",
            "defaultValue": false
          }
        ]
      }
    ]
  },
  {
    "step_title": "Java Runtime Environment Selection",
    "items": [
      {
        "type": "singleselect",
        "desc": "Please select the Java version which you would like CrashPlan to use:",
        "subitems": [
          {
            "key": "WIZARD_JRE_SYS",
            "desc": "Default system Java version",
            "defaultValue": false
          },
          {
            "key": "WIZARD_JRE_CP",
            "desc": "Dedicated installation of Java 8",
            "defaultValue": true
          }
        ]
      }
    ]
  }
]

Changelog:

0031 Added TCP 4242 to the firewall services (computer to computer connections)
0047 30/Oct/17 – Updated dedicated Java version to 8 update 151, added support for additional Intel CPUs in x18 Synology products.
0046 26/Aug/17 – Updated to CrashPlan PRO 4.9, added support for migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO). Please read the Migration section on this page for instructions.
0045 02/Aug/17 – Updated to CrashPlan 4.8.3, updated dedicated Java version to 8 update 144
0044 21/Jan/17 – Updated dedicated Java version to 8 update 121
0043 07/Jan/17 – Updated dedicated Java version to 8 update 111, added support for Intel Broadwell and Grantley CPUs
0042 03/Oct/16 – Updated to CrashPlan 4.8.0, Java 8 is now required, added optional dedicated Java 8 Runtime instead of the default system one including 64bit Java support on 64 bit Intel CPUs to permit memory allocation larger than 4GB. Support for non-Intel platforms withdrawn owing to Code42’s reliance on proprietary native code library libc42archive.so
0041 20/Jul/16 – Improved auto-upgrade compatibility (hopefully), added option to have CrashPlan use a dedicated Java 7 Runtime instead of the default system one, including 64bit Java support on 64 bit Intel CPUs to permit memory allocation larger than 4GB
0040 25/May/16 – Added cpio to the path in the running context of start-stop-status.sh
0039 25/May/16 – Updated to CrashPlan 4.7.0, at each launch forced the use of the system JRE over the CrashPlan bundled Intel one, added Maven build of JNA 4.1.0 for ARMv7 systems consistent with the version bundled with CrashPlan
0038 27/Apr/16 – Updated to CrashPlan 4.6.0, and improved support for Code 42 pushed updates
0037 21/Jan/16 – Updated to CrashPlan 4.5.2
0036 14/Dec/15 – Updated to CrashPlan 4.5.0, separate firewall definitions for management client and for friends backup, added support for DS716+ and DS216play
0035 06/Nov/15 – Fixed the update to 4.4.1_59, new installs now listen for remote connections after second startup (was broken from 4.4), updated client install documentation with more file locations and added a link to a new Code42 support doc
EITHER completely remove and reinstall the package (which will require a rescan of the entire backup set) OR alternatively please delete all except for one of the failed upgrade numbered subfolders in /var/packages/CrashPlan/target/upgrade before upgrading. There will be one folder for each time CrashPlan tried and failed to start since Code42 pushed the update
0034 04/Oct/15 – Updated to CrashPlan 4.4.1, bundled newer JNA native libraries to match those from Code42, PLEASE READ UPDATED BLOG POST INSTRUCTIONS FOR CLIENT INSTALL this version introduced yet another requirement for the client
0033 12/Aug/15 – Fixed version 0032 client connection issue for fresh installs
0032 12/Jul/15 – Updated to CrashPlan 4.3, PLEASE READ UPDATED BLOG POST INSTRUCTIONS FOR CLIENT INSTALL this version introduced an extra requirement, changed update repair to use the chrisnelson.ca method, forced CrashPlan to prefer IPv4 over IPv6 bindings, removed some legacy version migration scripting, updated main blog post documentation
0031 20/May/15 – Updated to CrashPlan 4.2, cross compiled a newer cpio binary for some architectures which were segfaulting while unpacking main CrashPlan archive, added port 4242 to the firewall definition (friend backups), package is now signed with repository private key
0030 16/Feb/15 – Fixed show-stopping issue with version 0029 for systems with more than one volume
0029 21/Jan/15 – 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
0028 22/Oct/14 – Substantial re-write:
Updated to CrashPlan version 3.6.4
DSM 5.0 or newer is now required
libjnidispatch.so taken from Debian JNA 3.2.7 package with dependency on newer libffi.so.6 (included in DSM 5.0)
jna-3.2.5.jar emptied of irrelevant CPU architecture libs to reduce size
Increased default max heap size from 512MB to 1GB on systems with more than 1GB RAM
Intel CPUs no longer need the awkward glibc version-faking shim to enable inotify support (for real-time backup)
Switched to using root account – no more adding account permissions for backup, package upgrades will no longer break this
DSM Firewall application definition added
Tested with DSM Task Scheduler to allow backups between certain times of day only, saving RAM when not in use
Daemon init script now uses a proper PID file instead of Code42’s unreliable method of using grep on the output of ps
Daemon init script can be run from the command line
Removal of bash binary dependency now Code42’s CrashPlanEngine script is no longer used
Removal of nice binary dependency, using BusyBox equivalent renice
Unified ARMv5 and ARMv7 external binary package (armle)
Added support for Mindspeed Comcerto 2000 CPU (comcerto2k – armhf) in DS414j
Added support for Intel Atom C2538 (avoton) CPU in DS415+
Added support to choose which version of CrashPlan PROe client to download, since some servers may still require legacy versions
Switched to .tar.xz compression for native binaries to reduce web hosting footprint
0027 20/Mar/14 – Fixed open file handle limit for very large backup sets (ulimit fix)
0026 16/Feb/14 – Updated all CrashPlan clients to version 3.6.3, improved handling of Java temp files
0025 30/Jan/14 – glibc version shim no longer used on Intel Synology models running DSM 5.0
0024 30/Jan/14 – Updated to CrashPlan PROe 3.6.1.4 and added support for PowerPC 2010 Synology models running DSM 5.0
0023 30/Jan/14 – Added support for Intel Atom Evansport and Armada XP CPUs in new DSx14 products
0022 10/Jun/13 – Updated all CrashPlan client versions to 3.5.3, compiled native binary dependencies to add support for Armada 370 CPU (DS213j), start-stop-status.sh now updates the new javaMemoryHeapMax value in my.service.xml to the value defined in syno_package.vars
0021 01/Mar/13 – Updated CrashPlan to version 3.5.2
0020 21/Jan/13 – Fixes for DSM 4.2
018 Updated CrashPlan PRO to version 3.4.1
017 Updated CrashPlan and CrashPlan PROe to version 3.4.1, and improved in-app update handling
016 Added support for Freescale QorIQ CPUs in some x13 series Synology models, and installer script now downloads native binaries separately to reduce repo hosting bandwidth, PowerQUICC PowerPC processors in previous Synology generations with older glibc versions are not supported
015 Added support for easy scheduling via cron – see updated Notes section
014 DSM 4.1 user profile permissions fix
013 implemented update handling for future automatic updates from Code 42, and incremented CrashPlanPRO client to release version 3.2.1
012 incremented CrashPlanPROe client to release version 3.3
011 minor fix to allow a wildcard on the cpio archive name inside the main installer package (to fix CP PROe client since Code 42 Software had amended the cpio file version to 3.2.1.2)
010 minor bug fix relating to daemon home directory path
009 rewrote the scripts to be even easier to maintain and unified as much as possible with my imminent CrashPlan PROe server package, fixed a timezone bug (tightened regex matching), moved the script-amending logic from installer.sh to start-stop-status.sh with it now applying to all .sh scripts each startup so perhaps updates from Code42 might work in future, if wget fails to fetch the installer from Code42 the installer will look for the file in the public shared folder
008 merged the 14 package scripts each (7 for ARM, 7 for Intel) for CP, CP PRO, & CP PROe – 42 scripts in total – down to just two! ARM & Intel are now supported by the same package, Intel synos now have working inotify support (Real-Time Backup) thanks to rwojo’s shim to pass the glibc version check, upgrade process now retains login, cache and log data (no more re-scanning), users can specify a persistent larger max heap size for very large backup sets
007 fixed a bug that broke CrashPlan if the Java folder moved (if you changed version)
006 installation now fails without User Home service enabled, fixed Daylight Saving Time support, automated replacing the ARM libffi.so symlink which is destroyed by DSM upgrades, stopped assuming the primary storage volume is /volume1, reset ownership on /var/lib/crashplan and the Friends backup location after installs and upgrades
005 added warning to restart daemon after 1st run, and improved upgrade process again
004 updated to CrashPlan 3.2.1 and improved package upgrade process, forced binding to 0.0.0.0 each startup
003 fixed ownership of /volume1/crashplan folder
002 updated to CrashPlan 3.2
001 30/Jan/12 – intial public release

6,692 thoughts on “CrashPlan packages for Synology NAS”

maartenl945 May 20, 2015 at 18:06

Same issue here on DS214Play

Reply ↓
1. MD May 23, 2015 at 20:27
  
  Same issue on DS231+. No logs and package will not start after update to 4.2.0-0031
  
  Reply ↓
goslow2gofast May 20, 2015 at 19:35

I had used the previous fix mentioned by christian and had been running since the last auto pushed CrashPlan update had broke things. Today in the package center it indicated there was an update for the CrashPlan package so I let it update. Unfortunately now when I try to start the service back up it reports the following in the file “engine_error.log”:

Error: Could not find or load main class com.backup42.service.CPService

Reply ↓
1. Claude Philipona May 21, 2015 at 06:25
  
  I’ve got the exact same problem on my DS213+, engine_error.log with Error: Could not find or load main class com.backup42.service.CPService and service not starting.
  
  On my DS415+, with the same procedure the problem does NOT occur.
  
  Reply ↓
  1. Holger May 21, 2015 at 13:30
    
    Same problem on a DS413 with the 5.2 update 1 installed. Tried reinstalling, still seeing the same thing. Looks like only the /bin directory was actually created in the CrashPlan folder, no /log or anything…
  2. RV May 22, 2015 at 11:18
    
    I am having the same problem. Currently on DS 5.0 (DS413). Crashplan 3.7 was running fine. Applied the upgrade and now getting “Error: Could not find or load main class com.backup42.service.CPService” in my engine_error.log
    
    The main crashplan folder (/var/packages/CrashPlan/target) looks like it has a bunch of files missing…
    
    3.7.3 used to look like this…
    -rw-r–r– 1 root root 5 May 22 12:11 CrashPlan.pid
    drwxr-xr-x 2 root root 4096 May 22 12:10 backupArchives
    drwxr-xr-x 2 root root 4096 May 22 12:11 bin
    drwxr-xr-x 2 root root 4096 May 22 12:10 cache
    drwxr-xr-x 3 root root 4096 May 22 12:11 conf
    drwxr-xr-x 2 root root 4096 May 22 12:10 doc
    -rw-r–r– 1 root root 388 May 22 12:10 install.vars
    -rw-r–r– 1 root root 330 May 22 12:10 jniwrap.lic
    drwxr-xr-x 2 root root 4096 May 22 12:10 lang
    drwxr-xr-x 2 root root 4096 May 22 12:10 lib
    -rw-r–r– 1 root root 24756 May 22 12:10 libjniwrap.so
    -rw-r–r– 1 root root 48344 May 22 12:10 libjniwrap64.so
    -rw-r–r– 1 root root 129771 May 22 12:11 libjtux.so
    -rw-r–r– 1 root root 287934 May 22 12:10 libjtux64.so
    -rw-r–r– 1 root root 7346 May 22 12:10 libmd5.so
    -rw-r–r– 1 root root 8417 May 22 12:10 libmd564.so
    drwxr-xr-x 2 root root 4096 May 22 12:10 log
    -rw-r–r– 1 root root 39 Oct 10 2012 marker.txt
    drwxr-xr-x 2 root root 4096 May 22 12:10 skin
    -rw-r–r– 1 root root 242 May 22 12:11 syno_package.vars
    drwxr-xr-x 3 root root 4096 May 22 12:11 upgrade
    -rw-r–r– 1 root root 0 May 22 12:10 ~custom
    
    Now after 4.2 the folder looks like a bunch of stuff is missing.
    drwxr-xr-x 2 root root 4096 May 22 12:13 bin
    drwxr-xr-x 2 root root 4096 May 22 12:10 cache
    -rw-r–r– 1 root root 388 May 22 12:12 install.vars
    -rwxr-xr-x 1 root root 158879 May 22 12:13 lib
    -rwxr-xr-x 1 root root 129771 May 22 12:13 libjtux.so
    drwxr-xr-x 2 root root 4096 May 22 12:10 log
    -rw-r–r– 1 root root 39 Oct 10 2012 marker.txt
    -rw-r–r– 1 root root 242 May 22 12:12 syno_package.vars
2. Karsten May 21, 2015 at 12:27
  
  So I have the same issue with the 4.2.0-0031 version of the Crashplan package on a DS413 running DSM 5.2-5565 Update 1. When logging in and calling
  
  /var/packages/CrashPlan/scripts/start-stop-status start
  
  I get this (scary) output:
  
  Starting CrashPlan …
  sed: /var/packages/CrashPlan/target/bin/restartLinux.sh: No such file or directory
  find: /var/packages/CrashPlan/target/upgrade: No such file or directory
  cp: can’t stat ‘/bin/libffi.so.5’: No such file or directory
  /var/packages/CrashPlan/scripts/start-stop-status: /var/packages/CrashPlan/scripts/start-stop-status.sh: line 6: can’t create : nonexistent directory
  
  Reply ↓
  1. Fabien May 22, 2015 at 18:18
    
    Hi Karsten,
    
    I have the same issue on my DS413.
    
    Did you find a solution ?
    
    Thank you.
    
    Fabien
  2. Sparkles May 23, 2015 at 23:43
    
    I have exactly the same issue with same hardware and versions as Karsten. I tried reinstalling CrashPlan package and java embedded 7 but that did not help. When trying to run the CrashPlan package from package centre it does not change status at all – stays stopped.
3. kdambekalns May 21, 2015 at 13:02
  
  Hm, /var/packages/CrashPlan/target/lib/com.backup42.desktop.jar just doesn’t exist.
  
  Reply ↓
  1. Andy May 24, 2015 at 13:18
    
    Same issue for me that a lot of the required files simply don’t exist after upgrading. I tried re-installing and that doesn’t help. The service won’t start and nothing appears in the log. This is on DS413 with DSM 5.2-5565 Update 1 (but it broke before I moved to Update 1).
  2. Andy May 24, 2015 at 13:35
    
    I was able to uninstall and reinstall the old 3.7 version manually through http://packages.pcloadletter.co.uk/downloads/old/. Once you go through the update fix noted here: http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/ I am back in business.
4. goslow2gofast June 4, 2015 at 00:29
  
  The new 0031 version from pat has now resolved this problem, I edited the INFO file down to 0030, which caused the update to show in Package Center. It updated, and started right up now, all good.
  
  Reply ↓
MrXcitement May 20, 2015 at 19:40

Thanks Patters, the update to 4.2 went without a hitch… my DSM 5.2 server is now backing up via CrashPlan, as we say out here on the great plains, ye haw!

Reply ↓
MrXcitement May 20, 2015 at 19:43

Thanks Patters, just updated to my DMS 5.2 version of CrashPlan to 4.2 without a problem. £20 headed your way

Reply ↓
tony May 20, 2015 at 19:54

same here on 2x DS214play

Reply ↓
Pascal Kugele May 21, 2015 at 07:20

I had problems after update to Syno 5.2 then i hvae don this how to (http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/)

Today the package-center in DSM show me a update for CP 4.2.0.0031 after this update CP dosent start anymore… please Help! ;-)

Reply ↓
1. wesgurn May 21, 2015 at 12:46
  
  Same issue here. I have DS413 and after update I get the following in the log:
  NAS> ls -latr
  drwxr-xr-x 2 root root 4096 May 19 12:16 .
  -rw-r–r– 1 root root 0 May 19 14:46 restore_files.log.0
  -rw-r–r– 1 root root 3633 May 19 14:46 backup_files.log.0
  -rw-r–r– 1 root root 31193 May 19 14:47 app.log
  -rw-r–r– 1 root root 4722068 May 19 14:47 service.log.0
  -rw-r–r– 1 root root 4416 May 20 20:38 history.log.0
  -rw-r–r– 1 root root 0 May 21 12:25 engine_output.log
  -rw-r–r– 1 root root 72 May 21 12:25 engine_error.log
  drwxrwxrwx 5 root root 4096 May 21 12:25 ..
  NAS> more engine_error.log
  Error: Could not find or load main class com.backup42.service.CPService
  NAS>
  
  Reply ↓
  1. Isiah May 24, 2015 at 09:30
    
    After upgrade got this problem
    DS413> tail -f engine_error.log
    Error: Could not find or load main class com.backup42.service.CPService
    DS413> /var/packages/CrashPlan/scripts/start-stop-status start
    Starting CrashPlan …
    sed: /var/packages/CrashPlan/target/bin/restartLinux.sh: No such file or directory
    find: /var/packages/CrashPlan/target/upgrade: No such file or directory
    cp: can’t stat ‘/bin/libffi.so.5’: No such file or directory
    /var/packages/CrashPlan/scripts/start-stop-status: /var/packages/CrashPlan/scripts/start-stop-status.sh: line 6: can’t create : nonexistent directory
    DS413> /var/packages/CrashPlan/scripts/start-stop-status start
    Starting CrashPlan …
    sed: /var/packages/CrashPlan/target/bin/restartLinux.sh: No such file or directory
    find: /var/packages/CrashPlan/target/upgrade: No such file or directory
    cp: can’t stat ‘/bin/libffi.so.5’: No such file or directory
    /var/packages/CrashPlan/scripts/start-stop-status: /var/packages/CrashPlan/scripts/start-stop-status.sh: line 6: can’t create : nonexistent directory
    May I know how to fix?
  2. ST May 27, 2015 at 18:03
    
    I’m getting the same issue. DS413 with latest DSM.
  3. Kim Schulz May 28, 2015 at 09:54
    
    I see the same problem. I cannot start the crashplan service anymore on my DS413 after latest update
2. slidermike May 21, 2015 at 17:10
  
  I am still on DSM 4.3 on my DS1512+
  My crashplan stopped working about a week ago.
  I uninstalled crashplan off the NAS. Trying to re-install it, I cannot locate the last working crashplan for 4.x
  crashplan3.6.3-merged-0027
  http://packages.pcloadletter.co.uk/downloads/old/
  Can anyone provide this version of crashplan again?
  
  Reply ↓
  1. patters Post authorMay 22, 2015 at 12:00
    
    I’ve re-uploaded it back into that folder you linked to. Obviously your mileage will vary, because CrashPlan will immediately push a newer version once you install that one.
  2. slidermike May 22, 2015 at 14:19
    
    Thank you patters.
    I guess my only real recourse is to update the DSM to 5.1/5.2
    4.3 is super stable and less “candy” appearance. Oh well all good things must come to an end.
  3. kamster May 23, 2015 at 10:32
    
    Patters,
    Thanks for all the work, I am in the same situation as slidermike. Guess it’s time to upgrade to DSM 5.x
3. hal May 21, 2015 at 21:55
  
  me too!
  
  Reply ↓
4. MD May 23, 2015 at 20:31
  
  Same issue here on DS231+
  
  Reply ↓
Bert May 21, 2015 at 10:51

The update to build 31 didn’t seem to come through on my server (or I was impacient) so I uninstalled the package and after I reinstalled the crashplan package on my DS 1512+, everything worked again.
Thanks for fixing the problem!

Reply ↓
1. Bert May 21, 2015 at 10:58
  
  In fact I replied too soon. I just checked my logging again and it looks like it runs for some time (4-5 minutes), then stops and restarts. Anyone else with the same behavior?
  
  Reply ↓
  1. Bert May 21, 2015 at 11:45
    
    now keeps running after I installed the latest DSM patch (DSM 5.2-5565 Update 1)
  2. bertxl May 22, 2015 at 18:39
    
    I want to re-iterate to this, I’ve uninstalled Crashplan, reinstalled it but still no succes.
    DS1513+ – Upgraded to Memory 4GB
    DSM 5.2-5565 – Patter’s CrashPlan Version 4.2.0-0031
    Patter’s Java SE Embedded 8 Version 1.8.0_33-0031
    CrashPlan + 3 Version 4.2.0
    
    After installation, I stopped the crashplan package, verified the syno_package.vars were OK ( “USR_MAX_HEAP=2048M” ) and restarted it. Logging in to Crashplan, scanning the files went OK, scanning the blocks took a while but also went OK. But as soon as it started backing up the files, the crashplan client on my PC lost connection and I could see in the logfile that the crashplan on my NAS restarts after each file it backs up to the cloud.
    
    This is what I see in history.log.0 in /volume1/@appstore/CrashPlan/log
    I 05/22/15 06:01PM CrashPlan started, version 4.2.0, GUID 606116277561852009
    I 05/22/15 06:01PM Backup scheduled to always run
    I 05/22/15 06:01PM [Active] Starting backup to CrashPlan Central: 2,624 files (12.70GB) to back up
    I 05/22/15 06:04PM Stopping CrashPlan
    I 05/22/15 06:04PM CrashPlan started, version 4.2.0, GUID 606116277561852009
    I 05/22/15 06:04PM Backup scheduled to always run
    I 05/22/15 06:04PM [Active] Starting backup to CrashPlan Central: 2,623 files (12.70GB) to back up
    I 05/22/15 06:06PM Stopping CrashPlan
    I 05/22/15 06:07PM CrashPlan started, version 4.2.0, GUID 606116277561852009
    I 05/22/15 06:07PM Backup scheduled to always run
    I 05/22/15 06:07PM [Active] Starting backup to CrashPlan Central: 2,622 files (12.70GB) to back up
    I 05/22/15 06:09PM Stopping CrashPlan
    I 05/22/15 06:10PM CrashPlan started, version 4.2.0, GUID 606116277561852009
    I 05/22/15 06:10PM Backup scheduled to always run
    I 05/22/15 06:10PM [Active] Starting backup to CrashPlan Central: 2,622 files (12.70GB) to back up
    I 05/22/15 06:12PM Stopping CrashPlan
    
    If it takes 3 minutes to backup each file and restart CP, it will take me 180 hours to upload everything…
  3. bertxl May 23, 2015 at 09:28
    
    I finally discovered what caused the issue… A # in syno_package.vars. For some reason, an old version of the file got back in the Crashplan folder and the usr_max_heap got commented out (and thus back to default).
    I’ve changed it again to 2048MB and now the backup seems to be running again.
RAJ May 22, 2015 at 02:27

In the event this helps anyone…. my current setup:

DS1511+ – Upgraded to 3G Memory
DSM 5.2-5565
Patter’s CrashPlan Version 4.2.0-0031
Patter’s Java SE Embedded 7 Version 1.7.0_75-0031
CrashPlan + 3 Version 4.2.0

Order of steps I took:
1. Stopped Patters Crashplan Service on Synology Package Center
2. Updated DSM to version 5.2.5565
3. Updated to Patters CrashPlan Version 4.2.0-0031
4. Made my three changes listed below using Putty to SSH as root into DS1511+
5 Started CrashPlan, then stopped it, then started it again
6. Updated the client side Crashplan to Version 4.2.0, by downloading and installing it onto PC
7. Updated the conf/ui.properties – and added the line “serviceHost=192.168.1.XXX” – where XXX was my DS1511+

Aside from using the above, and upgrading to 3GB of memory… the following 3 tweaks help me get it all working seemlessly. Using Putty to SSH onto the DS1511+, and logging in as root:

1. EDIT syno_package.vars
a. cd /volume1/@appstore/CrashPlan
b. vi syno_package.vars
c. Change “#USR_MAX_HEAP=512M” to “USR_MAX_HEAP=2944M” removing the # and bumping up to 2944.
d. Hit “ESCAPE” – “:wq” – “ENTER”

2. EDIT run.conf
a. cd /volume1/@appstore/CrashPlan/bin
b. vi run.conf
c. Change to “-Xms256m -Xmx2944m” on first line
d. Change to “-Xms128m -Xmx1024m” on second line
d. Hit “ESCAPE” – “:wq” – “ENTER”

3. EDIT CrashPlanEngine
a. cd /volume1/@appstore/CrashPlan/bin
b. vi CrashPlanEngine
c. Add lines (a couple of line above “# Common functions used for…”:
#Increase open files limit
ulimit -n 65536
d. Hit “ESCAPE” – “:wq” – “ENTER”

Steps 2 and 3 Patters says is redundant… but I dont want to jinx myself and change what worked for me :) Any starting stopping issues that I ever came across, were memory related.

Hope this helps,…. and a thousand thanks again Patters!

RAJ

Reply ↓
1. cfpsystems May 22, 2015 at 14:21
  
  Raj,
  
  Thanks. I remember you posting this before. I have an 1813+ that this works on just fine. I also manage a 2015xs that no matter what I try, I cannot increase the heap size on. If I change if from default the package starts and stops immediately. Once I comment out the heap size message it runs again (at least for a while). The client does not stay running for more than a few minutes at a time though.
  
  Wondering if there is something different with the XS (I have 8GB ram in it and would like CPPro to use more than the default. Any ideas?
  
  Charlie-
  
  Reply ↓
2. BigBen July 1, 2015 at 20:07
  
  On a DS 213+ this patch does not work unfortunately.
  CrashPlan can not be started.
  
  Reply ↓
Shane May 22, 2015 at 05:03

Thank you for updating the package on the Synology for CrashPlan. I am now working where I can make IT decisions and have decided to go with a Synology/Crashplan backup solution. My home one works great and the work one is getting there. Thanks for all of your hard work.

Reply ↓
DEXTER May 22, 2015 at 16:48

I also have the same issue on DS413:
NAS> more engine_error.log
Error: Could not find or load main class com.backup42.service.CPService

Is there something broken with the ppc (qoriq) model’s packages?

Reply ↓
hal May 22, 2015 at 20:21

When I updated to the 4.2 package crashplan wouldn’t start. I saw others had this problem. So I uninstalled, and went back to 3.7( which then update to 4.2.) I used chris nelson’s fix to get it running: http://goo.gl/n6OpiH.

Patters,
So the question is should, do I update to the new 4.2 package or is a fix on the way.

thanks for all your work. just donated (again).

Hal

Reply ↓
1. patters Post authorMay 23, 2015 at 09:37
  
  Thanks for the donation. Which model of NAS do you have? I don’t yet understand how some systems have problems with this release. It’s basically unchanged from the 3.7.0-0030 package – only the download links to fetch the CrashPlan installer have been modified.
  
  Reply ↓
  1. hal May 23, 2015 at 10:27
    
    213+
    
    Thanks.
    
    Hal
  2. BJ May 23, 2015 at 11:33
    
    I’ve got the same problem: Synology 213+ with NAS 5.2 5565 update 1 and crashplan 4.2.0 0031. It was working before these updates today…
  3. ded32 May 27, 2015 at 14:26
    
    I have the same problem on 1813+, DSM 5.2-5565 Update 1 and CrashPlan 4.2.0-0031…
    
    Patters, in other reply you’ve told about problems in cpio lib, maybe they are concerned not to PowerPC only?
  4. Tony May 27, 2015 at 19:55
    
    Hi Patters,
    
    Thanks to you I have been able to use Crashplan on my DS 213+ for over 2 years now. I’m now on DSM 5.2 and unfortunately since the recent update of Crashplan I’m unable to start Crashplan. From reading recent posts I have the impression that the issue is specific totgr DS 213+. Can you advise? Many thanks
  5. Tom June 7, 2015 at 19:38
    
    Hi Patters
    I have synced my 415+ (updating the DSM with every new version, now DSM 5.2-5565 Update 1) to Crashplan using your package successfully. Ran into the same problems as many others some weeks ago with the package on the NAS stopping. With your latest package (4.2.0-0031) update this seems to be solved. The Pakcage is running, however the log only shows one line saying the package has started.
    On my PC i was unable to launch the Crashplan client (freezes at the splash screen). I have uninstalls and reinstalled from Code24 (4.2.0). Before i edit the ui.properties the client app launches nicely, but naturally without the option to manage my NAS backup. When i enter the NAS IP address in ui.properties, I am no longer able to launch the client (freezes at the splash screen and says it is unable to connect). I have ping’ed the NAS and know the IP address i correct.
    CrashPlan Backup Report says it’s now 21 days since last activity. I am not very savvy with these things and would highly appreciate help.
    Patters, where do I go to donate, in appreciation for your help?
    Best regards
    Tom
Gijs May 23, 2015 at 10:23

Running DSM 5.2-5565 Update 1 on a Synology DS213+ . Cannot get latest package to work as im getting the errors others (were?) getting for other models;

nas> /var/packages/CrashPlan/scripts/start-stop-status.sh start
Starting CrashPlan …
sed: /var/packages/CrashPlan/target/bin/restartLinux.sh: No such file or directory
find: /var/packages/CrashPlan/target/upgrade: No such file or directory
cp: can’t stat ‘/bin/libffi.so.5’: No such file or directory
/var/packages/CrashPlan/scripts/start-stop-status.sh: line 5: can’t create : nonexistent directory

Anyone had any luck with this?

Reply ↓
nolatron May 23, 2015 at 12:36

I have DS413 running DSM 5.2-5565 Update 1

My crashplan was working fine up until about 2 weeks ago. I’ve uninstalled and reinstalled the lastest clients but it’s not starting.

I installed the Java SE Embedded 7 1.7.0_750031 and Crashplan package 4.2.0-0031

Crashplan never wants to start though. I when I hit run, it tries but the status remains at “Stopped”. When i click View Log link on the Crashplan package screen, it’s blank.

Any idea’s where i can check to see why Crashplan won’t start?

Reply ↓
1. nolatron May 23, 2015 at 12:58
  
  Also, these two log files mentioned in the article don’t exist for me:
  
  /volume1/@appstore/CrashPlan/log/engine_output.log
  /volume1/@appstore/CrashPlan/log/engine_error.log
  
  Thanks!
  
  Reply ↓
  1. nolatron May 27, 2015 at 23:37
    
    Today I tried creating the ‘log’ folder at /volume1/@appstore/CrashPlan/ and now I get these log files generated.
    
    Error I’m getting is:
    
    Error: Could not find or load main class com.backup42.service.CPService
2. slidermike May 26, 2015 at 14:03
  
  My friend who has a ds210+ is having the exact same issue. Worked fine until about 2 weeks ago.
  Now it wont start the crashplan.
  
  Anyone got an idea what we can try?
  Thank you
  
  Reply ↓
Matt Chan May 24, 2015 at 00:37

Hi there,
I’m having similar problems to others since upgrading to DSM 5.2 and CP 4.2 on a 213+
I can’t attempt Chris Nelsons fix as the “upgrade” sub directory doesn’t exist, tried uninstall/reinstall of both the CP and java packages.

If I run the start script, I get the following:
/var/packages/CrashPlan/scripts/start-stop-status start
Starting CrashPlan …
sed: /var/packages/CrashPlan/target/bin/restartLinux.sh: No such file or directory
find: /var/packages/CrashPlan/target/upgrade: No such file or directory
cp: can’t stat ‘/bin/libffi.so.5’: No such file or directory
/var/packages/CrashPlan/scripts/start-stop-status: /var/packages/CrashPlan/scripts/start-stop-status.sh: line 5: can’t create : nonexistent directory

The log folder then contains the following:
cat ./log/engine_error.log
Error: Could not find or load main class com.backup42.service.CPService

Any help would be great.

Cheers
Matt

Reply ↓
Sylar May 24, 2015 at 07:28

Same kind of problem with a DS213+
4.2.0-0031 is not able to start anymore. I get in engine_error.log :
> Error: Could not find or load main class com.backup42.service.CPService

From what I can see, the package stops working around 5/16 (before Patters’s update), probably when Crashplan automatically updated the engine to 4.2?

Reply ↓
undefined undefined May 24, 2015 at 08:35

It seems like every time CrashPlan is updated, all my backups to my DS1513+ are lost and once the various clients connect (local or remote) they do a full backup from scrtach with 0 files showing as backed-up. After this has happened, everything runs fine until the next CrashPlan change. Client updates seem to always trigger this behaviour.

Anyone else seeing this and or knpow how to fix it?

Thanks, Mark

Reply ↓
Marcel May 24, 2015 at 08:43

I have the same issue with my DS413:
Error: Could not find or load main class com.backup42.service.CPService

I tried to uninstall and reinstall the package, but without any luck. It’s also leaving me with a /volume1/@appstore/CrashPlan_data_mig folder where the ./conf folder is located.

Reverting to crashplan3.7.0-merged-0030.spk and upgrading again doesn’t work either. I can’t even get 3.7.0 to work again.

Does anyone have a solution for this ?

Reply ↓
Marcel May 24, 2015 at 08:44

I have the same issue with my DS413:
Error: Could not find or load main class com.backup42.service.CPService

I tried to uninstall and reinstall the package, but without any luck. It’s also leaving me with a /volume1/@appstore/CrashPlan_data_mig folder where the ./conf folder is located.

Reverting to crashplan3.7.0-merged-0030.spk and upgrading again doesn’t work either. I can’t even get 3.7.0 to work again.

Does anyone have a solution for this ? I am on DSM 5.2-5565 Update 1

Reply ↓
Marcel May 24, 2015 at 12:28

I managed to get it working on my DS413. Looks like an issue with cpio. I manually downloaded the linux client from the CrashPlan site. While installing I noticed this message :

cpio: warning: archive header has reverse byte-order
./install.sh: line 345: 22547 Broken pipe cat “${HERE}/${ARCHIVE}”
22548 | gzip -d -c –
22549 Segmentation fault (core dumped) | cpio -i –no-preserve-owner

I created a virtual machine with Ubuntu (I’m using Windows) and copied the installer there.

tar -xvf CrashPlan_4.2.0_Linux.tgz
cd CrashPlan-install/
mkdir /tmp/cp
cp CrashPlan_4.2.0.cpi /tmp/cp
cd /tmp/cp
cat CrashPlan_4.2.0.cpi | gzip -d -c – | cpio -i –no-preserve-owner
rm CrashPlan_4.2.0.cpi

This left me with all necessary files for CrashPlan to run. Next I installed the Crashplan package from this website on my DS413 using Package Center and copied all the files and subfolders from my VM (/tmp/cp) to /volume1/@appstore/CrashPlan . After that I started the package, stopped it and started it again.

Now everything seems to be up and running.

I 05/24/15 12:12PM CrashPlan started, version 4.2.0, GUID xxx
I 05/24/15 02:14PM Stopping CrashPlan
I 05/24/15 12:14PM CrashPlan started, version 4.2.0, GUID xxx
I 05/24/15 12:15PM Backup scheduled to always run

Reply ↓
1. patters Post authorMay 24, 2015 at 20:19
  
  Awesome, thanks for that. I will see if I can find a better cpio binary for PowerPC. Weird thing is that the native bins in my package (which are downloaded separately) were unchanged between 3.7.0 and 4.2.0.
  
  Reply ↓
  1. Marcel May 25, 2015 at 11:52
    
    It has something to do with the cpio package that comes from Code42. I downloaded your crashplan-native-ppc.tar.xz and extracted cpio from it. From the Code42 site I downloaded a cpio file for CrashPlan 3.7.0 (in this case the Pro version, but that’s not necessarily relevant for this issue) to test it against the cpio in your package.
    
    DiskStation> cat CrashPlan_4.2.0.cpi | gzip -d -c | ./cpio -i –no-preserve-owner
    ./cpio: warning: archive header has reverse byte-order
    Segmentation fault (core dumped)
    
    DiskStation> cat CrashPlanPROe_3.7.0.cpi | gzip -d -c | ./cpio -i –no-preserve-owner
    49872 blocks
  2. Marcel May 25, 2015 at 12:03
    
    DiskStation> file -z CrashPlanPROe_3.7.0.cpi
    CrashPlanPROe_3.7.0.cpi: ASCII cpio archive (pre-SVR4 or odc) (gzip compressed data, was “CrashPlanPROe_3.7.0.cpi”, from Unix, last modified: Thu Nov 20 16:12:26 2014, max compression)
    
    DiskStation> file -z CrashPlan_4.2.0.cpi
    CrashPlan_4.2.0.cpi: byte-swapped cpio archive (gzip compressed data, was “CrashPlan_4.2.0.cpi”, from Unix, last modified: Thu May 7 16:08:00 2015, max compression)
    
    At least they were archived differently. Maybe a bug in cpio for PPC-architecture ?
  3. Marcel May 25, 2015 at 12:44
    
    Downloaded version 2.11 of cpio from https://www.gnu.org/software/cpio/ and compiled it on my DS413. Had to use ipkg to install gcc and make. The freshly compiled cpio does not crash.
    
    DiskStation> cat CrashPlan_4.2.0.cpi | gzip -d -c | ./cpio -i –no-preserve-owner
    ./cpio: warning: archive header has reverse byte-order
    56059 blocks
    
    DiskStation> ls -al
    total 24792
    drwxr-xr-x 10 root root 4096 2015-05-25 12:43 .
    drwxrwxrwt 6 root root 4096 2015-05-25 12:37 ..
    drwxr-xr-x 2 root root 4096 2015-05-25 12:43 bin
    drwxr-xr-x 2 root root 4096 2015-05-25 12:43 conf
    -rwxr-xr-x 1 root root 346051 2015-05-25 12:30 cpio
    -rw-r–r– 1 root root 24342646 2015-05-24 11:50 CrashPlan_4.2.0.cpi
    drwxr-xr-x 2 root root 4096 2015-05-25 12:43 doc
    -rw-r–r– 1 root root 330 2015-05-25 12:43 jniwrap.lic
    drwxr-xr-x 2 root root 4096 2015-05-25 12:43 lang
    drwxr-xr-x 2 root root 4096 2015-05-25 12:43 lib
    -rw-r–r– 1 root root 48344 2015-05-25 12:43 libjniwrap64.so
    -rw-r–r– 1 root root 24756 2015-05-25 12:43 libjniwrap.so
    -rw-r–r– 1 root root 287934 2015-05-25 12:43 libjtux64.so
    -rw-r–r– 1 root root 257693 2015-05-25 12:43 libjtux.so
    -rw-r–r– 1 root root 8417 2015-05-25 12:43 libmd564.so
    -rw-r–r– 1 root root 7346 2015-05-25 12:43 libmd5.so
    drwxr-xr-x 2 root root 4096 2015-05-25 12:43 log
    drwxr-xr-x 2 root root 4096 2015-05-25 12:43 skin
    drwxr-xr-x 3 root root 4096 2015-05-25 12:43 upgrade
2. Andy June 1, 2015 at 06:26
  
  I was able to get my DS 213+ working with CrashPlan 4.2.0 following Marcel’s instructions. Early on I’d uninstalled and tried reinstalling. So after CrashPlan was running again I additionally had to follow the instructions to “adopt computer”.
  
  Reply ↓
gernotstarke May 24, 2015 at 13:10

on DSM 5.2, the CrashPlan upgrade to 4.2 broke everything…
the nice post http://chrisnelson.ca/tag/crashplan/ didn’t help,
as I could not locate jar-files at all… the new installer contains a huge cpi-file,
manually unpacking and extracting didn’t help.

Could not locate any previous installers – would very much love to go back to CrashPlan 3.x
version without auto-update :-(

I can imagine that loads of NAS-admins/owners would even pay for a working CrashPlan
installation/version on their machines – at least I would…

best,
Gernot

Reply ↓
Mark Johnson May 25, 2015 at 19:14

I wonder if someone can help. Every time, the CrashPlan client updates and I re-install the CrashPlan server component on my Synology DS1513+ I lose all existing backups on my Synology device for both the clients on my local and remote networks. It has just happened again on the 4.2.0 update.

I first updated to 4.2.0 based on advice in this thread using SFTP and all worked correctly. However, when the official package update appeared I ran that also to get to a “clean” position and once again, all the previous back-ups “disappeared” and the clients started doing a full backup from scratch.

Has anyone else experienced this problem and aware of a fix or how to avoid it in future?

Thanks, Mark

Reply ↓
1. AJ Willmer May 25, 2015 at 20:32
  
  You may find that your configuration in /volume1/@appstore/CrashPlan/conf/my.service.xml is being reset to a new/fresh install.
  
  Reply ↓
  1. Mark Johnson May 27, 2015 at 21:16
    
    Thanks for the response.
    
    How do I avoid the my.service.xml file being reset? I assume as its not a common problem it must be something to do with my setup that this happens?
  2. AJ Willmer May 27, 2015 at 23:09
    
    Yes happened to me but we seem to be outliers. There is a dir called /volume1/@appstore/CrashPlan_data_mig …. and I put a copy of my config files in there but I really don’t know the function of that dir. For may part I was having an issue I could not resolve and so I performed an UNinstall of patters app, and reinstalled. I suspect that is where I lost my configuration. I am presuming that any auto update will NOT cause a problem.
  3. Mark Johnson May 30, 2015 at 11:20
    
    I lost all my backups for local and remote network clients during an auto update. This has happened to me every time since I first started using Crash Plan on my Synology during an auto update.
    
    Not sure how to proceed really. Anyone got any pointers on how to diagnose/resolve? Any thoughts much appreciated.
    
    Thanks
Jim May 25, 2015 at 20:02

Hi. I cannot get my Crashplan to run on the Diskstation. It is a 210+ and has the latest DSM on it (5.2-5565 Update 1) and Crashplan 4.2. View Log on the DS shows a blank screen. There are no logs in /volume1/@appstore/CrashPlan/log/engine_output.log or /volume1/@appstore/CrashPlan/log/engine_error.log I guess cause it cannot run? There used to be logs before I completely uninstalled and installed everything trying to fix this problem.
Thanks for any direction you can give me!

Reply ↓
Ian May 26, 2015 at 02:20

I have a DS413 as well and am having the same issue described in the comments above. I uninstalled 4.3 and re-installed 3.7.0-0030 followed the CrashPlan 4.2.0/DSM 5.2 fix and it’s working again.

Reply ↓
Patrick May 26, 2015 at 18:14

Just got it working on my DS212j. Great stuff!! I was struggling for a bit until I discovered that I forgot to delete the # in conf/ui.properties, #serviceHost=127.0.0.1. I replaced the IP address with the one to my DS212j but as said forgot to remove the #.
But when that was fixed, it works like a charm!
Running DSM 5.2-5565 and Java SE Embedded 8 ver 1.8.0_33-0031.
MANY thanks for the great work!!!

Reply ↓
Jon Kensy (@JonKensy) May 26, 2015 at 18:42

Hey guys – just tried installing on a DS214 running DSM 5.2-5565 Update 1, installed Java as usual go to install the CrashPlan package thru “Community” and get: Failed to install “Crashplan” – nothing I do seems to fix it. I was able to install this on a DS214+ a few weeks ago. Can anyone assist?

Reply ↓
ded32 May 26, 2015 at 23:21

After upgrading DSM to 5.2-5565 Update 1 and CrashPlan to 4.2.0-0031 on DS 1813+, CrashPlan app stops immediately after starting. I see only this in the history.log.0 file:

I 05/26/15 12:53AM CrashPlan started, version 4.2.0, GUID XXXXXXXXXXXXXXXXXX
I 05/26/15 12:53AM CrashPlan stopped, version 4.2.0, GUID XXXXXXXXXXXXXXXXXX

Before these updates, it was working.
There are no pending updates in /var/packages/CrashPlan/target/upgrade folder.
I tried to re-install Java 6/7 and CrashPlan, but it did not help.

Have anyone any solution or workaround?

Reply ↓
Jim May 27, 2015 at 18:47

Has anyone had any luck with the starting/stopping issue? I still cannot get Crashplan 3.7 or 4.2 to run on my DS210+ with DSM 5.2. I have tried most of the things recommended in this Comment section with no luck. Thanks!

Reply ↓
Patrick May 27, 2015 at 20:13

On my DS212j, with DSM version 5.2-5565, and crashplan ver 4.2.0-0031 and java SE Embedded 8 ver 1.8.0-33.0031, crashplan is running fine. Just installed it so it’s heavily occupied doing the initial backup

Reply ↓
Scott Koland May 29, 2015 at 00:52

I am running into a similar issue on my 213+ with CrashPlan 4.2.0.0031 and DSM 5.2-5565 Update 1. Since the DSM update, CP has not been able to run. I noticed here that others are using Java 1.8, but when I uninstall 1.7 and try to install 1.8.0_6-0031, it fails because I don’t have the proper package – ejdk-8u6-fcs-b23-linux-ppc-e500v2-12_jun_2014.tar.gz. I cannot find where to download that package from the java site.
Should I be using Java 1.7 or 1.8 on my 213+? If 1.8, where do I get that package?
Thanks.

Reply ↓
1. hal sandick May 29, 2015 at 01:45
  
  I also have a ds213+. I’d like to know which version of java to be using.
  
  hal
  
  Reply ↓
  1. Alex June 8, 2015 at 09:25
    
    You need the latest Java 7 for Power Architecture. That’s the one I’m using with DSM 5.1 and Crashplan 4.2
    I’m learning my lesson now and leaving DSM be for as long as possible. Upgrading seems to be a great way of losing hours to fixing my backups as far as I’m concerned.
    
    http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html
    Power Architecture Linux – Headless – e500v2 with double-precision SPE Floating Point Unit
  2. Scott Koland June 20, 2015 at 20:46
    
    Just to confirm, I am now successfully running Java 1.7 with CP 4.2.0.0031 on my ds213+.
Ben Waller May 29, 2015 at 05:36

HI,
Upgrade to CP 4.2 on DSM 5.2 caused CP to stop. Manually downgraded to 3.7 and CP package is running again. Download 3.7 here: http://packages.pcloadletter.co.uk/downloads/old/

He will fix this, just be patient.

Reply ↓
1. patters Post authorMay 30, 2015 at 09:16
  
  I need SSH access to a test DS413 system in order to fix. A contact I have previously used seems to be away. Please post here if you can help, and I’ll email you asking for credentials. Thanks!
  
  Reply ↓
  1. ST May 30, 2015 at 10:28
    
    Hi,
    
    I can give you ssh to DS413. However, it’s not exposed to Internet. Therefore, please let me know if teamviewer / skype + desktop sharing + SSH from my desk will work for you.
    
    Thanks.
  2. Jim May 30, 2015 at 12:56
    
    Hi. I have a DS 210+ you can have access to if you’d like. It is having this problem and I cannot get it working at all.
  3. ded32 May 30, 2015 at 18:19
    
    Hi Patters,
    
    I can grant you access to DS 1813+ with the same symptoms right now.
Tony May 30, 2015 at 17:59

Hi Patters,

Thanks to you I have been able to use Crashplan on my DS 213+ for over 2 years now. I’m now on DSM 5.2 and unfortunately since the recent update of Crashplan I’m unable to start Crashplan. From reading recent posts I have the impression that the issue is specific to the DS 213+. Can you advise? Many thanks

Reply ↓
1. patters Post authorJune 2, 2015 at 14:27
  
  Does it work now? I’ve updated the cpio binary for Intel systems – could be the same fault as with PowerPC.
  
  Reply ↓
  1. Tony June 2, 2015 at 17:34
    
    It’s working perfectly Patters. A grateful donation is headed your way.
    
    Many thanks for your support; very much appreciated,
    
    Anthony
Eponym May 30, 2015 at 18:44

After being unable to backup for over 20 days I finally decided to follow a suggestion posted in this forum. And I got my DS213+ DSM5.2 to backup again.

Here are the steps, again I am just repeating what was already mentioned by many folks earlier, perhaps with a little less detail:
1. Uninstalled CrashPlan 4.2. by selecting Uninstall from the Action dropdown in the Synology Package Center.
2. Downloaded the old package crashplan3.7.0-merged-0030.spk from http://packages.pcloadletter.co.uk/downloads/old/
3. Back in the Synology Package Center used the Manual Install button and installed the downloaded file.
4. Started the CrasPlan Package and waited a few minutes, it will download the upgrade to 4.2.0 and then stop running. Checked the log using View Log link in the Package Center.
5. Tried to start package one more time. It attempts to install 4.2.0 (Synology repairing upgrade…) but fails and stops.
The updated package from Patters to new version 4.2.0-0031 now becomes available but I did not install it.
6. Ran the commands explained in http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/. For some reason I got some errors and wannings running the commands by just copying and pasting the absolute paths, so I drilled down into the directories.

I was now able to start CrashPlan and I am back in business.
Not sure if I should still install the update package from Patters. For now I’ll leave it as is.

Reply ↓
daversion May 31, 2015 at 05:18

My DS115j cannot install the package (generic error) but it has the Armada 370 chipset. Any helpful thoughts before I upgrade to the 215j to make CrashPlan work? Thanks!

Reply ↓
1. patters Post authorJune 2, 2015 at 13:41
  
  Would I be able to get SSH root access to your NAS in order to troubleshoot perhaps? If yes, let me know on here and I can email you privately for connection details.
  
  Reply ↓
  1. ded32 June 2, 2015 at 18:14
    
    Hi Patters,
    
    I just sent you a letter with access details to 1813+.
  2. daversion June 6, 2015 at 03:14
    
    Hi, sure there’s nothing on the DiskStation, anyway. My username is the local part of my email address.
  3. daversion June 6, 2015 at 04:05
    
    Foolish oversight. I had to go to Package Center -> Settings -> Trust Level -> Any Publisher. Might be good to add this to your installation instructions?
    
    Now I’m trying to locate CrashPlan even though it says its running – I can’t see it in the list of application shortcuts.
ProfMars May 31, 2015 at 10:36

I did a remove of CrashPlan from my DS413 and did a fresh install of the CrashPlan package, which renders little result as there is not even a log file available to troubleshoot against.
How can we fix this isue ?

Reply ↓
1. patters Post authorJune 2, 2015 at 13:38
  
  It should be fixed now. I had to cross compile a newer version of cpio from source. This binary is used to extract the CrashPlan software after it’s downloaded, but cpio is not included in Synology DSM so I need to provide a native binary with my package. Old version was 2.9, new version is latest 2.11. I had continued to use an old one for a long time because the newest version fails to cross compile properly without a patch to fix. For some reason, the CrashPlan 4.2.0 software archive causes a segfault when extracted with the older cpio binary.
  
  Reply ↓
  1. Jim June 2, 2015 at 13:46
    
    Thank you! I have uninstalled and installed and it is running on my 210+ ! So far so good.
ProfMars May 31, 2015 at 11:21

Ok, gave it another go to try and fix this. And was succesful in the end. These are the steps I took :

Steps taken :
1. remove Crashplan package using package center
2. download the package named “crashplan3.7.0-merged-0030.spk” from http://packages.pcloadletter.co.uk/downloads/old/crashplan3.7.0-merged-0030.spk
3. Manually install that package in the package center
4. Run/start the package -DO NOT PRESS THE UPDATE BUTTON in DSM UI-
5. It will download the 4.2.0 update in the background
6. Press run again to make sure everyting is ready for the “fix” in the next step
7. Follow the procedure as described here : http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/

For me this worked like a charm, hope this helps others too.

NOTE : Do not press the update button in the DSM package center UI, as this will break things again !!!

Reply ↓
Olivier Greoli May 31, 2015 at 11:51

Same problem with the latest update.

Reply ↓
Isiah June 2, 2015 at 11:08

Is there any update of startup problem in DS413 with latest DSM ? I didn’t backup for few days already :(

Reply ↓
1. patters Post authorJune 2, 2015 at 13:37
  
  It should be fixed now. I had to cross compile a newer version of cpio from source. This binary is used to extract the CrashPlan software after it’s downloaded, but cpio is not included in Synology DSM so I need to provide a native binary with my package. Old version was 2.9, new version is latest 2.11. I had continued to use an old one for a long time because the newest version fails to cross compile properly without a patch to fix. For some reason, the CrashPlan 4.2.0 software archive causes a segfault when extracted with the older cpio binary.
  
  Reply ↓
  1. hal June 2, 2015 at 13:48
    
    what is the number of your new package?
  2. patters Post authorJune 2, 2015 at 14:05
    
    Unchanged. It’s the native bins that are retrieved during installation that are updated. You can force an upgrade by editing /var/packages/CrashPlan/INFO and rolling the version number back if you don’t want to uninstall completely.
    
    I have a feeling that the same fix will be required to fix the DS1813+ issue also, so I’ve just compiled a new cpio binary for Intel systems. That change is also now live. Once it’s confirmed working I’ll push it as a new version on the repository to make it easier for most users.
Steve Lane June 2, 2015 at 12:40

I can’t get this installed.

I followed the instructions on this site: http://www.hanselman.com/blog/UPDATED2014HowToSetupCrashPlanCloudBackupOnASynologyNASRunningDSM50.aspx

My info:
DS115j
CPU
MARVELL Armada 370 88F6707
CPU clock rate
800 MHz
CPU cores
1
Total physical memory
256 MB
DSM version
DSM 5.2-5565 Update 1

When I click install, it shows a download dialogue box and it remains at 0%. It then changes window to the licence agreement. I click next. I then click apply. It then says installing, followed by failed to install “crashplan” and my only option is to click OK.

Can anyone help? Please don’t ask me to ssh to the command line etc. I am looking for the non-geek option.

Reply ↓
Joel June 2, 2015 at 13:27

It seems I am not the only one affected with DS413.
I currently have the latest crashplan version (4.2.0-0031) with the latest DSM (5.2-5565 Update 1) and I cannot get crashplan to start.
I’ve gone through the files via ssh but don’t want to make changes in case it breaks something later.

DiskStation> pwd
/var/packages/CrashPlan/scripts
DiskStation> ./start-stop-status.sh
grep: ./target/bin/run.conf: No such file or directory
./start-stop-status.sh: source: line 20: can’t open ‘./target/install.vars’

Looks like it may be looking in the wrong directory. Perhaps it might be ‘../target/…’?
DiskStation> ls -l /var/packages/CrashPlan/target/install.vars
-rw-r–r– 1 root root 388 May 22 19:42 /var/packages/CrashPlan/target/install.vars

Reply ↓
patters Post authorJune 2, 2015 at 13:46

The failure to install on PowerPC should be fixed now. I had to cross compile a newer version of cpio from source. This binary is used to extract the CrashPlan software after it’s downloaded, but cpio is not included in Synology DSM so I need to provide a native binary with my package. Old version was 2.9, new version is latest 2.11. I had continued to use an old one for a long time because the newest version fails to cross compile properly without a patch to fix. For some reason, the CrashPlan 4.2.0 software archive causes a segfault when extracted with the older cpio binary.

Reply ↓
1. Olivier Greoli June 2, 2015 at 19:08
  
  Thanks for all the time you are devoting for this useful package on Synology !
  
  Reply ↓
2. Claude Philipona June 2, 2015 at 19:41
  
  It works perfectly on my DS213+ now. Thanks.
  
  Reply ↓
3. hal June 2, 2015 at 20:52
  
  is now working on my 213+. Thanks
  
  Reply ↓
4. Joel June 2, 2015 at 21:01
  
  Hi patters,
  It doesn’t seem to be fixed for my DS413 yet.
  Is there something I need to do to activate the update? I tried refreshing under Package Center, running crashplan via the GUI several time, but no change. The latest version I see is still 4.2.0-0031.
  Thanks again for all your hard work!
  
  Reply ↓
  1. woolyninja June 3, 2015 at 00:51
    
    You need to go into package manager and uninstall the package and reinstall it. Should work after that.
  2. patters Post authorJune 3, 2015 at 08:02
    
    The package itself is unchanged. It’s the native bins that are retrieved during installation that are updated. You can force an upgrade by editing /var/packages/CrashPlan/INFO and rolling the version number back if you don’t want to uninstall and reinstall.
5. woolyninja June 3, 2015 at 00:53
  
  Thanks patters! Going to donate if I can find the link.
  
  Reply ↓
DSwan June 3, 2015 at 01:15

New and improved version 4.2.0-0031 works great (DS413, latest DSM). Edited /var/packages/CrashPlan/INFO as recommended above so I could “re-update” and not have to uninstall and reinstall. Thanks patters! Donation sent.

Reply ↓
James Abella June 3, 2015 at 05:38

Thank you Patters, I appreciate your continued efforts on supplying these updates/patches for us. Paypal donation coming your way!

Reply ↓
RC June 4, 2015 at 02:39

Also having the same problem after an upgrade to DSM 5.2-5565 Update 1, DS413, CrashPlan 4.2.0 Build 61, latest Patters CrashPlan package, both before and after an uninstall.

Please let me know if there is a way to resolve this or if I can provide more info.

Thanks.

Reply ↓
1. RC June 4, 2015 at 02:59
  
  Ah. I missed that your version number did not change. After reading through more carefully, I uninstalled / reinstalled again, and things are beginning to backup again.
  
  Much thanks. I’ll send a donation.
  
  Reply ↓
Derek Watson June 4, 2015 at 04:13

Ok I am having a weird issue that may have started with 4.2.0-0031 or it may have happened before but I am not sure…. I have my backup set to run only between 1 to 6 AM (bandwidth issues) through the Crashplan app settings. It used to work fine, but now it seems that Crashplan will more or less run forever ignoring these settings… Has anyone else run into this issue?

Reply ↓
1. patters Post authorJune 4, 2015 at 07:24
  
  I schedule my backups using DSM’s own Task Scheduler. Create a pair of new Service jobs and configure one to start and the other to stop the service. Make sure it’s active during the daily archive maintenance period at 03:00. If you use this method, you’re not wasting precious RAM on an idle CrashPlan the rest of the time.
  
  Reply ↓
Isiah June 8, 2015 at 00:52

Since there’s no news of the startup problem of 4.2.0-0031 yet, can I have the instruction of restore to last working version? Thanks.

Reply ↓
Tom June 8, 2015 at 07:10

Hi Patters
I have synced my 415+ (updating the DSM with every new version, now DSM 5.2-5565 Update 1) to Crashplan using your package successfully. Ran into the same problems as many others some weeks ago with the package on the NAS stopping. With your latest package (4.2.0-0031) update this seems to be solved. The Pakcage is running, however the log only shows one line saying the package has started.
On my PC i was unable to launch the Crashplan client (freezes at the splash screen). I have uninstalls and reinstalled from Code24 (4.2.0). Before i edit the ui.properties the client app launches nicely, but naturally without the option to manage my NAS backup. When i enter the NAS IP address in ui.properties, I am no longer able to launch the client (freezes at the splash screen and says it is unable to connect). I have pinged the NAS and know the IP address i correct.
CrashPlan Backup Report says it’s now 21 days since last activity. I am not very savvy with these things and would highly appreciate help.
Patters, where do I go to donate, in appreciation for your help?
Best regards
Tom

Reply ↓
Chris June 9, 2015 at 14:05

I am in the same boat, I have a DS413J and I can’t start the crashplan service (or I should say, the service will not stay running..I can start it and then it stops). Any ideas?

Reply ↓
alex84 June 14, 2015 at 22:03

My crashplan keeps restarting after 1mn (just when it gets above 1GB RAM). I’ve set to 3072M in both syno_package.vars and run.conf. What can I do? Thanks!

Reply ↓
1. ethuesen June 23, 2015 at 07:45
  
  I got the exact same issue – my CrashPlan is restarting every 3 minutes.
  It looks like it is restarting every time the Java process is reaching 800 MB of RAM.
  However, I have not been modifying any CrashPlan files. In fact I just tried to reinstall both the CrashPlan package and Java, which did not fix the problem.
  I have tried lowering the Java heap size, but it looks like CrashPlan will not respect the new limit.
  
  Does anyone know how to fix this. I’m on a DS412+ upgraded to 2GB of RAM. I can provide log files if needed.
  
  Reply ↓
Haburi June 16, 2015 at 00:23

Hi, I am trying to install Crashplan for the first time (4.2) package and it seems like it installs fine .. I made the client modifications to connect to my NAS but the client won’t connect.

I noticed something odd too – in the documentation for installing Crashplan it says it should create a crashplan user, but it doesn’t. Further confirming this, I noticed this in the messages log when I went to uninstall crashplan:

user_delete.c:517 SYNOUserDbGet(CRASHPLAN) failed [0x1D00 user_db_get.c:53]

Doesn’t seem like the user ever gets created.

Reply ↓
1. patters Post authorJune 16, 2015 at 08:10
  
  A number of versions ago I changed it to run as root since I noticed that’s the way Synology tend to do their own official packages, and since it’s something which interacts to tightly with the filesystem. The daemon user being re-created each upgrade was causing complications so it made sense to change to root. The call to remove the user was left in for a few versions to ensure that all the legacy installations are cleared up properly. The documentation blog post is now considerably out of date and needs refreshing.
  
  Reply ↓
  1. Mike Solin July 1, 2015 at 12:43
    
    Does that mean I don’t need the ‘crashplan’ folder anymore? It contains an empty folder called ‘backupArchives’. Is that safe to delete from File Station?
    
    Thanks!
Pella69 June 19, 2015 at 09:30

Dear All,
I have an issue connecting with CrashPlan Central Cloud.
In the log I have this:
“IOException in Factory:, java.nio.channels.ClosedChannelException”
Anyone could help me?

Thank you

Reply ↓