CrashPlan packages for Synology NAS

UPDATE – The instructions and notes on this page apply to all three versions of the package hosted on my repo: CrashPlan, CrashPlan PRO, and CrashPlan PROe.

CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient – it could even get stolen or destroyed and you would still have your data. Whilst you can pay a small monthly charge for a storage allocation in the Cloud, one neat feature CrashPlan offers is for individuals to collaboratively backup their important data to each other – for free! You could install CrashPlan on your laptop and have it continuously protecting your documents to your NAS, even whilst away from home.


CrashPlan is a Java application, and 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 a few others. As I started I used information from Kenneth Larsen’s blog post, the Vincesoft blog article for installing on ARM processor Iomega NAS units, and this handy PDF document which is a digest of all of them. I used the PowerPC binaries Christophe had compiled on his blog, so thanks go to him. I wanted make sure the package didn’t require the NAS to be bootstrapped, so I bundled any dependent binaries. Back in 2012 I didn’t know how to cross compile properly so I had to use versions I had found, but over the years I have had to compile my own versions of many of these binaries, especially as I added support for Synology’s huge proliferation of different CPU architectures.

UPDATE – For version 3.2 I also had to identify and then figure out how to compile Tim Macinta’s fast MD5 library, to fix the supplied on ARM systems (CrashPlan only distributes libraries for x86). I’m documenting that process here in case more libs are required in future versions. I identified it from the error message in log/engine_error.log and by running objdump -x I could see that the same Java_com_twmacinta_util_MD5_Transform_1native function mentioned in the error was present in the x86 lib but not in my compiled from W3C Libwww. I took the headers from an install of OpenJDK on a regular Ubuntu desktop. I then used the Linux x86 source from the download bundle on Tim’s website – the closest match – and compiled it directly on the syno using the command line from a comment in another version of that source:
gcc -O3 -shared -I/tmp/jdk_headers/include /tmp/fast-md5/src/lib/arch/linux_x86/MD5.c -o

Licence compliance is another challenge – Code 42 Software’s EULA prohibits redistribution of their work. I had to make the syno package download CrashPlan for Linux (after the end user agrees their EULA), then I had to write my own script to extract this archive and mimic their installer, since their installer is interactive


