CrashPlan packages for Synology NAS

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.


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:
    Add 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:
    Trust Level
  • 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 ( means the server is listening for connections on all interfaces) e.g.:

    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:
    assuming that the Synology NAS has the IP
    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/” (Mac OS X installed for all users)
    “~/Library/Application Support/CrashPlan/” (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!


  • 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:
  • 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:
    Schedule service start
    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:
    Schedule Service Start

  • 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.


#--------CRASHPLAN installer script
#--------package maintained at

[ "${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
  [ "${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=""
  [ "${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"
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_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
OLD_JNA_FILE="`echo ${OLD_JNA_URL} | sed -r "s%^.*/(.*)%\1%"`"
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"
UPGRADE_FILES="syno_package.vars conf/my.service.xml conf/service.login conf/service.model"
PUBLIC_FOLDER="`synoshare --get public | sed -r "/Path/!d;s/^.*\[(.*)\].*$/\1/"`"
#dedicated JRE section
if [ "${WIZARD_JRE_CP}" == "true" ]; then
  #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_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
  elif [ "${SYNO_CPU_ARCH}" == "armv7l" ]; then
    JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
  elif [ "${SYNO_CPU_ARCH}" == "armhf" ]; then
    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_BUILD="Power Architecture Linux - Headless - e500v2 with double-precision SPE Floating Point Unit"
  elif [ "${SYNO_CPU_ARCH}" == "i686" ]; then
    JAVA_BUILD="x86 Linux Small Footprint - Headless"
  elif [ "${SYNO_CPU_ARCH}" == "x64" ]; then
    JAVA_BUILD="Linux x64"
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

    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz ] && JAVA_BINARY_FOUND=true
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.tar ] && 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
    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" >> $SYNOPKG_TEMP_LOGFILE
      exit 1

    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" >> $SYNOPKG_TEMP_LOGFILE
      exit 1

    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

preinst ()
    WGET_FILENAME="`echo ${WGET_URL} | sed -r "s%^.*/(.*)%\1%"`"
    wget ${WGET_URL}
    if [[ $? != 0 ]]; then
      if [ -d ${PUBLIC_FOLDER} ] && [ -f ${PUBLIC_FOLDER}/${WGET_FILENAME} ]; then
        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
  exit 0

postinst ()
  if [ "${WIZARD_JRE_CP}" == "true" ]; then
    #extract Java (Web browsers love to interfere with .tar.gz files)
    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
      tar xzf ${JAVA_BINARY}.gz
    elif [ -f ${JAVA_BINARY}.tar ]; then
      tar xf ${JAVA_BINARY}.tar
    elif [ -f ${JAVA_BINARY}.tar.tar ]; then
      #Internet Explorer
      tar xzf ${JAVA_BINARY}.tar.tar
    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}
  #extract CPU-specific additional binaries
  mkdir ${SYNOPKG_PKGDEST}/bin
  [ "${OLD_JNA_NEEDED}" == "true" ] && tar xJf ${TEMP_FOLDER}/${OLD_JNA_FILE} && rm ${TEMP_FOLDER}/${OLD_JNA_FILE}

  #extract main archive
  #extract cpio archive
  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 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
  #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}/

  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
  [ -e ${OPTDIR}/lib/ ] && rm ${OPTDIR}/lib/

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

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

 exit 0

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

  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
      if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ]; then
    if [ -d ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ]; then
    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}
  exit 0


#--------CRASHPLAN start-stop-status script
#--------package maintained at

TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan" 
PKG_FOLDER="`dirname $0 | cut -f1-4 -d'/'`"
DNAME="`dirname $0 | cut -f4 -d'/'`"
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"`"
source ${OPTDIR}/install.vars
source /etc/profile
source /root/.profile

start_daemon ()
  #check persistent variables from syno_package.vars
  if [ -f ${OPTDIR}/syno_package.vars ]; then
    source ${OPTDIR}/syno_package.vars
  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/

  #fix up some of the binary paths and fix some command syntax for busybox 
  #moved this to from 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}"

  #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/

  #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 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

  #updates may also overwrite our native binaries
  [ -e ${OPTDIR}/bin/ ] && cp -f ${OPTDIR}/bin/ ${OPTDIR}/lib/
  [ -e ${OPTDIR}/bin/ ] && cp -f ${OPTDIR}/bin/ ${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/

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

  #set appropriate Java max heap size
  RAM=$((`free | grep Mem: | sed -e "s/^ *Mem: *\([0-9]*\).*$/\1/"`/1024))
  if [ $RAM -le 128 ]; then
  elif [ $RAM -le 256 ]; then
  elif [ $RAM -le 512 ]; then
  elif [ $RAM -le 1024 ]; then
  elif [ $RAM -gt 1024 ]; then
  if [ $USR_MAX_HEAP -gt $JAVA_MAX_HEAP ]; then
  if [ $JAVA_MAX_HEAP -lt $JAVA_MIN_HEAP ]; then
    #can't have a max heap lower than min heap (ARM low RAM systems)
  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}"

  #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${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/ 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

    #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\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
    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}"

  #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
  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}
    [ -z ${LANG} ] && export LANG=en_US.utf8
    export CLASSPATH=.:${OPTDIR}/jre-syno/lib

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

  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
    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

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
  #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
  rm -f ${PID_FILE}
  return 1

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

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

    if daemon_status; then
      echo Stopping ${DNAME} ...
      exit $?
      echo ${DNAME} is not running
      exit 0

    exit $?

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

    echo "${DLOG}"
    exit 0

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


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": "",
            "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


  • 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
  • 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
  • 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 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 taken from Debian JNA 3.2.7 package with dependency on newer (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 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), 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
  • 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 to 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 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 each startup
  • 003 fixed ownership of /volume1/crashplan folder
  • 002 updated to CrashPlan 3.2
  • 001 30/Jan/12 – intial public release

