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
  • Since CrashPlan is a Java application, you will need to install one of my Java SE Embedded packages first (Java 7 or 8) if you have not already done so. Read the instructions on that page carefully too.
  • 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.
  • 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. If it still won’t connect, check that the ServicePort value is set to 4243 in the following file:
  • 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"
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

    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

  #extract main archive
  #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
      if [ -f ${OPTDIR}/${FILE_TO_MIGRATE} ]; then
      if [ -d ${OPTDIR}/${FOLDER_TO_MIGRATE} ]; then

  exit 0

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


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

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

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

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

  #fix up some of the binary paths and fix some command syntax for busybox 
  #moved this to from because Code42 push updates and these
  #new scripts will need this treatment too
  find ${OPTDIR}/ -name "*.sh" | while IFS="" read -r FILE_TO_EDIT; do
    if [ -e ${FILE_TO_EDIT} ]; then
      #this list of substitutions will probably need expanding as new CrashPlan updates are released
      sed -i "s%^#!/bin/bash%#!$/bin/sh%" "${FILE_TO_EDIT}"
      sed -i -r "s%(^\s*)(/bin/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}
    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,247 thoughts on “CrashPlan packages for Synology NAS

  1. stevenschon


    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?

  2. Kevin

    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.

    1. Stanthewizzard

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

  3. Mike

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

  4. Robbert 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!

    1. missionmania

      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.

  5. Yves 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.

  6. Wade

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

    1. jirikafka

      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.

    2. Rich

      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?

      1. Kevin

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

        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

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

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

      5. jirikafka

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

      6. Jeff

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

      7. Jeff

        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
        It’s based on Mac users, but you should be able to do the same sort of thing from Windows.


  7. Per

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

    1. jirikafka

      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.

      1. Per

        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

      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.

      1. Per

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

    3. Wade

      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.

      1. Per

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

      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.

  8. jirikafka

    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.

  9. Yves 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/ /var/packages/CrashPlan/target/upgrade/1435726800440.whatevervalue/


    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/ /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/

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

  10. Yves 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/ /var/packages/CrashPlan/target/upgrade/1435726800440.whatevervalue/


    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/ /var/packages/CrashPlan/target/upgrade/1435726800441.whatevervalue/

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

    1. Mike

      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!

    2. George

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

    3. B. 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? :)

      1. B. Goodman

        Over at
        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 ./*/; do mv “$f” “$(dirname “$f”)/”

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

      2. B. 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

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

      What I did, about the numerous folders with the, 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

  11. Denny

    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 to (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 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).

    1. Mike

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

      1. Denny

        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

        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

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

        @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

        @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

      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… ;-)


      1. Denny

        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

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


  12. Mike

    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!

      1. Mike

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

      2. David

        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.(
        at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(
        at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(
        at com.code42.backup.path.BackupSetsManager.access$1600(
        at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(

        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

        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

        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

  13. Greg

    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?

    1. Greg

      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!

  14. Denny

    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.

      1. Denny

        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.

  15. Per

    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?

  16. nickzeff

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

    1. Chermette

      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

      1. Chermette

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


  17. Tazmanian

    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:

    Now, changes to the IP of your NAS.

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

  18. marco

    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

    1. marco

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

  19. Peter

    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+

  20. Sam

    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.

  21. Billy

    My synology fails to even download the .jar files. I tried to extract them from the 4.4.1 Linux install from the Crashplan website but there aren’t any .jar files inside. Does anyone know how to download them manually?

  22. marselaar

    I am done with it. Tried all the steps mentioned. Got the NAS to update the Crashplan, but the client will just not connect. Changed both the NAS and PC .ui_info file, but the package on NAS just stops. And the strange thing, the .ui_info file is changed afterwards (on NAS). I was giving it a final try, since my subscription ends in a month or so. I thank Patters for a year of good backups.

    Does anyone have other suggestions than Idrive? I love the prices, but I just don’t want a gui on port 80 of my NAS.

    1. patters Post author

      These days the upgrades never seem to work. I just wait until Code42 updates the actual main download and then I update the package to pull that. That hadn’t been done when I checked earlier this week, but I’ll take another look in a bit. Hopefully we’ll get this fixed soon.

      1. patters Post author

        Code42 have changed the folder naming inside the main .tgz archive. Also JNA has been updated to version 4.1.0. Their bundled jna.jar now includes an ARM binary. They also made a new requirement to put the NAS IP in the .ui_info file on the client computer. I have the new 4.4.1-0034 package working on Intel, but I need to test on ARM and ideally on PowerPC. It’s late now, so I’ll have to continue tomorrow.

      2. patters Post author

        Ok, so the included ARM doesn’t work for me so I’ve made new ones for armel and armhf architectures. Now I have to make the package able to cope with legacy installations of CPPROe. I also need a willing PowerPC test subject to see whether inotify support (for realtime backup) will actually work now that Code 42 is using a newer libjna.

    2. jirikafka

      I did pretty extensive research before jumping the ship, and the fact ís, if you want to archive around 1 TB of data, iDrive is the only option price / direct Synology support wise.

      1. rich

        I tried IDrive. However when I installed the package it is supposed to give you a url on the nas to go to in order to configure the package. However in my case it didn’t work, the web files were missing.

        When you use IDrive with sinology do you need a business plan? the business rate is a lot higher

      2. jirikafka

        That´s strange. You have to have web station activated obviously, but on mine 1511+ I just installed the app, run it from the top left menu, and that was it. The address is like /IDrive/

        I have regular personal plan.

      3. marselaar

        That’s too bad. I’m trying Idrive now, but it doesn’t seem to backup anything. Job runs, nothing happens. I guess it’s mandatory to use the admin account instead of an account in the admin group, although I didn’t try reinforcing the admin account yet. Besides port 80 this will be another feature I don’t like about Idrive

      4. Robbert Marrink

        I’ve got iDrive running since a couple of days. Runs on port 443 (add an ‘s’ to the http address), I have port 80 closed. Very very good backup speeds and so far all files are being backed up (1TB does take some more time). Check your logfile for the error. There’s a good offer on the Net for 15 bucks a TB the first year.

        I did like Crashplan very much. Set once and forget about it. All precious data backed up. But the frustration due to the update issues again and again, and the time it takes to find a solution, is enough for me now. iDrive is not as sophisticated as Crashplan with continues backup and versioning, but my data is off-site. So far so good.

      5. marselaar

        The right log? I have a log in NAS and a log in Idrive app. Both are empty. Disk space 0%. Pretty sure nothing is backupped. But let’s not discuss Idrive here. This is the Crashplan topic. And that’s not working too!

    3. Kevin

      I don’t quite understand your issue with port 80. I can connect to the idrive account on my NAS remotely using a custom port.

      1. marselaar

        It’s not that you cannot connect, but if you run a website also and you want it to stay on default http port, you and everyone else also will be able to connect to the Idrive part (by default Idrive url). This can only be changed if you can setup Idrive to listen to another port than webstation. Since they also require to use the Admin account (which I had disabled) it’s a bit of a nogo for me, securitywise.

  23. Martijn

    Same feelings here. I was really happy with Crashplan & Patters pacakge, but the number of times I had to update all kinds of obscure config files is getting ridiculous.
    I wonder if the updates from Crashplan are designed to break things…. Thanks Patters for all the hard work, it’s really appreciated, but the updates from Crashplan make it impossible for the users.

    For now I will try Amazon Glacier, it’s a package from Synology, so no more weird problems I hope.

  24. AlexAlex

    Finally got the 4.41 working with the latest suggestions in this thread. Thanks very much guys!
    Unfortunately it looks like I can’t use iDrive with my DS312+ on account of it being a QoriQ processor and neither a x86 or ARM installer will work.
    I can’t remember for the life of me now why I went for the + version of this NAS…

  25. jacques

    I succed to upgrade crashplan to 4.4.1 on 2 NAS ) but the 3rd failed and i don’t know why..
    i noticed that :
    i don’t need to edit, on client ( Linux in my case) , /usr/local/crashplan/conf/ anymore.
    i only need to edit /var/lib/crashplan/.ui_info and change uid and ip ( i didn’t change to the real IP on NAS, i did, only on Linux)

  26. Stanthewizzard

    Find a way to make it work from scratch

    Remove the package through Synology GUI

    Service started

    Update your client (mine is under Windows in 4.4.1

    Then on the server side (on the synology) go to

    You’ll see that the server tries to update to (for me) 4.3.0
    You have to (follow what is on this site

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

    Then restart crashplan on Syno
    I’ll try to update to the next version 4.3.3

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

    You’ll have to do that for each uper version of crashplan till you reach 441 … then the service start

    Go to

    Copy your ID and change it for Windows:


    Good luck

  27. Chuck

    I definitely appreciate Patters doing this. I am going to send a token of support to him in a moment. I guess I will investigate iDrive as well… I am backing up more than a tb so I will likely have to trim back and look for redundant files if I go with iDrive. The funny thing is that I would bet a lot of folks would gladly pay for something between a personal account and a business account for support Synology backup on Crashplan… I know I would be happy to pay it just to avoid the hack-nature this has become (and I agree… it almost feels like Code42 is doing things to make this more difficult…like they are happy to take our money and equally happy to screw with our ability to archive). I was okay with having to fiddle with a Java install now and then and edit a ui properties… but now we see people saying things like “all I had to do was this…” followed by all kinds of bash commands and changing settings on multiple computers just to open SSH tunnels so you can access the terminal to perform the commands. It is comical to see someone write “all I had to do was…” followed by 20 lines of code that you hope you get right lest you royally F*%ck your box.

    Anyway… thanks again Patters… I am going to wait until Code 42 posts the changes to the main file then follow your install package once updated. I will also have to go in an notify Code 42 that this is going to be the last time for me… if they don’t show some move to help us out then I am going to finalize my iDrive subscription…they have made hundreds of dollars off of me so far. It is no longer a cute little thing… I look at the number of people paying them and see a competitor that is supporting the Synology… and maybe iDrive deserves the next few years of my money.

  28. Christopher

    I’ve tried all the upgrade steps multiple times. Starting over from scratch each time. Here’s a screen shot of my log:

    Everything is smooth until getting stuck at 4.4.1

    Does anyone have an idea of what I could be doing wrong?

  29. semperfidelis

    I don’t know if I’m the exception here but after going through the 4.3 update process a couple of weeks ago it’s been pretty stable. It did stop just yesterday and I had to get the UI information again after restarting the Crashplan service but it’s running fine now. I too wish this was a bit more stable but I don’t think it’s the fault of this package creator. I’m very grateful for the work done on this package as it’s very straightforward. This is, after all, a headless client and is primarily designed for Linux gurus (which I am not one) so this package is very appreciated.

  30. jacques

    patters package 4.3.0-0033 ( which correspond to 4.3.0, 4.3.2, 4.3.3, 4.4.0, 4.4.1) is ok with Intel NAS but not with ARM NAS
    After fews restart of crashplan, upgrade to 4.4.1 is ok on Intel Nas but not with ARM (Marvel)

    1. jacques

      mmmm maybe it’s false….. because i succed to upgrade crashplan to 4.4.1 on a marvel NAS….

      for 4.3.0 to 4.3.3, i used automatic upgrade (via gui)
      for 4.4.0 and 4.4.1, i didn’t use automatic upgrade but I used

      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/


      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/

      and it work’s now….


  31. C

    I’ve managed to upgrade by applying instructions on the latest upgrade jar (1435726800441.jar).
    This means extracting the nested jars from the jar and copying them to the lib folder. There will be some duplicates but everything should be okay.
    However in 4.4 for some reason, code42 went from using properties files for logging to using xml. If you don’t have the proper files, Crashplan will start but the log files will be silent.
    You can get them by upgrading your client (Windows in my case) client and copying over the conf/*.xml files to the NAS.

    I find Crashplan upgrade quite annoying – for a backup service, breaking the clients every 2-3 months is not fun especially since one discovers this by accident.
    Thanks to Patters and Chris for their support.

    Just like Chuck above, I have sent an email to Crashplan telling them that enough is enough and if they keep on breaking on each upgrade, I’ll take my money elsewhere.


  32. Chris

    Wow that was a marathon, after hours of scrabbling around I re-installed the original package, then ran through all four upgrades (32,33,40,41), did all the .ui_info things including IP address in the PC version of the file, and eventually found the post above about renaming jna-3.2.5.jar. Now I finally have everything working (well it’s chewing through “synchronising block info” which is about the same!).

    Thanks to everyone above for the hints/tips. Really not impressed with Crashplan right now. Unfortunately I have a DS413 which idrive doesn’t seem to support, so if I want to move it looks like it would have to be Glacier. Will cost more I suspect but at least is a Synology supported package. Have 8 months left on my CP subscription so will see how it goes…….

  33. Singularity

    Yeah, I really don’t care for Code42’s ‘Bugger Off’ attitude about this. I mean I don’t expect them to create a native client for Synology, but they could at least be a little forthcoming and helpful with someone that does (Patters).

    I’ve contacted them a couple of times and each time they’re flat out ‘We don’t care’ which is really off putting considering we’re paying customers, wouldn’t you at least try to accommodate people a little bit? Heck, aren’t more customers better?

    The way things are going I’m afraid they’ll one date put something in place which will totally cut us off, then what?

    Like a couple of you I’m moving to iDrive, so far so good although it’s great having a native client although it doesn’t seem as feature rich as the Mac/Windows one.. Ohh well..

    Patters, just wanted to say thanks for all the time you’ve put into your solution, too bad Code42 are jerks and ruin the party far too often!

  34. Bob Collins

    What happened to the Crashplan package? it is not listed on the site anymore; anyone know where it is?

    1. George

      Two possibilities, it does not list packages that are not compatible with the NAS architecture, in my case I think there is a problem with ARM support in 4.4.1 for my 214se. The other is that patters may have pulled the package while he determines the way to make 4.4.1 work better for everybody (thanks patters)


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