Synology Package Installation

    • In Synology DSM’s Package Center, click Settings and add my package repository:
      Add Package Repository
    • The repository will push its certificate automatically to the NAS, which is used to validate package integrity. Set the Trust Level to Synology Inc. and trusted publishers:
      Trust Level
    • Now browse the Community section in Package Center to install CrashPlan. The repository only displays packages which are compatible with your specific model of NAS. If you don’t see CrashPlan in the list, then either your NAS model or your DSM version are not supported at this time. DSM 5.0 is the minimum supported version for this package.
    • Since CrashPlan is a Java application, you will need to install one of my Java SE Embedded packages first (Java 7 or 8). Read the instructions on that page carefully too.
    • CrashPlan is installed in headless mode – backup engine only. This is 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.
    • If you previously installed CrashPlan manually using the Synology Wiki, you can find uninstall instructions here.

    CrashPlan Client Installation

    • Once the engine is running, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
    • To do this you need to edit the file conf/ in the CrashPlan folder on that computer so that this line:
      is uncommented (by removing the hash symbol) and set to the IP address of your NAS, e.g.:
      Mac OS X users can edit this file from the Terminal using:
      sudo nano /Applications/
      (use Ctrl-X to save changes and exit)
    • Starting with CrashPlan version 4.3.0 you will also need to 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 followed by a GUID:
      Copy this GUID and use this value to replace the GUID in the equivalent file on the computer you want to run the CrashPlan client on:
      C:\ProgramData\CrashPlan\.ui_info (Windows)
      /Library/Application Support/CrashPlan/.ui_info (Mac OS X)
      /var/lib/crashplan/.ui_info (Linux)
      You will not be able to connect the client unless these GUIDs match on the NAS and the client.
    • 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) 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 cp /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



    • The package downloads the CrashPlan installer directly from Code 42 Software, following acceptance of their EULA. I am complying with their wish that no one redistributes it.
    • Real-time backup does not work on PowerPC systems for some unknown reason, despite many attempts to cross compile libjna, and attempts to use binaries taken from various Debian distros (methods that work for the other supported CPU architectures).
    • 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. 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 sets which are scheduled to be protected at different times
    • The default location for saving friends’ backups is set to /volume1/crashplan/backupArchives (where /volume1 is you primary storage volume) to eliminate the chance of them being destroyed accidentally by uninstalling the package.
    • If you need to manage CrashPlan from a remote location, I suggest you do so using SSH tunnelling as per this support document.
    • The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache. Upgrades can now take place without requiring a login from the client afterwards.
    • If you remove the package completely and re-install it later, you can re-attach to previous backups. When you log in to the Desktop Client with your existing account after a re-install, you can select “adopt computer” to merge the records, and preserve your existing backups. I haven’t tested whether this also re-attaches links to friends’ CrashPlan computers and backup sets, though the latter does seem possible in the Friends section of the GUI. It’s probably a good idea to test that this survives a package reinstall before you start relying on it. Sometimes, particularly with CrashPlan PRO I think, the adopt option is not offered. In this case you can log into CrashPlan Central and retrieve your computer’s GUID. On the CrashPlan client, double-click on the logo in the top right and you’ll enter a command line mode. You can use the GUID command to change the system’s GUID to the one you just retrieved from your account.
    • The log which is displayed in the package’s Log tab is actually the activity history. If you are trying to troubleshoot an issue you will need to use an SSH session to inspect these log files:
    • When CrashPlan downloads and attempts to run an automatic update, the script will most likely fail and stop the package. This is typically caused by syntax differences with the Synology versions of certain Linux shell commands (like rm, mv, or ps). The startup script will attempt to apply the published upgrade the next time the package is started.
    • Although CrashPlan’s activity can be scheduled within the application, in order to save RAM some users may wish to restrict running the CrashPlan engine to specific times of day using the Task Scheduler in DSM Control Panel:
      Schedule service start
      This is particularly useful on ARM systems because CrashPlan currently prevents hibernation while it is running (unresolved issue, reported to Code 42). 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 Package wiki.

    #--------CRASHPLAN installer script
    #--------package maintained at
    [ "${SYNOPKG_PKGNAME}" == "CrashPlan" ] && DOWNLOAD_FILE="CrashPlan_4.3.0_Linux.tgz"
    [ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_4.3.0_Linux.tgz"
    if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
      [ "${WIZARD_VER_430}" == "true" ] && CPPROE_VER="4.3.0"
      [ "${WIZARD_VER_420}" == "true" ] && CPPROE_VER="4.2.0"
      [ "${WIZARD_VER_370}" == "true" ] && CPPROE_VER="3.7.0"
      [ "${WIZARD_VER_364}" == "true" ] && CPPROE_VER="3.6.4"
      [ "${WIZARD_VER_363}" == "true" ] && CPPROE_VER="3.6.3"
      [ "${WIZARD_VER_3614}" == "true" ] && CPPROE_VER=""
      [ "${WIZARD_VER_353}" == "true" ] && CPPROE_VER="3.5.3"
      [ "${WIZARD_VER_341}" == "true" ] && CPPROE_VER="3.4.1"
      [ "${WIZARD_VER_33}" == "true" ] && CPPROE_VER="3.3"
    SYNO_CPU_ARCH="`uname -m`"
    [ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
    [ "${SYNO_CPU_ARCH}" == "armv5tel" ] && SYNO_CPU_ARCH="armle"
    [ "${SYNO_CPU_ARCH}" == "armv7l" ] && SYNO_CPU_ARCH="armle"
    [ "${SYNOPKG_DSM_ARCH}" == "armada375" ] && SYNO_CPU_ARCH="armle"
    [ "${SYNOPKG_DSM_ARCH}" == "comcerto2k" ] && SYNO_CPU_ARCH="armhf"
    [ "${SYNOPKG_DSM_ARCH}" == "alpine" ] && SYNO_CPU_ARCH="armhf"
    NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
    TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
    #the Manifest folder is where friends' backup data is stored
    #we set it outside the app folder so it persists after a package uninstall
    MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
    UPGRADE_FILES="syno_package.vars conf/my.service.xml conf/service.login conf/service.model"
    UPGRADE_FOLDERS="log cache"
    PUBLIC_FOLDER="`synoshare --get public | sed -r "/Path/!d;s/^.*\[(.*)\].*$/\1/"`"
    source /etc/profile
    preinst ()
      if [ -z ${JAVA_HOME} ]; then
        echo "Java is not installed or not properly configured. JAVA_HOME is not defined. "
        echo "Download and install the Java Synology package from"
        exit 1
      if [ ! -f ${JAVA_HOME}/bin/java ]; then
        echo "Java is not installed or not properly configured. The Java binary could not be located. "
        echo "Download and install the Java Synology package from"
        exit 1
      cd ${TEMP_FOLDER}
      for WGET_URL in ${INSTALL_FILES}
        WGET_FILENAME="`echo ${WGET_URL} | sed -r "s%^.*/(.*)%\1%"`"
        wget ${WGET_URL}
        if [[ $? != 0 ]]; then
          if [ -d ${PUBLIC_FOLDER} ] && [ -f ${PUBLIC_FOLDER}/${WGET_FILENAME} ]; then
            echo "There was a problem downloading ${WGET_FILENAME} from the official download link, "
            echo "which was \"${WGET_URL}\" "
            echo "Alternatively, you may download this file manually and place it in the 'public' shared folder. "
            exit 1
      exit 0
    postinst ()
      #extract CPU-specific additional binaries
      mkdir ${SYNOPKG_PKGDEST}/bin
      cd ${SYNOPKG_PKGDEST}/bin
      #extract main archive
      cd ${TEMP_FOLDER}
      #extract cpio archive
      cat "${TEMP_FOLDER}/${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}/${EXTRACTED_FOLDER}/scripts/CrashPlanEngine ${OPTDIR}/bin
      cp ${TEMP_FOLDER}/${EXTRACTED_FOLDER}/scripts/run.conf ${OPTDIR}/bin
      mkdir -p ${MANIFEST_FOLDER}/backupArchives    
      #save install variables which Crashplan expects its own installer script to create
      echo BINSDIR=/bin >> ${VARS_FILE}
      echo MANIFESTDIR=${MANIFEST_FOLDER}/backupArchives >> ${VARS_FILE}
      #leave these ones out which should help upgrades from Code42 to work (based on examining an upgrade script)
      #echo INITDIR=/etc/init.d >> ${VARS_FILE}
      #echo RUNLVLDIR=/usr/syno/etc/rc.d >> ${VARS_FILE}
      echo INSTALLDATE=`date +%Y%m%d` >> ${VARS_FILE}
      echo JAVACOMMON=\${JAVA_HOME}/bin/java >> ${VARS_FILE}
      cat ${TEMP_FOLDER}/${EXTRACTED_FOLDER}/install.defaults >> ${VARS_FILE}
      #remove temp files
      #add firewall config
      /usr/syno/bin/servicetool --install-configure-file --package /var/packages/${SYNOPKG_PKGNAME}/scripts/${SYNOPKG_PKGNAME}.sc > /dev/null
      #amend CrashPlanPROe client version
      [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ] && sed -i -r "s/^version=\".*(-.*$)/version=\"${CPPROE_VER}\1/" /var/packages/${SYNOPKG_PKGNAME}/INFO
      exit 0
    preuninst ()
      exit 0
    postuninst ()
      if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
        source ${SYNOPKG_PKGDEST}/syno_package.vars
      [ -e ${OPTDIR}/lib/ ] && rm ${OPTDIR}/lib/
      #delete symlink if it no longer resolves - PowerPC only
      if [ ! -e /lib/ ]; then
        [ -L /lib/ ] && rm /lib/
      #remove firewall config
      if [ "${SYNOPKG_PKG_STATUS}" == "UNINSTALL" ]; then
        /usr/syno/bin/servicetool --remove-configure-file --package ${SYNOPKG_PKGNAME}.sc > /dev/null
     exit 0
    preupgrade ()
      #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
          if [ -d ${OPTDIR}/${FOLDER_TO_MIGRATE} ]; then
      exit 0
    postupgrade ()
      #use the migrated identity and config data from the previous version
      if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf/my.service.xml ]; then
        for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
          if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ]; then
        if [ -d ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ]; then
        rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
        rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig
        #make CrashPlan log entry
        TIMESTAMP="`date "+%D %I:%M%p"`"
        echo "I ${TIMESTAMP} Synology Package Center updated ${SYNOPKG_PKGNAME} to version ${SYNOPKG_PKGVER}" >> ${LOG_FILE}
      exit 0

    #--------CRASHPLAN start-stop-status script
    #--------package maintained at
    TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
    MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan" 
    PKG_FOLDER="`dirname $0 | cut -f1-4 -d'/'`"
    DNAME="`dirname $0 | cut -f4 -d'/'`"
    JAVA_MIN_HEAP=`grep "^${CFG_PARAM}=" "${OPTDIR}/bin/${ENGINE_CFG}" | sed -r "s/^.*-Xms([0-9]+)[Mm] .*$/\1/"` 
    SYNO_CPU_ARCH="`uname -m`"
    TIMESTAMP="`date "+%D %I:%M%p"`"
    source ${OPTDIR}/install.vars
    source /etc/profile
    source /root/.profile
    start_daemon ()
      #check persistent variables from syno_package.vars
      if [ -f ${OPTDIR}/syno_package.vars ]; then
        source ${OPTDIR}/syno_package.vars
      USR_MAX_HEAP=`echo $USR_MAX_HEAP | sed -e "s/[mM]//"`
      #do we need to restore the identity file - has a DSM upgrade scrubbed /var/lib/crashplan?
      if [ ! -e /var/lib/crashplan ]; then
        mkdir /var/lib/crashplan
        [ -e ${OPTDIR}/conf/var-backup/.identity ] && cp ${OPTDIR}/conf/var-backup/.identity /var/lib/crashplan/
      #fix up some of the binary paths and fix some command syntax for busybox 
      #moved this to from because Code42 push updates and these
      #new scripts will need this treatment too
      find ${OPTDIR}/ -name "*.sh" | while IFS="" read -r FILE_TO_EDIT; do
        if [ -e ${FILE_TO_EDIT} ]; then
          #this list of substitutions will probably need expanding as new CrashPlan updates are released
          sed -i "s%^#!/bin/bash%#!$/bin/sh%" "${FILE_TO_EDIT}"
          sed -i -r "s%(^\s*)(/bin/ps|ps) [^w][^\|]*\|%\1/bin/ps w \|%" "${FILE_TO_EDIT}"
          sed -i -r "s%\`ps [^w][^\|]*\|%\`ps w \|%" "${FILE_TO_EDIT}"
          sed -i -r "s%^ps [^w][^\|]*\|%ps w \|%" "${FILE_TO_EDIT}"
          sed -i "s/rm -fv/rm -f/" "${FILE_TO_EDIT}"
          sed -i "s/mv -fv/mv -f/" "${FILE_TO_EDIT}"
      #use this daemon init script rather than the unreliable Code42 stock one which greps the ps output
      sed -i "s%^ENGINE_SCRIPT=.*$%ENGINE_SCRIPT=$0%" ${OPTDIR}/bin/
      #any downloaded upgrade script will usually have failed despite the above changes
      #so ignore the script and explicitly extract the new java code using the method 
      UPGRADE_SCRIPT=`find ${OPTDIR}/upgrade -name ""`
      if [ -n "${UPGRADE_SCRIPT}" ]; then
        rm ${OPTDIR}/*.pid
        #make CrashPlan log entry
        echo "I ${TIMESTAMP} Synology repairing upgrade in ${SCRIPT_HOME}" >> ${DLOG}
        mv ${SCRIPT_HOME}/upgrade.log ${SCRIPT_HOME}/upgrade.log.old
        UPGRADE_VER=`echo ${SCRIPT_HOME} | sed -r "s/^.*\/([0-9]+)\.[0-9]+/\1/"`
        unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -d ${OPTDIR}/lib/
        unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -d ${OPTDIR}
        mv ${SCRIPT_HOME}/ ${SCRIPT_HOME}/
        exit 0
      #updates may also overwrite our native binaries
      [ -e ${OPTDIR}/bin/ ] && cp -f ${SYNOPKG_PKGDEST}/bin/ ${OPTDIR}/lib
      [ -e ${OPTDIR}/bin/ ] && cp -f ${OPTDIR}/bin/ ${OPTDIR}/
      cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib
      #create or repair symlink if a DSM upgrade has removed it - PowerPC only
      if [ -e ${OPTDIR}/lib/ ]; then
        if [ ! -e /lib/ ]; then
          #if it doesn't exist, but is still a link then it's a broken link and should be deleted first
          [ -L /lib/ ] && rm /lib/
          ln -s ${OPTDIR}/lib/ /lib/
      #set appropriate Java max heap size
      RAM=$((`free | grep Mem: | sed -e "s/^ *Mem: *\([0-9]*\).*$/\1/"`/1024))
      if [ $RAM -le 128 ]; then
      elif [ $RAM -le 256 ]; then
      elif [ $RAM -le 512 ]; then
      elif [ $RAM -le 1024 ]; then
      elif [ $RAM -gt 1024 ]; then
      if [ $USR_MAX_HEAP -gt $JAVA_MAX_HEAP ]; then
      if [ $JAVA_MAX_HEAP -lt $JAVA_MIN_HEAP ]; then
        #can't have a max heap lower than min heap (ARM low RAM systems)
      sed -i -r "s/(^${CFG_PARAM}=.*) -Xmx[0-9]+[mM] (.*$)/\1 -Xmx${JAVA_MAX_HEAP}m \2/" "${OPTDIR}/bin/${ENGINE_CFG}"
      #disable the use of the x86-optimized external Fast MD5 library if running on ARM and PPC CPUs
      #seems to be the default behaviour now but that may change again
      [ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
      if [ "${SYNO_CPU_ARCH}" != "i686" ]; then
        grep "^${CFG_PARAM}=.*c42\.native\.md5\.enabled" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
         || sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1 -Dc42.native.md5.enabled=false\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
      #move the Java temp directory from the default of /tmp
      grep "^${CFG_PARAM}=.*Djava\.io\.tmpdir" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
       || sed -i -r "s%(^${CFG_PARAM}=\".*)\"$%\1${TEMP_FOLDER}\"%" "${OPTDIR}/bin/${ENGINE_CFG}"
      #now edit the XML config file, which only exists after first run
      if [ -f ${OPTDIR}/conf/my.service.xml ]; then
        #allow direct connections from CrashPlan Desktop client on remote systems
        #you must edit the value of serviceHost in conf/ on the client you connect with
        #users report that this value is sometimes reset so now it's set every service startup 
        sed -i "s/<serviceHost>127\.0\.0\.1<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${OPTDIR}/conf/my.service.xml"
        #default changed in CrashPlan 4.3
        sed -i "s/<serviceHost>localhost<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${OPTDIR}/conf/my.service.xml"
        #this change is made only once in case you want to customize the friends' backup location
        if [ "${MANIFEST_PATH_SET}" != "True" ]; then
          #keep friends' backup data outside the application folder to make accidental deletion less likely 
          sed -i "s%<manifestPath>.*</manifestPath>%<manifestPath>${MANIFEST_FOLDER}/backupArchives/</manifestPath>%" "${OPTDIR}/conf/my.service.xml"
          echo "MANIFEST_PATH_SET=True" >> ${OPTDIR}/syno_package.vars
        #since CrashPlan version 3.5.3 the value javaMemoryHeapMax also needs setting to match that used in bin/run.conf
        sed -i -r "s%(<javaMemoryHeapMax>)[0-9]+[mM](</javaMemoryHeapMax>)%\1${JAVA_MAX_HEAP}m\2%" "${OPTDIR}/conf/my.service.xml"
        #make sure CrashPlan is not binding to the IPv6 stack
        grep "\-Djava\.net\.preferIPv4Stack=true" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
         || sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
        echo "Check the package log to ensure the package has started successfully, then stop and restart the package to allow desktop client connections." > "${SYNOPKG_TEMP_LOGFILE}"
      #increase the system-wide maximum number of open files from Synology default of 24466
      echo "65536" > /proc/sys/fs/file-max
      #raise the maximum open file count from the Synology default of 1024 - thanks Casper K. for figuring this out
      ulimit -n 65536
      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 $!
        if [ -z "${SYNOPKG_PKGDEST}" ]; then
          #script was manually invoked, need this to show status change in Package Center      
          [ -e ${PKG_FOLDER}/enabled ] || touch ${PKG_FOLDER}/enabled
        echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" > "${SYNOPKG_TEMP_LOGFILE}"
        echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" >&2
        exit 1
    stop_daemon ()
      echo "I ${TIMESTAMP} Stopping ${DNAME}" >> ${DLOG}
      kill `cat ${PID_FILE}`
      wait_for_status 1 20 || kill -9 `cat ${PID_FILE}`
      rm -f ${PID_FILE}
      if [ -z ${SYNOPKG_PKGDEST} ]; then
        #script was manually invoked, need this to show status change in Package Center
        [ -e ${PKG_FOLDER}/enabled ] && rm ${PKG_FOLDER}/enabled
      #backup identity file in case DSM upgrade removes it
      [ -e ${OPTDIR}/conf/var-backup ] || mkdir ${OPTDIR}/conf/var-backup 
      cp /var/lib/crashplan/.identity ${OPTDIR}/conf/var-backup/
    daemon_status ()
      if [ -f ${PID_FILE} ] && kill -0 `cat ${PID_FILE}` > /dev/null 2>&1; then
      rm -f ${PID_FILE}
      return 1
    wait_for_status ()
      while [ ${counter} -gt 0 ]; do
        [ $? -eq $1 ] && return
        let counter=counter-1
        sleep 1
      return 1
    case $1 in
        if daemon_status; then
          echo ${DNAME} is already running with PID `cat ${PID_FILE}`
          exit 0
          echo Starting ${DNAME} ...
          exit $?
        if daemon_status; then
          echo Stopping ${DNAME} ...
          exit $?
          echo ${DNAME} is not running
          exit 0
        exit $?
        if daemon_status; then
          echo ${DNAME} is running with PID `cat ${PID_FILE}`
          exit 0
          echo ${DNAME} is not running
          exit 1
        echo "${DLOG}"
        exit 0
        echo "Usage: $0 {start|stop|status|restart}" >&2
        exit 1

    install_uifile & upgrade_uifile

        "step_title": "Client Version Selection",
        "items": [
            "type": "singleselect",
            "desc": "Please select the CrashPlanPROe client version that is appropriate for your backup destination server:",
            "subitems": [
                "key": "WIZARD_VER_430",
                "desc": "4.3.0",
                "defaultValue": true
                "key": "WIZARD_VER_420",
                "desc": "4.2.0",
                "defaultValue": false
                "key": "WIZARD_VER_370",
                "desc": "3.7.0",
                "defaultValue": false
                "key": "WIZARD_VER_364",
                "desc": "3.6.4",
                "defaultValue": false
                "key": "WIZARD_VER_363",
                "desc": "3.6.3",
                "defaultValue": false
                "key": "WIZARD_VER_3614",
                "desc": "",
                "defaultValue": false
                "key": "WIZARD_VER_353",
                "desc": "3.5.3",
                "defaultValue": false
                "key": "WIZARD_VER_341",
                "desc": "3.4.1",
                "defaultValue": false
                "key": "WIZARD_VER_33",
                "desc": "3.3",
                "defaultValue": false


    • 0031 Added TCP 4242 to the firewall services (computer to computer connections)
    • 0033 Fixed version 0032 client connection issue for fresh installs
    • 0032 Updated to CrashPlan 4.3, PLEASE READ UPDATED BLOG POST INSTRUCTIONS FOR CLIENT INSTALL this version introduced an extra requirement, changed update repair to use the method, forced CrashPlan to prefer IPv4 over IPv6 bindings, removed some legacy version migration scripting, updated main blog post documentation
    • 0031 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 Fixed show-stopping issue with version 0029 for systems with more than one volume
    • 0029 Updated to CrashPlan version 3.7.0, improved detection of temp folder (prevent use of /var/@tmp), added support for Annapurna Alpine AL514 CPU (armhf) in DS2015xs, added support for Marvell Armada 375 CPU (armhf) in DS215j, abandoned practical efforts to try to support Code42’s upgrade scripts, abandoned inotify support (realtime backup) on PowerPC after many failed attempts with self-built and pre-built jtux and jna libraries, back-merged older libffi support for old PowerPC binaries after it was removed in 0028 re-write
    • 0028 Substantial re-write:
      Updated to CrashPlan version 3.6.4
      DSM 5.0 or newer is now required taken from Debian JNA 3.2.7 package with dependency on newer (included in DSM 5.0)
      jna-3.2.5.jar emptied of irrelevant CPU architecture libs to reduce size
      Increased default max heap size from 512MB to 1GB on systems with more than 1GB RAM
      Intel CPUs no longer need the awkward glibc version-faking shim to enable inotify support (for real-time backup)
      Switched to using root account – no more adding account permissions for backup, package upgrades will no longer break this
      DSM Firewall application definition added
      Tested with DSM Task Scheduler to allow backups between certain times of day only, saving RAM when not in use
      Daemon init script now uses a proper PID file instead of Code42’s unreliable method of using grep on the output of ps
      Daemon init script can be run from the command line
      Removal of bash binary dependency now Code42’s CrashPlanEngine script is no longer used
      Removal of nice binary dependency, using BusyBox equivalent renice
      Unified ARMv5 and ARMv7 external binary package (armle)
      Added support for Mindspeed Comcerto 2000 CPU (comcerto2k – armhf) in DS414j
      Added support for Intel Atom C2538 (avoton) CPU in DS415+
      Added support to choose which version of CrashPlan PROe client to download, since some servers may still require legacy versions
      Switched to .tar.xz compression for native binaries to reduce web hosting footprint
    • 0027 Fixed open file handle limit for very large backup sets (ulimit fix)
    • 0026 Updated all CrashPlan clients to version 3.6.3, improved handling of Java temp files
    • 0025 glibc version shim no longer used on Intel Synology models running DSM 5.0
    • 0024 Updated to CrashPlan PROe and added support for PowerPC 2010 Synology models running DSM 5.0
    • 0023 Added support for Intel Atom Evansport and Armada XP CPUs in new DSx14 products
    • 0022 Updated all CrashPlan client versions to 3.5.3, compiled native binary dependencies to add support for Armada 370 CPU (DS213j), now updates the new javaMemoryHeapMax value in my.service.xml to the value defined in syno_package.vars
    • 0021 Updated CrashPlan to version 3.5.2
    • 0020 Fixes for DSM 4.2
    • 018 Updated CrashPlan PRO to version 3.4.1
    • 017 Updated CrashPlan and CrashPlan PROe to version 3.4.1, and improved in-app update handling
    • 016 Added support for Freescale QorIQ CPUs in some x13 series Synology models, and installer script now downloads native binaries separately to reduce repo hosting bandwidth, PowerQUICC PowerPC processors in previous Synology generations with older glibc versions are not supported
    • 015 Added support for easy scheduling via cron – see updated Notes section
    • 014 DSM 4.1 user profile permissions fix
    • 013 implemented update handling for future automatic updates from Code 42, and incremented CrashPlanPRO client to release version 3.2.1
    • 012 incremented CrashPlanPROe client to release version 3.3
    • 011 minor fix to allow a wildcard on the cpio archive name inside the main installer package (to fix CP PROe client since Code 42 Software had amended the cpio file version to
    • 010 minor bug fix relating to daemon home directory path
    • 009 rewrote the scripts to be even easier to maintain and unified as much as possible with my imminent CrashPlan PROe server package, fixed a timezone bug (tightened regex matching), moved the script-amending logic from to with it now applying to all .sh scripts each startup so perhaps updates from Code42 might work in future, if wget fails to fetch the installer from Code42 the installer will look for the file in the public shared folder
    • 008 merged the 14 package scripts each (7 for ARM, 7 for Intel) for CP, CP PRO, & CP PROe – 42 scripts in total – down to just two! ARM & Intel are now supported by the same package, Intel synos now have working inotify support (Real-Time Backup) thanks to rwojo’s shim to pass the glibc version check, upgrade process now retains login, cache and log data (no more re-scanning), users can specify a persistent larger max heap size for very large backup sets
    • 007 fixed a bug that broke CrashPlan if the Java folder moved (if you changed version)
    • 006 installation now fails without User Home service enabled, fixed Daylight Saving Time support, automated replacing the ARM symlink which is destroyed by DSM upgrades, stopped assuming the primary storage volume is /volume1, reset ownership on /var/lib/crashplan and the Friends backup location after installs and upgrades
    • 005 added warning to restart daemon after 1st run, and improved upgrade process again
    • 004 updated to CrashPlan 3.2.1 and improved package upgrade process, forced binding to each startup
    • 003 fixed ownership of /volume1/crashplan folder
    • 002 updated to CrashPlan 3.2
    • 001 intial public release

4,048 thoughts on “CrashPlan packages for Synology NAS

  1. Michael

    I seem to have the backup up working again, but the crash plan tray icon is greyed out and states “waiting for login”. When I click on the icon it opens correctly and everything seems to be working correctly. Does anybody know if this is a problem? Thanks

    1. patters Post author

      The tray icon is probably reporting on the status of the CrashPlan engine instance that’s running on your computer. You can disable that completely if you want. See the main post Client Installation section for details how.

  2. Michael

    Thanks, I have just noticed (your very small) paypal button so I have made a small donation for all your hard work & support.

  3. Mathias


    recently got hands on a friends DS215+ and noticed due to the new CPU the architecture naming got extended to “alpine4k” for this model, so you’re packages won’t be listed in the package center.

    Any plans to make ’em compatible to this new(upgraded) arch? Very happy to serve as a guinea pig ;-)

  4. Jon Kensy

    I had posted an issue with CrashPlan on synology failing to start recently. I just applied the 4.3.0-0033 update that popped up on my friends Synology and the unit now connects to my file server and is backing up! Thanks to the devs for this awesome app (and automatic fix)!

      1. Paul

        I do not see my Synology files from the CrashPlan client anymore and therefore I can’t configure backup to the Cloud. It seems that CrashPlan guys changed something in the recent release in the way that some of the technical files are missing or misplaced. As a result no internet instructions “How to” are useful anymore…

      2. Jake

        I’m in the same boat here as well. Even booted up another Windows instance to make sure it wasn’t something wrong there. I can’t see my NAS unit anymore even though the ssh tunnel is active and the .ui_conf file is adjusted.

  5. Eric

    My crashplan instance is stuck at “Waiting for backup”. I tried contacting support but they didn’t have any suggestions since this isn’t an an offically supported configuration. Any tips to debug and resolve? I tried to SSH but I don’t know what where all the logs are and what’s important.

  6. go4saint

    I can backup local computers in the same network and setting the ip adress of my synology.
    How can i backup a remote computer, over the internet, to my synology with public ip adress?

  7. WayneG

    Hello All…

    I’m about to setup my new NAS to run Crashplan. Would someone please be so kind as to let me know whether it is best to run Java 7 or 8..?

    My older NAS is running Java 7 with no issues.

    Thank you all.

  8. domgreener77176

    Hi Patters, i have recently apply the Mac os X El Capitan and in the same time, the DSM 5.2 Update 2 was applied too. the method seems to be not working, but that’s not the truth, the method corrects well and fix the DSM Update damage but in my case my client doesn’t work on my Mac os x client and works fine on my Synology server. This morning a new update for El Capitan has arrived and like a sharm my Crashplan client opens again !. So wait a lot and apply the fix from Mac os X El capitan or … don’t apply this bêta.
    Thank’s a lot for your work Crashplan for Synology is a really good tool.

  9. theodore1982

    Hi Patters,

    just a quick question. Been using your app for a few months and it’s working great. I have 11 different backup sets, each about 300-500 GB.

    Is it a good idea to leave the default scheduling settings for each backup set or could this be optimized? Every backup set has the following options:
    Backup will run: Always
    Verify selection every: 1 days at 03:00

    Is this a good idea? My NAS is online 24/7

    And where are the settings for my backup sets stored? On my client machine or/and on my NAS? Would be a good idea to backup Crashplan as well in case of a disaster!?

  10. antonio

    On the DSM 5.2 the crashplan headless client is running. I followed the steps to install the client on windows including copying the guid from the nas to the.ui_info file. The client still hangs when we start it.

  11. Jon Etkins

    It appears that Code42 have made some more changes over the weekend. On the Windows PC that runs my admin client, I found that had been replaced by a new ui_[username].properties, and both it and .ui_info had been reset to defaults. After copying .ui_info from the NAS, and adding serviceHost=ip.address.of.nas back into ui_[username].properties, the local client was able to resume connection to the headless client on the NAS.

    Oh, and while I’m here, I noticed that the NAS client is timestamping everything one hour in the past – it appears that whatever DST bug was previously fixed, has regressed.

  12. Ethan

    I can’t find the .ui_info file anywhere? I tried a re-install of the client on the Mac but still not there. Do I do a deeper uninstall? Other ideas?

  13. Ronald

    Same problem here on W8.1 pro and W 10 pro
    I’m waiting tot a solution. This was the 3rd time in tal months


Leave a Reply

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

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s