6,687 thoughts on “CrashPlan packages for Synology NAS

  1. Matt Davis

    As always, thank you Patters for maintaining this package (and this page). It’s been very helpful and much appreciated. I have two questions…

    1) I’ve seen a few mentions of running Crashplan in Docker. I know very little about what this actually means. What are the advantages? Will it be less likely to break when there are updates? Are there any disadvantages?

    2) This is a great site — but the stream of comments gets very time-consuming to wade through. Wouldn’t it be worthwhile to restart the question/answer materials in a forum — like Google Groups or something? Seems that the threads would be easier to follow and the information would be more easily accessible.

  2. Alfred

    I’m up and running now on DSM 5.2 on a DS415+

    I tried all solutions on

    Nothing helped. The update came in but was not processed and gave the “upgrade failed” message. After following these instructions form Aaron P:

    Here’s what worked for me, since all else failed on DSM 5.2. These steps assume you’ve already done Suggestion 1 above. The paths also assume you are running CrashPlan PRO.

    Install ipkg:

    Install bash and coreutils via ipkg:
    ipkg install -A bash
    ipkg install -A coreutils

    Symlink so CrashPlan can find them:
    ln -s /opt/bin/bash /bin/bash
    ln -s /opt/bin/nice /bin/nice

    Back up install.vars and syno_package.vars:
    cp /var/packages/CrashPlanPRO/target/install.vars ~/
    cp /var/packages/CrashPlanPRO/target/syno_package.vars ~/

    Uninstall CrashPlan via Package Center
    Install CrashPlan via Package Center

    After a fresh install the update came in and was processed in the right way. Today I did the update from Patters and everything is working fine!

    So the key was answer of Aaron P and following suggestion 1 on I hope it helps more people.

  3. Yvonus

    Working like a charm on DS415+. Auto upgrade worked flawlessly.
    Thank you so much for your work. I still hope that Code42 will support (some) Synology boxes, just like other (more standard) connectors to S3, etc…
    This way, we’ll stop bothering you everytime Code42 build a new (Synology incompatible) package ;-)
    Thanks again

  4. Mathew Beall

    Is anyone else seeing this message in their notification window? Synology is suggesting it is because of crashplan (unsupported software running on the box). I am running the lastest versions of crashplan and DSM.

    DSM cannot start up normally because it ran into a problem. Please contact the Synology support team for help.

    Nothing seems to be problematic with my array – but this message appears every 2-4 hours in the notification window.


      1. Mathew Beall

        Here is the message in the notification window:

        “DSM cannot start up normally because it ran into a problem. Please contact the Synology support team for help.”

        When I contacted them they said to remove crashplan, and if that didn’t resolve it – to reinstall DSM from scratch.. :/

        I am going to uninstall crashplan and see if I have this error message over night.


  5. Eugene Archibald

    Thanks for all your work!

    I’m managing CrashPlan on my DiskStation and also for a friend’s, so I threw together a bash script to retrieve .ui_info, massage it, and drop it into the user-specific or system-wide .ui_info, then launch the CrashPlan client. It’s got paths for OS X and Linux (but er…it needs conditional logic to run the Linux binary instead of the OS X one. Wups.):

    earchibald$ ./
    Connection to port 22 [tcp/ssh] succeeded!
    Fetching .ui_info from as user admin…
    Executing sudo to edit /Library/Application Support/CrashPlan/.ui_info (may require your user password)…
    Opening CrashPlan client…

  6. Ian H

    It’s all working again ! Great – thanks Patters.
    Using a DS215j – any suggestions for improving upload speeds .. I’m sure it used to run faster … (my Virgin internet is pretty quick 12 Mbps upload 200 download – so that should’t be the problem.)
    I did a clean install of the latest version and didn’t change any of the defaults.
    Network settings in crashplan client are set to have no limits.

    1. Jeff

      I had to temporarily disable the virus scan to maximize the upload speed. 512MB on the DS216j is a limitation.

  7. RC

    Completely reinstalled the new package, using a DS215j, but still getting a similar result, in which the CrashPlan package starts and stops every few minutes. Is this normal?

    I 05/26/16 09:45PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 09:45PM [Default] Scanning for files to back up
    I 05/26/16 09:45PM Backup scheduled to always run
    I 05/26/16 09:48PM [Default] Starting backup to CrashPlan Central: 25 files (714.50KB) to back up
    I 05/26/16 09:52PM Stopping CrashPlan
    I 05/26/16 09:52PM [Default] Scanning for files stopped
    I 05/26/16 09:53PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 09:53PM [Default] Scanning for files to back up
    I 05/26/16 09:53PM Backup scheduled to always run
    I 05/26/16 09:57PM [Default] Starting backup to CrashPlan Central: 8 files (548.50KB) to back up
    I 05/26/16 10:00PM Stopping CrashPlan
    I 05/26/16 10:01PM [Default] Scanning for files stopped
    I 05/26/16 10:01PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 10:02PM [Default] Scanning for files to back up
    I 05/26/16 10:02PM Backup scheduled to always run
    I 05/26/16 10:05PM [Default] Starting backup to CrashPlan Central: 8 files (548.50KB) to back up
    I 05/26/16 10:09PM Stopping CrashPlan
    I 05/26/16 10:09PM [Default] Scanning for files stopped
    I 05/26/16 10:10PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 10:10PM [Default] Scanning for files to back up
    I 05/26/16 10:10PM Backup scheduled to always run
    I 05/26/16 10:14PM [Default] Starting backup to CrashPlan Central: 8 files (548.50KB) to back up
    I 05/26/16 10:18PM Stopping CrashPlan
    I 05/26/16 10:18PM [Default] Scanning for files stopped
    I 05/26/16 10:18PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 10:19PM [Default] Scanning for files to back up
    I 05/26/16 10:19PM Backup scheduled to always run
    I 05/26/16 10:22PM [Default] Starting backup to CrashPlan Central: 1 file (167.90KB) to back up
    I 05/26/16 10:28PM Stopping CrashPlan
    I 05/26/16 10:28PM [Default] Scanning for files stopped
    I 05/26/16 10:29PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 10:30PM [Default] Scanning for files to back up
    I 05/26/16 10:30PM Backup scheduled to always run
    I 05/26/16 10:35PM [Default] Starting backup to CrashPlan Central: 496 files (14.90MB) to back up
    I 05/26/16 10:39PM Stopping CrashPlan
    I 05/26/16 10:40PM [Default] Scanning for files stopped
    I 05/26/16 10:40PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 10:41PM [Default] Scanning for files to back up
    I 05/26/16 10:41PM Backup scheduled to always run
    I 05/26/16 10:44PM [Default] Starting backup to CrashPlan Central: 8 files (548.50KB) to back up
    I 05/26/16 10:48PM Stopping CrashPlan
    I 05/26/16 10:48PM [Default] Scanning for files stopped
    I 05/26/16 10:49PM CrashPlan started, version 4.7.0, GUID 696715712192315897
    I 05/26/16 10:49PM [Default] Scanning for files to back up
    I 05/26/16 10:49PM Backup scheduled to always run
    I 05/26/16 10:53PM [Default] Starting backup to CrashPlan Central: 2 files (185KB) to back up

  8. cyprianpl

    I’ve got CP working on a local network, I can also connect from CP UI to CP on Synology from outside my network using public IP; however the backup to that destination is not working, it keeps saying “Waiting for connection”. I’ve opened both CP ports to outside. Any ideas?

  9. nh_ets

    Running a DS414 and installed 4.7. Package starts then stops and does not restart.
    I had no issues on my DS1513+ or a DS214play (both Intel).

    Did a new install of Java. DSM is 6.0-7321 Update 3
    Any ideas on how to keep the package running?

  10. Lloyd

    I was using release 039 without any problems for several weeks, I tried upgrading to release 040 and once I made the switch it started having the “scan halfway through the folder and restart error” I’ve tried all the traditional fixes for this, including increasing memory and reinstalling but it still gives the same defect mode. Enough people have showed the log files for this error that I won’t bloat this message with it.

  11. nh_ets

    Does it start but then stop a few seconds later (and not restart) like I was describing just above?

  12. Mike Baker

    Hi Patters

    I have two Windows 10 PCs that have been backing up to a DS415Play very successfully for some time. With the CP 4.7.0 update on the PCs the connection to the DS stopped so I updated CP on the DS to the same version, which normally gets it working again, but this time it hasn’t. I have reinstalled Java and CP on the DS and CP on the PCs without success. They are all running but there is no connection when on LAN or WAN.

    Any advice would be most welcome!

  13. Ian H

    Oh great … another DSM Update … Version: 6.0.1-7393
    Anyone tried this upgrade yet and can confirm Crashplan 4.70 still works OK? Thanks.

      1. John Pane

        Uninstalling and reinstalling the CrashPlan package got it going for me.

      2. johnpane

        Actually, I may have spoken too soon. It shows as “Running” within DSM but no clients have managed to connect to it yet.

      3. johnpane

        All that is getting logged is starting and stopping of CrashPlan. No client connections or attempts are shown. I have rebooted the DS and un/reinstalled CrashPlan. This is on a DS412+.

  14. Hal Sandick

    upgraded to DSM 6.0.1-7393. Had to uninstall crash plan package and reinstall. needed to issue the command, “echo `cat /var/lib/crashplan/.ui_info`” to get the new authentication token.

    Everything is back working



    1. rdamazio

      Mine stopped working as well. Apparently it has to do with the startup scripts not finding Java anymore. No fix yet, investigating.

      1. patters Post author

        My CrashPlan install was unaffected following the latest DSM update, but I got this exact same problem with my Serviio installation. I couldn’t fix it. It was like the shell that was spawning to run the package had no environment. The root profile and /etc/profile were correctly defining the Java location but these variables were ignored somehow when started from the DSM GUI. I ended up having to reinstall Serviio, which fixed it. It definitely seemed to have been caused by the latest DSM update.

  15. craig1001

    Have just updated my DS415+ to DSM 6.0.1-7393. It had been running CrashPlanPRO 4.7.0-0040 ok since the last DSM update a couple of weeks ago. I’ve reset the GUID in my local desktop (Linux Mint) but of course it won’t connect because CPP won’t start on the NAS. I’ve checked the NAS for upgrade files but there aren’t any in /var/packages/CrashPlanPRO/target/upgrade so I don’t think it’s a 7zip issue.
    Any advice appreciated.

    1. scudmissile

      craig1001: try rebooting your DiskStation. That got the CrashPlan service running again for me after the DSM update, and it looks like it’s worked for others commenting earlier here.

  16. sdmikef

    I seem to be having an issue upgrading the CP PROe client from 4.6.0 to 4.7.0 on a DS713+ running DSM 6.0-7321 Update 7. I don’t see anyone else having this issue and I’m hoping someone could give me a hand.

    When I go to update it, I get A message saying that it failed to update ‘CrashPlan PROe client’.
    there was a problem downloading CrashPlanPROe_4.7.0_Linux.tgz from the official download link.

    This process removes CP 4.6.0, so when the install fails, there is no CP PROe on the machine. I can re-install 4.6.0 by selecting it in the install process, but it, of course, won’t run and notifies me there is an update available.

    Any help would be much appreciated.

    1. patters Post author

      It looks like CP PROe 4.7.0 has not actually been released yet as standalone download. You’ll have to pick 4.6.0 in the installer for now. They really don’t make this easy do they?

      1. sdmikef

        Yes, they do!

        What’s frustrating is that I haven’t been able to backup for a week now.

        Thanks for checking, Patters!

  17. dsd0_Jose

    There is no need to reinstall CP after updating to 6.0.1-7393.
    It’s enough to execute from a shell:

    sudo /var/packages/CrashPlan/scripts/ start

    After that, I can stop and start CP again with no problems from Syno Package Center.

  18. RCH

    I backup 3 PC’s to a folder on my 214 Play. When I first setup crashplan on the server, I changed the default backup location to a folder backups/crashplan. I also have other backup programs going to backups/Windows, etc.

    With this last update on crash plan I noticed that my used disk space was being increased quite a bit. After investigating I found that the back ups are going to a different directory on the server. They are now going to a folder named crashplan/backuparchives. When I first installed crash plan I created a back up directory and then had all my backups going to that directory. Crashplan, windows backup, etc. It appears that this last update change things back to the original default location to place backups. I probably will not change it back in case crashplan changes it again on the next update.
    Just thought I would mention it in case others are seeing their disk space disappearing.

    1. patters Post author

      This is my package’s default location for the friends’ backups, as explained on the main blog post. If I hadn’t defined this location it would by default store them inside the package folder resulting in total loss if the package is upgraded/removed. Not sure why it would have reset though, since the CrashPlan config XML should persist between package versions.

      1. Rui Marinho

        Hey patters,

        The following line on the script is not deterministic. Just before a reboot, the result was:

        find / -maxdepth 2 -path ‘/volume?/@tmp’

        I store my backupArchives under volume1, so if by any chance I had installed the package with this order I would have to re-configure all paths (as I have done once already). The current order after another reboot is:

        find / -maxdepth 2 -path ‘/volume?/@tmp’

        At least volume1 appears first now. Any ideas on how to improve this? Perhaps a package installation option?


  19. nh_ets

    would this solve the problem of trying to start the package from the Package Center, then seeing it start, but the stop itself about 10 seconds later? Tried a reboot, re-install, and new Java. No difference. Help!

    1. bertxl

      Check the comment of dsd0_Jose (June 7, 2016 at 17:22). This did it for me:
      sudo /var/packages/CrashPlan/scripts/ start

  20. rjr

    I tried for hours to get this working again. I can install 4.6 and start it, but I cannot connect to it with the GUI on my desktop.
    I have edited the files multiple times but nothing happens. Gui will not open. Set it back to normal and it opens fine.
    I have 4.7 on my desktop. I found a 4.6 version, after a very long search, and it updates automatically to 4.7. Will 4.7 desktop gui work on 4.6 Synology Crashplan?

  21. nh_ets

    no luck with that. Runs script from SSH but when I look in package center it is stopped. I try to then run from Package Ctr and it runs for about 10 seconds

  22. rdamazio

    Warning: I was running Crashplan using Java 8, and I then realized that some files were never being backed up – it was happily skipping over many files without telling me at all on the UI (it said “backup complete”, but the files were not available to restore – the logs). I talked to Crashplan support, and they suggested I downgraded to java 7 (1.7.0), so I uninstalled Java 8 from the Synology and that did the trick.

    If you *have* been running with Java 8, you may want to search your service.log files for exceptions like this:

    [06.03.16 00:58:33.006 WARN BQTodoWkr-42] BQ:: Exception:$DeltaBlockOutputStreamException: WRITE: ArrayIndexOutOfBoundsException: (…)
    Caused by:$DeltaBlockOutputStreamException: WRITE: ArrayIndexOutOfBoundsException: (…)
    at com.code42.backup.handler.BackupHandler.streamFile(
    at com.code42.backup.handler.BackupHandler.saveFile(
    at com.code42.backup.handler.BackupHandler.executeSave(
    … 4 more
    Caused by: java.lang.ArrayIndexOutOfBoundsException

    (Where I put “(…)” will be a data about the skipped file)

    1. patters Post author

      Enhancement idea – optional configuration to use Java 7 Embedded JRE regardless of system JRE. Similar to Java package, the user will need to download the appropriate JRE bundle from Oracle and put it in the public folder on the NAS. A UI wizard during the package install will determine whether or not this is used. install.vars gets amended to use local Java 7 JRE.

  23. caracturus

    First of all thanks for all your help guiding us with making the CrashPlan app work.

    – I noticed on June 9 2016 that CrashPlan had stopped on the Synology (running the latest DSM 6.0.1-7393). Crashplan was version 4.7.
    – After a few messing around, I uninstalled and reinstalled your latest package and the app started working fine.
    – I made sure that the ui_info ui_properties reflected the necessary keys, ports and server addresses. Unfortunately, the Windows app does not find the server and just times out.
    – The version of Crashplan is 4.7.0 – 1435813200470 (2015-07-02T05:00:00:470+0000) – Build: 317.
    – According to the app log on the server :

    671279843063103752, DiskStation, SELF, private=, connectedFor=0ms

    – This surprised me as it shows port 4242 and not 4243.
    – The cat /var/lib/crashplan/.ui_info ; echo shows that it is 4243.

    – I tried changing the Windows application files from port 4243 to port 4242 and that made no difference either.

    Any suggestions?


  24. B. Goodman

    Patters, thanks for keeping the ever-changing CrashPlan working on our Synology NASes! Tossing you a few Pounds to say thanks. I’m posting it here to encourage some of the others.

  25. QHel0

    DSM 6.0.1-7393 and Crashplan version 4.7
    engine_error.log says:
    /var/packages/CrashPlan/scripts/ line 171: /bin/java: No such file or directory
    causing CP not to start.
    install.vars has JAVACOMMON=${JAVA_HOME}/bin/java but seems to be ignored..

    1. patters Post author

      I think the last DSM update broke the way that some packages’ shells are invoked. It will be cured with a package reinstall. To do this without having to re-sync your entire backup set I think you can edit /var/packages/CrashPlan/INFO and lower the package version number in that file. Then open Package Center and it will offer you an upgrade to the latest version, which will migrate your settings.

      1. airplanedude

        thanks for all the work. Incredibly appreciated.

        I tried as you described (changed to 4.6). Ran the update. Stopped the application through the GUI. Restarted the application through the GUI.

        Same as before: Desktop app cannot make contact with the Crashplan app on the Sinology NAS 1513+ (Latest FW).

  26. Harley

    Patters – thanks. The file version changed did the trick to reload and then restarting worked to get CrashPlan back on the Synology DS1515+

    1. Stingr

      This worked for me as well.

      Thanks as always, Patters for keeping Crashplan running on our Synologys. I just sent a few pounds your way as a thank you for all the great work you do.

  27. Per

    Five days ago, DSM on my NAS auto-updated and my CrashPlan would no longer run. After reading about it on some places, eg here, I decided to reinstall CrashPlan. I uninstalled it, but when I was about to reinstall it, I noticed that none of the PCLoadLetter packages were available to install. No CrashPlan, no Serviio, no MineCraft or any other package from So now I’m left without any CrashPlan at all, running or not. Any help would be much appreciated.

    My NAS is a Synology DS1513+ running the latest public version of DSM.

    1. patters Post author

      Is that still the case? While running DSM 5.x your system’s identifier was either cedarview or x86, but DSM has been compiled as a 64bit native OS now so maybe they changed the name.
      Can you run uname -a and paste the result so I can fix this.

  28. airplanedude

    Alright. I think I found the issue with my hiccup. (see two above)
    I noticed upon echo `cat /var/lib/crashplan/.ui_info` that
    4271,/—–whatever token text———/,
    was returned.
    That was despite restarting, despite forcing the re-run of the install script as Patters had described.
    At first I didn’t notice, but then looked at the fist four digits and found that they do not read 4243.
    Running the config scripts did not seem to have an impact. (It may well be that I did not do something correctly, although I like to think that I followed the instructions well enough.)

    Not knowing any better, I uninstalled and reinstalled CP on the NAS.

    Now all works.

    Hope this helps someone else in my situation.

    Again, thanks Patters.

  29. polarys

    I highly recommend anyone using Java SE 8 to _immediately_ downgrade to Java SE 7. I was on Java 8 and it was “backing up” (and even Crashplan server thought it was backing up) – however it was missing a LOT of files. (I had to check after reading comments a bit earlier in this thread about backups not working on Java SE 8). Not only that, but my log files did not have the exceptions in them that others have seen (ArrayIndexOutOfBoundsException), so it wasn’t even obvious from looking at the log files that it was failing.

    Only by going to the “restore files” UI in Crashplan web could I see that my recent files weren’t actually being backed up. Now that I’ve downgraded to Java SE 7, I had to change my backup set slightly for force a re-scan, and it’s now backing up 10GB of data that wasn’t previously backed up.

  30. Mike

    I got tired of manually switching files ( & .ui_info) on my Windows PC to access the CrashPlan UI for my PC and CrashPlan UI for the NAS so I wrote this .bat file. I’m passing along in case it’s useful to others.

    Some notes:
    1) It requires a .ORG and .DISKSTATION version of each of the two ui files in their respective directories that hold the right config strings for starting the respective UIs. This .bat file just swaps those files.
    2) Be sure the CrashPlan UI isn’t already running
    3) Be sure to run the .bat file as administrator

    @echo off
    REM change the current working directory to where the batch script is located
    cd /d %~dp0

    if exist CurrNAS.txt (
    call :PC
    goto :EOF
    if exist CurrPC.txt (
    call :NAS
    goto :EOF
    if not exist *Curr*.txt (
    call :NAS
    goto :EOF
    goto :EOF

    REM subroutines only below this point:
    REM switch to PC UI
    echo Switching to PC UI
    copy “C:\Program Files\CrashPlan\conf\” “C:\Program Files\CrashPlan\conf\”
    copy “C:\ProgramData\CrashPlan\.ui_info.ORG” “C:\ProgramData\CrashPlan\.ui_info”
    echo “Currently PC UI” > CurrPC.txt
    del CurrNAS.txt
    start “” “C:\Program Files\CrashPlan\CrashPlanDesktop.exe”
    REM pause
    goto :EOF

    REM switch to DISKSTATION UI
    echo Switching to DISKSTATION (NAS) UI
    copy “C:\Program Files\CrashPlan\conf\” “C:\Program Files\CrashPlan\conf\”
    copy “C:\ProgramData\CrashPlan\.ui_info.DISKSTATION” “C:\ProgramData\CrashPlan\.ui_info”
    echo “Currently NAS UI” > CurrNAS.txt
    del CurrPC.txt
    start “” “C:\Program Files\CrashPlan\CrashPlanDesktop.exe”
    REM pause
    goto :EOF

  31. nh_ets

    I still have an issue with CP stopping shortly after I start it on a DS414 (ARM). Maybe it is still running? It does say stopped in Package Center.
    Should I be using Java 7 instead of Java 8?

  32. XJS Tamas (@XJS_Tamas)

    Just figured out, that my (automatically assigned) 4279 port has been changed (automatically) to 4329, therefore haven’t been able to connect the gui. Is there any idea what is causing random port changes?
    Also, the engine sporadically stops recognizing backup sets, and reporting back zero MB backups in the daily emails….

    1. ajwillmer

      I am also finding the daily emails seem to have poor reporting. The app and online agree but the emails underreport files/size backed up

  33. Mike Stop Continues

    I just got a DS216play running v6.0.1, and no pcloadletter packages are showing up after adding the repo, enabling any source, and refreshing. Anyone else having the issue? Any idea how to fix it? Thanks!

  34. sdmikef

    So, now it would seem that CP PROe 4.6.0 is also unavailable. I’ve been futzing with this and thought I’d try another 4.6.0 re-install, but I get the same error message as before, only with 4.6.0’s path listed. 4.5.2 still installs, though I doubt it will work.

  35. Mike

    All of a sudden when I start the Crashplan service, it just sits there saying “running.” I’ve tried uninstalling and reinstalling both the Crashplan package and Java 7 from Synology. Nothing else has changed and it doesn’t look like an upgrade failure. The log just says CrashplanPRO started, version 4.7.0 then nothing else. Any ideas?

      1. mgittelman

        Through some combination of uninstalling the crashplan and java packages and reinstalling it’s now working again. The only other thing I did was the cpio copy which I’d never done before. I don’t know if that would have made any difference though.

  36. BarefootInMA

    Our organization uses CrashplanPROe and we just got a new Synology RS815+. I’m having a hell of a time getting Crashplan working on it. I installed Java 7, per the comments, and the CrashPlan PROe Client. Since 4.7.0 and 4.6.0 won’t download anymore (also outlined in the comments) I went with 4.5.2 and made sure my client was running the same version. I could log in at first but it quit pretty quickly and then the PROe Client was stopped on the server. I used cmd `sudo /var/packages/CrashPlanPROe/scripts/ start` which believed it started it but it stayed stopped on the Synology. I can uninstall and reinstall, but the process stops pretty quickly after installation. I tried downgrading to 4.5.0, same issue. I also did reboot the box but that didn’t help either. Any ideas on how to get this stable?

    1. patters Post author

      Since they moved to 4.7.0 build 344 the regular download link seems to work again. Maybe it was a hosting error on their side. Is it all ok for you now?

  37. Brian

    I’m running the latest packages of CP on DSM 6.0.1-7393 Update 1. Lately i’ve noticed that inbound backups to the Diskstation keep disconnecting. Both sides simply say the reason for stopping is the backup destination disconnected. This happens every 10-30 minutes while a backup is running. Is anyone else seeing this? The CP service isn’t restarting so I’m wondering if there’s some TCP timeout that’s dropping the connection. If I notice the disconnect has happened and go force a retry, it usually connects up right away.

  38. mgittelman

    Looks like a new version is out. It says it installed upgrade version 1435813200470 but then the service stops. Can’t get it to start again. Anyone else getting this yet? Looks like the upgrade installs successfully – not getting the “repaired in” issue from earlier. Tried switching to Synology Java 7 and Java 8.

    I did just notice the file /var/packages/CrashPlan/target/syno_package.vars no longer exists after the upgrade. Did something get overwritten/corrupted with the new install?


      @mgittelman: I modified this to try to get it working:

      Here are some relevant commands from my history:

      343 cd /var/packages/CrashPlan/target
      376 mv upgrade.cpi upgrade.cpi.gz
      377 gunzip upgrade.cpi.gz
      387 mkdir temp
      388 cd temp
      389 ../bin/cpio -i < ../upgrade.cpi
      392 mv lib ..
      400 mv lang/ ..

      After the above, I used the Package Manager controls in the Synology Web-based GUI to start the package.

      I'm getting this in service.log:

      [07.11.16 15:29:12.490 ERROR main com.backup42.service.CPService] Error starting up, java.lang.UnsatisfiedLinkError: no jtux in java.library.path


    2. Jon Etkins

      I noticed the exact same behavior – new version appeared to successfully upgrade, but then the service would no longer start and didn’t even appear to be touching its log files.

      Poking around, I found /var/packages/CrashPlan/target/bin/CrashPlanEngine which appears to be the start/stop/status script for CP. I guess this is a change from previous versions – running “/var/packages/CrashPlan/target/bin/CrashPlanEngine start” successfully starts CP, though Package Center in DSM still shows its status as Stopped.

      And as mgittleman reported, syno_package.vars is no longer anywhere to be found, so IDK how to increase the Java heap any more except via the GUI.

      1. Luca

        I tried, but I have: /volume1/@appstore/CrashPlan/jre/bin/java: /volume1/@appstore/CrashPlan/jre/bin/java: cannot execute binary file
        Cannot understand why.

      2. Luca

        Ok, I moved Java in install.vars and now it starts… then I have the very same error: Error starting up, java.lang.UnsatisfiedLinkError: no jtux in java.library.path

  39. Troy

    The issue appears to be in the log file stating:

    Could not find JAR file /volume1/@appstore/CrashPlan/bin/../lib/com.backup42.desktop.jar

    1. Martin Hallerdal

      I also encountered this. I don’t know why, but it seems as if the upgrade process wiped the lib directory. There may be other solutions to this but my solution was to re-install the crashplan package. But then I encountered two more problems 1) JAVACOMMON was changed in install.vars, easily fixed 2) An UnsatisfiedLinkError in service.log.0 when loading My guess is that the upgrade process replaced this library with a ARM incompatible version. After re-installing the package (again) I copied this library to another location and after the upgrade I copied it back again.

  40. troy

    I used this to extract the files but the ‘could not find JAR’ file error above is the remaining issue preventing the service from starting up.

    sudo 7z e -y /var/packages/CrashPlan/target/upgrade/1435813200470_344.jar “*.jar” -o/var/packages/CrashPlan/target/lib/
    sudo 7z e -y /var/packages/CrashPlan/target/upgrade/1435813200470_344.jar “lang/*” -o/var/packages/CrashPlan/target/lib/

  41. Martin Hallerdal

    I had a problem today with update 1435813200470. It seems like this update overwrote my (located in the CrashPlan directory) with a non-ARM compatible version causing a UnsatisfiedLinkError exception visible in the service.log.0 file. My work-around was to re-install the crashplan package, copy the file to /tmp, and then when the upgrade had overwritten this file I copied it back. Also, the upgrade process downloaded a non-ARM compatible JRE and changed JAVACOMMON in install.vars so that had to be changed as well.

  42. Jay

    Ok. I have just installed CrashPlan about a month ago and being at 90% complete on my initial back up of 2.5TB I thought I was going a bit crazy as to why this happened. It’s been a long road to even get the thing installed for someone who hasn’t touched unix/linux for 20 years. If and when a solution is found, if someone is willing to outline the fix in fairly easy to understand steps I would be vary appreciative. Thanks all.

  43. Sebalux

    I managed to get it running again after doing what above described.

    Nevertheless, as other mentioned it too, the syno_package.vars disappeared.
    All my other attempts to change the memory from 1024m to another value failed so far.
    The entry in my.service.xml is getting ignored. Same happens via the GUI java mx command. It always defaults back to 1024m. The engine_output.log always states:
    Checking Java memory heap max.
    Previous Java memory max heap size was 1024

    Might they have included an auto detect to adjust memory based on system available memory?

  44. Wayne

    Hello All…

    I have (it seems) managed to get it working.

    Version: 4.7.0 – 1435813200470 (2015-07-02T05:00:00:470+0000) – Build: 344

    1: Delete the crashplan package.
    2: SSH in and delete /var/lib/crashplan
    3: Reinstall Crashplan
    4: Replace the jna.jar file as described in previous posts.
    5: Start Crashplan

    Oddly, I set the JAVA path absolutely in the install.vars file, but looking at it now, it has reverted to standard. Maybe I did not save it…. No idea…..


    At this point, it seems to be working. I can log in via the client from a windows PC just fine.

    BUT… It is now set up as a new PC. I have not adopted a previous GUID. And for me, that’s OK.

    Good Luck…!!!

    1. Troy

      Can you be m ore explicit about “replace the jna.jar file as described in previous posts”. There are too many previous posts to know exactly what you used. Can you also post exactly what you used in the install.vars file that’s actually working

      1. Wayne


        Sure can..!!

        0. Stop CrashPlan on Synology
        1. Download the latest jna from:
        2. Upload the jna-4.2.2.jar to Synology
        3. SSH into the synology as admin user
        4. Rename (or delete) the jna. that ships with CrashPlan “mv /var/packages/CrashPlan/target/bin/jna.jar /var/packages/CrashPlan/target/bin/jna.ja_”
        5. Move the downloaded jna-4.2.2.jar to the CrashPlan folder and rename it to jna.jar
        6. Start CrashPlan on Synology

        Bear in mind I also deleted the folder /var/crashplan which holds the .ui_info file. So in my case, it became a clean install, with a new GUID. And has I did not have much data, that was not an issue.

        As mentioned, I also set the path to Java8 in the install.vars file, but on restart that file reverted to the original. Nonetheless, it all is still working.


      2. Troy

        Thanks for your instructions. I did as you stated but it did not work. It tries to start and fails. In the log file upgrade.1435813200470_344.1468266697953.log it shows the following:

        Java Installed.
        Unpacking remaining upgrade files
        currentDir=/volume1/@appstore/CrashPlan/upgrade/1435813200470_344.1468266697953 line 214: cpio: command not found
        Removing existing app files…
        Adding updated files…
        32 bit version detected, using 32 bit electron.
        Replacing CrashPlanEngine
        ‘scripts/CrashPlanEngine’ -> ‘../../bin/CrashPlanEngine’
        Replacing run.conf
        ‘scripts/run.conf’ -> ‘../../bin/run.conf’
        Replacing root app launcher file…
        Replacing /usr/share/applications/crashplan.desktop with scripts/CrashPlan.desktop AS /usr/share/applications/crashplan.desktop…
        ‘scripts/CrashPlan.desktop’ -> ‘/usr/share/applications/crashplan.desktop’
        cp: cannot create regular file ‘/usr/share/applications/crashplan.desktop’: No such file or directory
        Finished removing user launcher files…
        Restarting Service
        Could not find JAR file /volume1/@appstore/CrashPlan/bin/../lib/com.backup42.desktop.jar
        Service Restart Complete

      3. Wayne


        Sorry, I did leave out one step. I completely uninstalled Crashplan and (as I mentioned) also deleted the folder /var/crashplan which holds the .ui_info file.

        Then I installed Crashplan, moved the jna.jar into place as discussed and altered the install.vars to point directly to the Java install.

        You will need to start and stop Crashplan a couple of times, so it can setup a new .ui_info file.

    2. OleDK

      Wayne, I followed your instructions and it seems to work. It’s syncronizing block information now and that usually takes a few hours.

      Thanks a lot.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s