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.

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:
    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:
    Community-packages
    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:
    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.

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

  1. Sasha's avatarSasha

    Current configuration DS1512+ 5.2-5592 Update 4.
    Crashplan on NAS: 4.3.0-0033
    Crashplan on Win7: 4.3.0
    Until a few days ago, everything was OK.
    Client can’t connect anymore.
    I reinstalled the NAS version, but same.
    I tried to match the key from NAS, but /var/lib/Crashplan directory is empty, no .ui_info file.
    I am stuck here.
    Anyone know why i can’t find the above file?!

    Reply
  2. Sasha's avatarSasha

    WinSCP client didn’t see the hidden file .ui_info on the NAS. With CAT command, I managed finally to get the token key. I copied it (with 0.0.0.0 at the end) to the same file on PC and now all is back to normal.

    Reply
  3. ethan's avatarethan

    so does this apply to this statement:
    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.

    Removing the CLENT is not enough? I need to uninstall and reinstall on teh synology as well?
    The the order is
    start and stop on syno
    then run the client?

    Reply
  4. acn's avataracn

    I’m having issues with the .ui_info token stuff. Basically CrashPlan is randomly resetting the token and I can’t understand if there is anything triggering this. This happens both in the background and while the UI is active (the Mac app closes).

    I ended up understanding that this was the token after checking the logs, where references to mismatch token are appearing.

    Log excerpt:
    http://pastebin.com/nkLsVfJa

    I’ve uninstalled CrashPlan before on my Mac and also done that 4.3.0 upgrade fix, but it keeps happening. I can temporarily access the Synology if I’m fast enough changing the token, but eventually it will reset it.

    Does anyone have any idea what’s going on?

    Reply
  5. OjaSapNL's avatarOjaSapNL

    Hi All,

    Since yesterday Crashplan released version 4.4.0 it has stopped working at my Synology. Already tried a reinstalled but still same error. Is there someone who already fixed the problem?

    Error message:

    I 09/22/15 07:56AM CrashPlan started, version 4.3.0, GUID xxxxxxxxxx
    I 09/22/15 07:56AM Upgrades available at central.crashplan.com:443
    I 09/22/15 07:56AM Downloading a new version of CrashPlan.
    I 09/22/15 07:56AM Download of upgrade complete – version 1435726800440.
    I 09/22/15 07:56AM Installing upgrade – version 1435726800440
    I 09/22/15 07:56AM Upgrade failed – version 1435726800440
    I 09/22/15 09:58AM Stopping CrashPlan

    Reply
  6. Dmitriy's avatarDmitriy

    This package is getting unusable… what a shame…
    Again the upgrade for 1435726800440 has failed, manual steps make no difference, the security token keeps changing… Crash Plan package keep stopping. Tried reloading it – same results…

    Reply
  7. ties's avatarties

    Anyone seeing issues in their logs with Crashplan pushing out an upgrade to version 1435726800440 and that update failing? It looks like the old version is still uploading… for now…

    Reply
    1. Fabien's avatarFabien

      Hello,
      I have also problems with Crashplan on my DS415+.
      I followed the following procedure :
      1. Reinstall Windows client and apply modifications on ui.properties file
      2. Reinstall Crashplan package on my Synology and launch it.
      Log shows at the end : Upgrade failed – 1435726800440
      3. unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
      4. unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “lang/*” -d /var/packages/CrashPlan/target/
      5. mv /var/packages/CrashPlan/target/upgrade/1435726800440.XXXXXXXXXXXX/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435726800440.XXXXXXXXXXX/upgrade.sh.old
      6. I can launch my Windows client but I have the following error : crashplan has been disconnected from the backup engine !

      Could someone helps me ???

      Many thanks.

      Fabien

      Reply
      1. Fabien's avatarFabien

        I have resinstalled another time Crashplan package on my Synology and everything seems to be fine now…
        Fabien

  8. john's avatarjohn

    I noticed Crashplan had stopped tonight so I attempted to start it. Each time I attempt to start Crashplan I get the following error: “09/22/15 10:03PM Synology repairing upgrade in”
    It doesn’t specify a path in the error. Any ideas?

    Reply
  9. Stephen Cranfill's avatarStephen Cranfill

    Yes–I ran into this yesterday and, whereas the process outlined here:

    http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/

    …has worked for the past two updates, I’m not having any luck with this new one. (To be clear, Chris’s instructions still work when putting in the new ID of 1435726800440, but the logs don’t indicate Crashplan is running afterwards.) The GUI in Synology shows it’s running, but the Crashplan app can’t connect to it and it shows offline at crashplanpro.com.

    I’ve just tried to uninstall Crashplan from the Synology again and this time *not* attempt to fix the failing upgrade. It’s currently showing as online at Crashplanpro.com, but I’m not hopefully. The selection size appears far too small. I suspect I would need to adopt my old archive (if I could get Crahsplan GUI to connect).

    Reply
  10. nico's avatarnico

    Looks like after the 00440 update issue, mine has completely stopped working. attempted removing and reinstalling, and now i get the cannot connect to engine error. Have done the ui_info stuff but no joy. The service appears to be running, but now due to me reinstalling it, i dont think it’s configured, so it wont even backup anything now. Any ideas anyone?

    Reply
  11. Singularity's avatarSingularity

    Yeah, it sure seems like the latest update 1435726800440 has really screwed us connecting client wise to our headless NAS. My backups are going fine, I just can’t connect via my Mac client to see what’s going on.

    I’ve updated the .ui_info file with the correct ID, used the IP of my NAS at the end, used all 0’s nothing seem to work right, I always get the disconnect message..

    I wonder if Code42 put in some extra security measures to spice things up a bit?
    DANG!

    Reply
  12. Alan's avatarAlan

    I recently upgrade java to 1.7.0_80, not sure this has anything to do with it but Crashplan on my 212play is giving and Upgrade failed error -version 1435726800440.

    Any ideas?
    Thanks.

    Reply
      1. marselaar's avatarmarselaar

        That does not seem to work this time. :-(
        Strange thing is I have a 1435726800441.jar , but after unzipping I seem to have 2 update directories:
        drwxr-xr-x 4 root root 4096 Sep 26 09:37 1435726800440.1443252204854
        drwxr-xr-x 4 root root 4096 Sep 26 09:37 1435726800440.1443252396146

        The log on Synology says it has downloaded two updates 1435726800440 and 1435726800441. But it does not seem to install them correctly, since when I try to start after the instructions from chris nelson it will still repair the upgrade.

        Remember the days Crashplan Syno package was easy…. :-(

  13. stevenschon's avatarstevenschon

    Help!

    Crashplan 4.3 seems to be running on my DS414, however, when I look at the logs, it stops and then restarts every 3 minutes. Also, when I launch Crashplan on my remote machine (looking at the IP address of the DS414, it looks like its starting the backup, does the analyzing file or synching blocks, and then the crashplan GUI spontaneously closes, before I can see if anything is actually being backup to the Crashplan servers. Restarting the Crashplan on the remote just repeats the same thing.

    Anything I can do to get Crashplan to run continuously on the DS414 without the stop and restart every 3 minutes?

    Reply
  14. Kevin's avatarKevin

    The update directions get the package running again. However, when trying to connect using the client, you now get an error that says “CrashPlan has been disconnected from the backup engine”. I’m not sure what is causing this, but something has definitely changed. I have never had this issue before.

    Reply
    1. Stanthewizzard's avatarStanthewizzard

      Same issue here
      I’m not sure but apparently there is 2 listening port 4242 and 4243
      Impossible to connect anymore

      Reply
    2. Jan's avatarJan

      I have the same issue – can’t connect (with the error message above) despite following all the instructions including the UUID. Any ideas on how to get my backup running again?

      Reply
  15. Mike's avatarMike

    I’m seeing similar issues. I filled the instructions to fix which have worked for previous builds and this build appears to be running according to Package Center but I notice nothing is written to the log which seems wrong! I get the same client error that others are seeing in terms of ‘disconnected from backup engine’.

    Reply
  16. Robbert Marrink's avatarRobbert Marrink

    Crashplan doesn’t start anymore after a reboot of my DS. Unable to update the client on DS through the mentioned method. Unable to connect to the client from my Mac. Basically I’m without off-site backup now and that worries me. Usually there is a quick response on this site from Patters with a fix. I don’t see a reply from him now, so I hope he has can find the time to come up with a fix. I do appreciate his support very much!

    Reply
    1. missionmania's avatarmissionmania

      If it makes you feel better you’re not alone. My DS does not have a working crash plan installation and I can’t workout how to roll back to a previous version. Hoping we see a solution soon.

      Reply
  17. Chuck's avatarChuck

    Power went out the other day, the Synology came back and is working fine but the CrashPlan log says “Synology repairing upgrade in” and it crashes or doesn’t even start. Any suggestions how to fix it?

    Reply
  18. Yves Soers's avatarYves Soers

    Same here, I have Crashplan on 2 different NAS. In the log of my NAS at work Crashplan is still running but is trying to install the upgrade every 30 minutes. Upgrade always fails.

    On my NAS at home I had a broken HDD, so needed to put a new one in. And on this NAS crashplan does not start anymore (probably because of shut down en reboot)

    Seems to me packages needs to be updated :-(
    Old fixes don’t work.

    Reply
  19. tiennemannes's avatartiennemannes

    This is what i get after also copying the service.log.xml:

    cp /var/packages/CrashPlan/target/upgrade/1435726800441.1443273296129/service.log.xml /var/packages/CrashPlan/target/conf/

    and changing the logging level to DEBUG, and then trying to connect to the headless from my computer:
    http://pastebin.com/XAALrceE

    Reply
  20. Martin's avatarMartin

    /volume1/@appstore/CrashPlan/conf/my.service.xml
    ” ”
    ” instead of 0.0.0.0 ”
    ” 4243 ”
    That did the trick to connect for me.

    Here the same problem that crashplan won’t start anymore and fails to upgrade.

    Reply
  21. Josh's avatarJosh

    I think I’ve gotten through the upgrades okay, but as soon as I connect the client to the engine and login with my password, I get the following in the engine_output.log. Anyone else seen this? I’ve tried with both the java7 and java8 packages and get the same result.

    [09.27.15 19:26:28.551 INFO 25955_AUTH-1 42.backup.path.BackupSetsManager] BSM:: Initializing scheduled file queue watcher driver.
    #
    # A fatal error has been detected by the Java Runtime Environment:
    #
    # SIGILL (0x4) at pc=0x4aaf2744, pid=1453, tid=1247278192
    #
    # JRE version: Java(TM) SE Embedded Runtime Environment (8.0_51-b07) (build 1.8.0_51-b07)
    # Java VM: Java HotSpot(TM) Embedded Client VM (25.51-b07 mixed mode linux-arm )
    # Problematic frame:
    # C [jna6727043308918060404.tmp+0x12744] ffi_prep_cif_machdep+0x16c
    #
    # Core dump written. Default location: /volume1/@appstore/CrashPlan/core or core.1453
    #
    # An error report file with more information is saved as:
    # /volume1/@appstore/CrashPlan/hs_err_pid1453.log
    #
    # If you would like to submit a bug report, please visit:
    # http://bugreport.java.com/bugreport/crash.jsp
    # The crash happened outside the Java Virtual Machine in native code.
    # See problematic frame for where to report the bug.

    Reply
  22. Wayne's avatarWayne

    So…it’s been over a week and sounds like we are no closer to a solution. I think the time has come to open a dialog with Code42 and either:
    1) Get it supported under a list of the popular NAS’s
    2) Have Code42 release both the headless and PC client versions at the same time…while keeping in mind that they need to be able to work in a headless environment.

    This current cycle of getting broken every month has to stop. Has anyone tried to work with Code42 on something like this? Are they approachable?

    Reply
  23. jimmah!'s avatarj1mmah

    I’m not seeing any packages any more on my DS409, has the platform/processor been put on an unsupported list? I uninstalled the CrashPlan client with the intention of reinstalling cleanly and can no longer find it.

    Reply
    1. patters's avatarpatters Post author

      It was getting too complex to script around all the various differences between systems so I had to baseline on DSM 5.0 when I released 3.6.3 I think, and that excluded units that were older than 2010. Sorry about that.

      Reply
  24. Wade's avatarWade

    This is getting to be a very annoying pattern, to the point that I’m thinking about just switching to one of the synology supported packages and paying more for a backup service. While I appreciate the work patters has done to keep this package running thus far, I really can’t trust my backup/recovery strategy to something with such a critical dependency and continual point of failure. I’ve been without offsite backups for almost a week now, and we still haven’t heard from patters. Every time this happens I wonder “Is this the one?”

    Reply
    1. wraczlavski's avatarjirikafka

      I am totally hearing you. I am not prolonging my CrashPlan subscription, and will go for Amazon S3. My business can´t stand on such a shabby service. I don´t blame Patters, its just unpaid hobby project for him. I guess I just expected it to be a more stable solution.

      Reply
    2. Rich's avatarRich

      What other options are there? As a alternate I installed cloud sync to amazon for my mission critical folder. I figured in a total disaster I can get that up and running 10 minutes after I bring the nas online. However the cloud sync went crazy and at one point it thought an old copy on the amazon server was newer then the nas copy and it ‘restored’ a microsoft access database that was 3 hours old.

      I am willing to pay but of course I want to keep is reasonable. Right now i only have 300 GBs on the nas and would likely stay under 500 GB for some time.

      Anyone use anything that they like as much as crash plan?

      Reply
      1. Kevin's avatarKevin

        Along with Crashplan, I also use iDrive. Their price is reasonable and the best part is it is actually supported by them. Very easy to use.

      2. wraczlavski's avatarjirikafka

        I am giving iDrive a spin right now and so far it seems to work quite well. How long have you been with them and how was your experience?

      3. Kevin's avatarKevin

        I am on my second year. The few issues that I have had were bugs that were fixed with their 2nd level support. 1st level support isn’t that good. Second level is excellent !

      4. wraczlavski's avatarjirikafka

        Am I missing something, or iDrive on synology doesnt do file versioning? Thats a no no for me, sadly.

      5. wraczlavski's avatarjirikafka

        Care to elaborate? I am currently testing free version, but I dont see option to restore different version of the file.

      6. Jeff's avatarJeff

        Why not just mount your NAS partitions on a system that is supported by CrashPlan, and backup from there?

      7. Jeff's avatarJeff

        I’ve been asked several times on how I backup my Synology NAS to Crashplan with absolutely ZERO client issues on the Nas. It’s easy. Don’t run Crashplan on the NAS. I run it on my Mac, and my Mac mounts my NAS partitions and backs them up.

        No muss, no fuss.

        I’ve created a little how-to at http://k9town.com/crashplan/how-to-backup-nas-from-mac.html
        It’s based on Mac users, but you should be able to do the same sort of thing from Windows.

        -Jeff

  25. Dmitriy's avatarDmitriy

    Can’t blame patters! After-all we haven’t paid a penny/cent for this and have had plenty of benefit! I’m too looking for alternative ways but hey! :)

    Reply
  26. Ron's avatarRon

    Every so often, I will send an email to support and/or feature requests – to both CP & Syno to make a supported app. I love the setup, but when we roll this out to our 50+ clients – we get hit when CP updates then our backups all stop. I sent the email to both the other day…maybe that will be the one that makes it to the approval table.

    Reply
  27. Per's avatarPer

    Hi,
    Keep in mind that Crashplan is one of the only ones that have Secure Key management, ie you control the encryption keys (so that you can your data secure and not being shared with the backup vendor).

    BTW, the fixes outlined both here and on http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/ works every time for me. The only annoyance I have is that the Windows client can’t connect. According to Crashplan support they should be releasing the new client “soon”.

    At least my backups are still sync’ed up to Crashplans servers, which is what I primarely need.

    Reply
    1. wraczlavski's avatarjirikafka

      That doesn´t work for me anymore, my CrashPlan seems to be running, but it is synced. Anyway, I have better things to do with my time than hack paid service to work.

      Reply
      1. Per's avatarPer

        Yep, I’m quite irritated that Crashplan doesn’t do a proper Synology package that they support. But for me I’ll stick with Crashplan until I can find a provider that let me control the encryption keys and have a configurable file versioning.

    2. marselaar's avatarmarselaar

      That doesn’t work for me either, because there are now 2 update packages waiting. And since the Windows client is needed for restoring….. It might be solved any time soon, but these manual interventions keep happening and they seem to occur more often.

      Reply
      1. Per's avatarPer

        You could try to use the web for restoring. That has helped me when I’ve had issues with my Synology.

    3. Wade's avatarWade

      It wouldn’t be so bad if they gave me the option to opt out of updates, which are what cause all these issues in the first place. I want a service that I can just set and forget, and the crashplan alerts don’t seem to start filling my inbox until it’s already been a few days without any backups. After years of dealing with this, and expecting it to get better while it seems to constantly go the other direction, I think I’m just finally getting fed up and am ready to pay for some convenience. Now it’s just a matter of figuring out who to pay.

      Reply
      1. Per's avatarPer

        Right, I do agree that there should be a choice to opt-out or at least a configurable delay before they force the updates.

        In regards to status alerts through email, I’ve setup my CP so that I get a warning after 1 day without backups.

    4. hermlam's avatarhermlam

      I completely de-installed and re-installed crashplan and now 2 updates are waiting, same as Marselaar. How to solve this with the chrisnelson option?

      Reply
    5. tuxerr's avatartuxerr

      One have the option to control the encryption key with idrive. Just signed up for the free 5gb account. It toke me less then 5 minutes to get it up and running with my DS212j. One of the first questions you get is if you want to use idrives encryption key or your own. So for the needs I have the case is closed I will go with idrdrive.

      Reply
  28. Peter Allen's avatarPeter Allen

    Hi,
    It’s a shame that Code 42 does not support Synology NASs as a matter of course but I suspect that their business model would not work for single machines with large storage requirements. I am sure Patters works hard on this project but his input could never be more than “best endeavours”, which is why we have several gaps in service – and hence a reliability problem – as we are just not paying enough for the service. I used iDrive with my Windows Home Server and the backup regime was faultless. At that time, iDrive told me that they were working on a NAS-based solution for the future. I hope the current NAS-based solution is as good as their former Windows Home Server offering used to be. In the meantime, Patters – keep up the good work!

    Reply
  29. wraczlavski's avatarjirikafka

    Ok, guys and gals, I´ve switched to iDrive just now.

    Synology app works as expected, speed is better (10/10 Mbps), desktop client looks like it was created in this millenium, and as a bonus, I don´t have to fuck around with linux commands longer than my family tree.

    For $15 you can get 1 TB / year (it dropped from $40 after using it for free 1 day), so why not check it out.

    Thank you Patters for all your time you´ve dedicated to this.

    Reply
  30. Yves Soers's avatarYves Soers

    I managed to get it back running on my NAS.

    I did the following instructions:

    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “lang/*” -d /var/packages/CrashPlan/target/

    mv /var/packages/CrashPlan/target/upgrade/1435726800440.whatevervalue/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435726800440.whatevervalue/upgrade.sh.old

    –> NOTE THERE ARE SEVERAL DIRECTORY’S, YOU HAVE TO RUN THIS COMMAND FOR EVERY DIRECTORY !!!!!

    I started the packages again and upgrade tot 4.4.1

    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “lang/*” -d /var/packages/CrashPlan/target/

    mv /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/upgrade.sh.old

    mv /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/service.log.xml /var/packages/CrashPlan/target/conf/service.log.xml

    This extra command will fill the log again. Otherwise you can’t see Crashplan starting in the log on your NAS.

    I’m not able to connect my client to the NAS, so something is still broken. But at least, files are backing up again :-)

    Reply
  31. Yves Soers's avatarYves Soers

    Please delete previous post, I made some typos.

    These is the corrected post:

    I managed to get it back running on my NAS.

    I did the following instructions:

    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar “lang/*” -d /var/packages/CrashPlan/target/

    mv /var/packages/CrashPlan/target/upgrade/1435726800440.whatevervalue/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435726800440.whatevervalue/upgrade.sh.old

    –> NOTE THERE ARE SEVERAL DIRECTORY’S, YOU HAVE TO RUN THIS COMMAND FOR EVERY DIRECTORY !!!!!

    I started the packages again and upgrade to 4.4.1

    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800441.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800441.jar “lang/*” -d /var/packages/CrashPlan/target/

    mv /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/upgrade.sh.old

    mv /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/service.log.xml /var/packages/CrashPlan/target/conf/service.log.xml

    This extra command will fill the log again. Otherwise you can’t see Crashplan starting in the log on your NAS.

    I’m not able to connect my client to the NAS, so something is still broken. But at least, files are backing up again :-)

    Reply
    1. Mike's avatarMike

      OK, so this got CP back & running on the NAS, like you I still can’t connect with my Mac Client, but the log shows stuff being backed up!

      Reply
    2. George's avatarGeorge

      Thanks Yves for posting this. Have been successful in upgrading Synology package this way. I am using Linux client, and that is able to connect to CP server (has always worked) without any problems or changes (even running 4.3.3 on client).

      Reply
    3. B. Goodman's avatarB. Goodman

      Thanks especially for your note about having to run this command on each of the “several” directories. I think I had 10! If I had any Linux scripting skills I’d create something to list out these directories, parse the output, and issue the command for each directory. I’m sure I could do it in a Windows batch file, but I’m totally out of my depth in Linux/unix. Any script gurus want to take a shot? :)

      Reply
      1. B. Goodman's avatarB. Goodman

        Over at http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/
        dSebastien offered up this (which I haven’t needed yet since I did it manually):

        I’ve just used the following (from the ‘/var/packages/CrashPlan/target/upgrade’ folder):
        for f in ./*/upgrade.sh; do mv “$f” “$(dirname “$f”)/upgrade.sh.old”

        (*I changed his post where he apparently had “smart quotes” to standard quotes, as suggested by “Bionic Cat”)

      2. B. Goodman's avatarB. Goodman

        One extra “gotcha” this time that I had not seen before: CrashPlan took it upon itself to change my listening port number which caused all my “friends” to fail to reach my server remotely. (I disable UPnP in my router so it won’t auto-forward.)

        Once I changed it back to what I had been using, the remote machines all started to connect again.

    4. arl's avatararl

      Thx for all of these tips, I have managed to get it working again.

      What I did, about the numerous folders with the upgrade.sh, is I deleted them all, except the last one, and only did it for that one.

      I also did the jna.jar action, as root user.

      I did not yet check, wether I could logon remotely

      Reply
    5. hal sandick's avatarhal sandick

      i did not see your post and put this together from several others posts. thanks for putting it in one place!

      hal

      Reply
  32. Denny's avatarDenny

    Interestingly, CP on my NAS unit upgraded without this intervention. I had to stop/start the package (via the package manager gui) three times, waiting for the CPU utilization to settle down each time, but it completed the upgrade on it’s own. In my case, the upgrade was from 4.3.0 to 4.4.1.

    With regard to remote access, it’s been mentioned elsewhere that the requirements for remote access have changed as of 4.3.1 or 4.3.2. On the NAS unit, you need to edit /var/lib/crashplan/.ui_info, and change the listen address from 127.0.0.1 to 0.0.0.0 (or an explicit IP address) and then restart CP. On the client host, you need to edit the .ui_info file to ensure the shared secret is the same (field 2) and that the IP address (field 3) is that of your NAS. serviceHost in ui.properties appears to no longer be used.

    I’m working solidly with 4.4.1 running on both the NAS and my linux box (remote client).

    Reply
    1. Mike's avatarMike

      My listen address is set to 0.0.0.0 and I have the GUID copied to my Mac and my client will not connect. Everything worked OK until this latest update.

      Reply
      1. Denny's avatarDenny

        Do you have the address of the server in the .ui_info file on the Mac? And are you are running the same version on the Mac as on the the NAS (4.4.1)?

      2. Singularity's avatarSingularity

        For those not able to connect to their NAS I’d suggest grabbing the latest client from Code42! I was running 4.3 and my NAS was on 4.4 and it refused to connect. I installed 4.4.1 on my MAC and now I’m able to connect, after the usual tweaks of course!

        For some reason it’s not talking with CP Central so I need to figure that out, but at least I’m able to communicate with my NAS once again! *WHEW*

        Good luck everyone, and make sure you let Code42 know disappointed you are that they have ZERO interest in supporting this even though they’re losing customers..

        I for one am looking at iDrive simply because it’s a fully supported platform, great features and can’t beat the price!

        Thanks again for all your hard work Patters, too bad Code42 are jerks..

      3. DEXTER's avatarDEXTER

        After I upgraded manually to 4.4.1 the client was able to connect to the NAS. But now I also have the issue where it is not connecting to Crashplan central.

        Unfortunately idrive is not supporting all Synology models. Mine is DS413 and it is not supported. Any other good alternatives?

      4. wraczlavski's avatarjirikafka

        @DEXTER Don´t sweat it; basically there are only 2 types of packages of iDrive for Synology – x86 and ARM version. Grab one, and try it with free account.

      5. DEXTER's avatarDEXTER

        @Singularity: This is what made it work for me, to connect to crashplan central again:
        cp /var/packages/CrashPlan/target/lib/jna-3.2.5.jar /var/packages/CrashPlan/target/lib/jna.jar

        So much hack is needed after every upgrade, I’m really in need of a reliable/working backup solution now…

    2. Jens's avatarJens

      Hi @all!

      Can you give me an advice on how to upgrade to V4.4.1 on my Syno DS2415+?
      I’m still on 4.3.3 and my syno is not updating automatically (even not after a service restart) and Denny’s post really made me curious… ;-)

      Cheers,
      Jens.

      Reply
      1. Denny's avatarDenny

        It should begin the update on restart. However, you may have to wait for Code42 to push the update to you. I assume that they randomize the push of the update over several days to avoid overloading their servers.

    3. jbrerhel's avatarjbrerhel

      Sorry for the daft question, but how do you access the /var path above and make the changes? Using SSH, or directly through the DSM interface? And if using SSH, is there a place where I can see some advice or a tutorial on how to execute the changes (what specific commands to use)?

      thanks!

      Reply
  33. Mark Venn's avatarMark Venn

    I followed Yves’ instructions, having first uninstalled and reinstalled the package on my Synology NAS. I found two instances of (failed) upgrades to 4.4.1 and I moved the upgrade.sh file to upgrade.sh.old in both of them. I then restarted the package on the NAS and followed the process to manually unzip the files from the newer of the two upgrade folders and moved the service.log.xml file.

    Running cat /var/lib/crashplan/.ui_info I noticed that the listen IP address on the NAS was already set to 0.0.0.0. I therefore edited .ui_info on my client (running on Yosemite) to overwrite the GUID with the value from the NAS and I changed the listen IP address to match my NAS’s LAN IP address. I’ve now been able to connect to the NAS from my Mac for the first time in 10 days!

    It remains to be seen whether this will survive a reboot of the NAS and the Mac, let alone the upgrade to El Capitan which is planned for later today ;-) Thanks to Yves and Denny for their posts.

    Reply
  34. Mike's avatarMike

    That was the issue with the Mac, the client for some reason didn’t update, it was still 4.3. This morning it’s updated to 4.4.1 and now everything connects!

    Reply
      1. Mike's avatarMike

        OK, Panic over. Of course the update changed the GUID! Also I noticed using 0.0.0.0 didn’t connect. I had to change it to the address of my NAS. If you have it publicly addressable you can use http://www.blahblah.com rather than a fixed IP address.

      2. David's avatarDavid

        I can get the client to connect now that I updated it to 4.4.1, but now backups won’t start. The engine_error.log file has this error:

        xception in thread “W32598491_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
        at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:22)
        at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:417)
        at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(BackupSetsManager.java:355)
        at com.code42.backup.path.BackupSetsManager.access$1600(BackupSetsManager.java:72)
        at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(BackupSetsManager.java:1148)
        at com.code42.utils.AWorker.run(AWorker.java:157)
        at java.lang.Thread.run(Thread.java:745)

        I’ve found discussions online that associate this with the wrong temp directory, but the temp directory in both the config files and the logs is set to /volume1/@tmp so that should be fine. I did try reinstalling a few times in the last few days. The upgrade to 4.4.1 runs fine, so that’s not the problem.

      3. David's avatarDavid

        I finally got it to work on my DS213+. In addition to copying over service.log.xml as Mike earlier suggested, I also found that CrashPlan now includes a jna-3.2.5.jar file and no jna.jar file. I tried copying the jna-3.2.5.jar file in place of the jna.jar file and that fixed the issue. It now runs and successfully scans/backups.

      4. DEXTER's avatarDEXTER

        Wow, this is it! Copying the jna.jar made it work again for me.
        So this is a needed step:
        cp /var/packages/CrashPlan/target/lib/jna-3.2.5.jar /var/packages/CrashPlan/target/lib/jna.jar

  35. Greg's avatarGreg

    Another Upgrade issue. Looks on 9/30 another upgrade was attempted. Log says installing upgrade 1435726800441 and that upgrade failed. It tried a repair of the upgrade and that is the last log entry. Crashplan will not start. Any ideas?

    Reply
    1. Greg's avatarGreg

      Nevermind, I followed the steps from Yves and got the latest version installed. It however keeps crashing. I am going to look at iDrive as well. I can’t spend several hours going through this each time an upgrade happens. It is unfortunate. I sent a support note to Code42 as well telling them people are dropping them because they do not support this. Bummer!

      Reply
  36. Denny's avatarDenny

    One thing that occurs to me that may have been key to the automated upgrade working. I had previously upgraded Java to 1.7.0_79 via the Java Manager, so there was no Java upgrade step to be done as part of CP’s upgrade.

    Reply
      1. Denny's avatarDenny

        Similarly, Package Manager will continue to report the CrashPlan package as version 4.3.0-0033 even though CrashPlan itself has been upgraded to 4.4.1.

  37. Per's avatarPer

    Finally CP released a Windows 4.4.1 client. I’m now fully upgraded and everything works as expected.

    I wonder how long time we have to wait before they push the next upgrade?

    Reply
  38. nickzeff's avatarnickzeff

    Well, this is frustrating! After much mucking around, I decided to uninstall and re-install Patters latest 4.3 CrashPlan package and started it.

    It then downloaded the 4.4.1 upgrade packages and failed to upgrade (as expected). I then followed the instructions at http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/ to manually copy the relevant jar files and rename the upgrade scripts.

    At this point the crashplan site showed that the engine was connected, but I’m pretty sure nothing was being backed up.

    I downloaded the latest 32 bit windows client version 4.4.1 from the Crashplan site and ensured the .ui_info file was updated with the relevant key and IP address of my NAS (as per guidance on Chris Nelson’s site above).

    Unfortunately now whenever I try to connect with the client it causes a fatal Java error with the engine and CrashPlan just stops on the NAS.

    I cannot work out why this is. The client and engine are now the same version, and I’m pretty sure the values in the .ui_info file are correct.

    Anybody fixed a similar problem?

    Reply
    1. Chermette's avatarChermette

      Hi, same thing here. I followed every step of the instructions posted earlier here (thanks a lot for these!), but as soon as I try to connect through my Mac, there’s a Java exception that kills CP on my Synology

      Reply
      1. Chermette's avatarChermette

        Tried Java 7 & 8, to no extent. But I think I’ve got it figured out. Thing is, I tried to reinstall CP from scratch on my NAS on Thursday. For some reasons unknown to me, it only downloaded v4.41, so I only installed this version on top of patters’s v4.3… This morning, I tried again to re-install CP from scratch, and it downloaded 4 versions (3.31, 3.32, 4.40 & 4.41 from memory – I might be wrong here). When I installed the 4 versions, I saw that 4.40 came with a lot of jars, I guess Code42 included new dependancies… v4.41 obviously didn’t embed that many external jars. Which totally explains why I got a JavaException error from Thursday on, which don’t happen anymore now that I installed all missing versions (i.e. all missing jars).

        Anyway, now I’m almost back on business… Because now, I’m stuck with a NotEnoughMemory error when I connect from CP on my Mac to my NAS…….. AAAAAAAAAARRRRGGGG :)

        Cheers

  39. Tazmanian's avatarTazmanian

    Since yesterday I also have the client working. Everything is working just fine now.

    There is one extra edit you need to do:

    ….
    echo `cat /var/lib/crashplan/.ui_info`
    Note those are backticks not quotes. This will give you a port number followed by a GUID:
    4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0
    ….

    Now, changes 0.0.0.0 to the IP of your NAS.

    When I did this I can connect the client (4.4.1) to my NAS, no problems anymore.

    Reply
  40. marco's avatarmarco

    lets give above tips a try, not having insight if anything is happening for my cloud backup solution is irritating and not what I paid for

    Reply
    1. marco's avatarmarco

      Yess!! It works again with help of this thread. Thanks guys! Hopefully nothing gets changed again soon.

      Reply
  41. Chris's avatarChris

    Wonder if anyone can help – I have 4.4.1 on my NAS after doing a manual update and the latest Windows client.

    I can’t get the .ui_info file to stick. Every time I change 0.0.0.0 to my NAS’s IP address (or even to “diskstation” which resolves to the same place), when I restart the package the file is reverted to a new ID and 0.0.0.0.

    Although I note that the newer client doesn’t say “disconnect from backup server”

    Any ideas?

    Reply
  42. Peter's avatarPeter

    What is the newest crasjplan package you guys are running?
    It seems like it’s 4.4.1 but my community package center is showing 4.3.0-0033, and wheni I try to install the package, it states “Failed to install Crashplan” There was a problem downloading Crashplan 4.3.0_Linux.tgz and then the path to crashplans server.
    I’m running DSM 5.2-5592 update 4 on a DS 1511+

    Reply
  43. Sam's avatarSam

    This thing really is a joke. After finally getting it working again after weeks of downtime, there’s a new update and now it’s totally kaput again, refusing to connect.

    Reply

Leave a reply to Fabien Cancel reply