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 CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
  • Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.
  • By default the client is configured to connect to the CrashPlan engine running on the local computer. You will 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 (4243), followed by an authentication token, followed by the IP binding ( means the server is listening for connections on all interfaces) e.g.:

    Copy this token value and use this value to replace the token in the equivalent config file on the computer that you would like to run the CrashPlan client on – located here:
    C:\ProgramData\CrashPlan\.ui_info (Windows)
    “/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for all users)
    “~/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for single user)
    /var/lib/crashplan/.ui_info (Linux)
    You will not be able to connect the client unless the client token matches on the NAS token. On the client you also need to amend the IP address value after the token to match the Synology NAS IP address (this was a new requirement with CrashPlan version 4.4.1).
    so using the example above, your computer’s CrashPlan client config file would be edited to:
    assuming that the Synology NAS has the IP
    If it still won’t connect, check that the ServicePort value is set to 4243 in the following file:
    C:\ProgramData\CrashPlan\conf\ui_(username).properties (Windows)
    “/Library/Application Support/CrashPlan/” (Mac OS X installed for all users)
    “~/Library/Application Support/CrashPlan/” (Mac OS X installed for single user)
    /usr/local/crashplan/conf (Linux)
  • As a result of the nightmarish complexity of recent product changes Code42 has now published a support article with more detail on running headless systems including config file locations on all supported operating systems, and for ‘all users’ versus single user installs etc.
  • You should disable the CrashPlan service on your computer if you intend only to use the client. In Windows, open the Services section in Computer Management and stop the CrashPlan Backup Service. In the service Properties set the Startup Type to Manual. You can also disable the CrashPlan System Tray notification application by removing it from Task Manager > More Details > Start-up Tab (Windows 8) or the All Users Startup Start Menu folder (Windows 7).
    To accomplish the same on Mac OS X, run the following commands one by one:

    sudo launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist
    sudo mv /Library/LaunchDaemons/com.crashplan.engine.plist /Library/LaunchDaemons/com.crashplan.engine.plist.bak

    The CrashPlan menu bar application can be disabled in System Preferences > Users & Groups > Current User > Login Items



  • 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.4.1_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_4.4.1_Linux.tgz"
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
  [ "${WIZARD_VER_441}" == "true" ] && { CPPROE_VER="4.4.1"; EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_430}" == "true" ] && CPPROE_VER="4.3.0"
  [ "${WIZARD_VER_420}" == "true" ] && CPPROE_VER="4.2.0"
  [ "${WIZARD_VER_370}" == "true" ] && CPPROE_VER="3.7.0"
  [ "${WIZARD_VER_364}" == "true" ] && CPPROE_VER="3.6.4"
  [ "${WIZARD_VER_363}" == "true" ] && CPPROE_VER="3.6.3"
  [ "${WIZARD_VER_3614}" == "true" ] && CPPROE_VER=""
  [ "${WIZARD_VER_353}" == "true" ] && CPPROE_VER="3.5.3"
  [ "${WIZARD_VER_341}" == "true" ] && CPPROE_VER="3.4.1"
  [ "${WIZARD_VER_33}" == "true" ] && CPPROE_VER="3.3"
SYNO_CPU_ARCH="`uname -m`"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
[ "${SYNO_CPU_ARCH}" == "armv5tel" ] && SYNO_CPU_ARCH="armel"
[ "${SYNO_CPU_ARCH}" == "armv7l" ] && SYNO_CPU_ARCH="armel"
[ "${SYNOPKG_DSM_ARCH}" == "armada375" ] && SYNO_CPU_ARCH="armel"
[ "${SYNOPKG_DSM_ARCH}" == "comcerto2k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine4k" ] && SYNO_CPU_ARCH="armhf"
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
OLD_JNA_FILE="`echo ${OLD_JNA_URL} | sed -r "s%^.*/(.*)%\1%"`"
TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
#the Manifest folder is where friends' backup data is stored
#we set it outside the app folder so it persists after a package uninstall
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
UPGRADE_FILES="syno_package.vars conf/my.service.xml conf/service.login conf/service.model"
PUBLIC_FOLDER="`synoshare --get public | sed -r "/Path/!d;s/^.*\[(.*)\].*$/\1/"`"
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
  [ "${OLD_JNA_NEEDED}" == "true" ] && tar xJf ${TEMP_FOLDER}/${OLD_JNA_FILE} && rm ${TEMP_FOLDER}/${OLD_JNA_FILE}

  #extract main archive
  #extract cpio archive
  cat "${TEMP_FOLDER}/${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}/
  [ -e ${OPTDIR}/bin/jna-3.2.5.jar ] && cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib/
  if [ -e ${OPTDIR}/bin/jna.jar ] && [ -e ${OPTDIR}/lib/jna.jar ]; then
    cp -f ${OPTDIR}/bin/jna.jar ${OPTDIR}/lib/

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

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

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

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

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

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

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

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

  #increase the system-wide maximum number of open files from Synology default of 24466
  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_441",
            "desc": "4.4.1",
            "defaultValue": true
            "key": "WIZARD_VER_430",
            "desc": "4.3.0",
            "defaultValue": false
            "key": "WIZARD_VER_420",
            "desc": "4.2.0",
            "defaultValue": false
            "key": "WIZARD_VER_370",
            "desc": "3.7.0",
            "defaultValue": false
            "key": "WIZARD_VER_364",
            "desc": "3.6.4",
            "defaultValue": false
            "key": "WIZARD_VER_363",
            "desc": "3.6.3",
            "defaultValue": false
            "key": "WIZARD_VER_3614",
            "desc": "",
            "defaultValue": false
            "key": "WIZARD_VER_353",
            "desc": "3.5.3",
            "defaultValue": false
            "key": "WIZARD_VER_341",
            "desc": "3.4.1",
            "defaultValue": false
            "key": "WIZARD_VER_33",
            "desc": "3.3",
            "defaultValue": false


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

4,618 thoughts on “CrashPlan packages for Synology NAS

  1. joelgerlach

    Did anyone’s crashplan stop running after the latest DSM update? Usually that doesn’t interfere with the crashplan package but now mine will not run anymore. Latest log says: “Synology repairing upgrade in” and that’s it.

    1. bst0n3

      @joelgerlach, I am seeing the exact same problem. CrashPlan stopped and won’t restart. I am currently running v4.4.1-0034.

      The log yesterday (2 November 2015) says:
      Downloading a new version of CrashPlan.
      Installing Upgrade – version 1425726800441.
      Upgrade failed – version 1435726800441.
      Stopping Crashplan.
      Synology repairing upgrade in.
      Synology repairing upgrade in.
      Synology repairing upgrade in.

      Not sure what to do to get it working again…

      1. bst0n3

        BTW, does anyone know if there are ports that I could block on my router to keep CrashPlan from downloading updates to the Synology box?

      2. wholly

        I did the manual repair process as documented for 4.3.0 (requires SSH) BUT there was one big difference this time. it seems that every time it tired to restart after patch it gets stuck and creates another directory. You’ll see that they are all actually the same patch/update. Just do one and delete the rest – there is only one jar file.

        And to avoid falling down the hour of debugging hole I fell into – do not just move the files out of the way, the update process searches the entire upgrade folder for any instance of so you have to either move them outside of the /var/packages/Crashplan/ tree or just delete them. But ONE should be kept to be run on startup as indicated in the repair docs. HTH.

    2. Joe User

      I got the exact same message – uninstalling and reinstalling fixed it for me. PIA, but CrashPlan is still worth it.

    3. Ian

      Yes I get this. I made a comment post here, though I can’t seem to see it… not sure where my posts go. :< Anyway, I posted the version information and I get the same error message as you.

      1. Ian

        I tried remove all but one of the numbered directories as mentioned in the released notes, however mine still refuses to upgrade successfully. It just says “Failed to update ‘Crashplan'”. after I click Next once I agree to the license.

        Any assistance appreciated, thanks.

      2. Dietmar Spehr

        @patterns: Thanks! May I ask what would be the smoothest way to update the packages? Just klick on update on both packages or do I have to do anything else?

      3. patters Post author

        Java can’t be upgraded – it has to be removed completely and re-installed (first stop all Java apps like Serviio/CrashPlan – you can leave them installed though).
        For CrashPlan, as I put in the What’s New notes – it’s best if you stop the package, then connect to your NAS via SSH and delete all apart from one of the subfolders in /var/packages/CrashPlan/target/upgrade
        Do that, then apply the package update and then start it, and it will successfully process the update that was recently pushed by Code42 (4.4.1_59).

      4. Mark

        Just tried the new package update and while the notes said that it would update to the latest version, it just reinstalled version 0035. Could you double-check the update?

    4. ded32

      I confirm the problem, DS1318+.

      First, DS auto-upgraded to version 5.2-5644. CrashPlan worked smoothly.

      Then desktop Crashplan clients stopped to communicate with server headless application.
      I saw several messages in CrashPlan log file that update version 1435726800441 is downloaded and started to install, but install process failed. This process repeated some times.

      Then I stopped the package, and, now every time I try to run it, I see only “Synology repairing upgrade in” in log file and the package does not start.

      1. George

        After I saw the CP upgrade install fail, I carried out the steps I highlighted on Oct 31, and that successfully installed the upgrade and everything is running fine on DS214se and Linix client.

    5. Simon

      Same issue for me I generally wait a few days for an autofix, but am beginning to think this may be one of the times where manual intervention may be required, as it’s now been down since the upgrade occurred 10/31/15

      1. Mike

        I got the same message, but tried starting a second time and it fired right up. It’s been running Ok since.

      2. Mark

        Same here, but reinstalling Crashplan fixed that issue for me. Now my only problem is that I can’t figure out how to get permissions to edit the ui info file on the NAS.

  2. Stevens420

    Now suddenly there is a new issue. The latest package continues running on the DS214+, but the client refuses to open the CP app on boot as it was doing before. I am unable to open the application until I execute a repair install on the application (my important files with the proper editing are read-only, so they are not overwritten). Then I am able to open the application and everything besides the log works as it should. However, on the next boot the application fails to open and requires a repair install again.

    1. stevens420

      Apparently, after removing CrashPlanPROTray from the startup, I no longer need repair installs to start the application. Everything is working again except for the log, which is a sticking point for me.

      1. stevens420

        I spoke too soon. Even though it worked after a reboot yesterday, today it required a repair install before I could open the app. I can’t figure out what is being changed, as all the files appear unaltered, but the repair installation process allows the application to open.

    2. Brad

      @Stevens420, I am seeing the exact same problem. CrashPlan stopped and won’t restart. The log yesterday (2 November 2015) says:
      Downloading a new version of CrashPlan.
      Installing Upgrade – version 1425726800441.
      Upgrade failed – version 1435726800441.
      Stopping Crashplan.
      Synology repairing upgrade in.
      Synology repairing upgrade in.
      Synology repairing upgrade in.

      Not sure what to do to get it working again…

    1. patters Post author

      It looks like version 5 will be a native client (no Java) so it’s probably not going to work unless you have an Intel NAS for the Linux build (which isn’t out yet). Goodbye ARM and PowerPC compatibility.

      1. Singularity

        Well it looks like it’s going to be pre-compiled Java, at least for Mac so who knows what means for the Linux version.. Probably not good overall though..

      2. J.A. Duke

        From what I can see, v5 (5.0.1) is still Java-based. Most of the distributions are including the JRE internally. At least the Mac version of the server and app are Java-based. From what I can tell about the Linux package, I think Java is embedded there as well.

      3. patters Post author

        Ah that’s good news. Presumably Code42 just mean that they have removed the confusing need to install the JRE separately on Mac OS X. So it’s not running without a JRE, just that it’s invisible to the end user. Most Java software seems to be doing this now. To be fair, the Mac OS Java situation was very confusing and must have caused them a lot of support issues. Apple halted any kind of OS-prompted JRE download at version six and left users hanging. Manually installing a newer one is ambiguous and never seems to properly seize the association away from the legacy one.

      4. paul

        Hi Patters,

        Not sure what you’re saying here? Does the Crashplan App stop to work for NAS systems that have ARM processors? Will it still work on my DS710+?

        Either way: I have also a lot of problems since the last upgrade: I cannot connect to my NAS using the desktop client anymore. Also not after a re-install of the desktop client. And if I get it to work, using all tricks I found on this formum, I cannot find my old backup (2.4 TB!) anymore. I only see files on my PC, and nothing from the NAS anymore, even though the IP is OK in the file and the guid is matched in the .ui_info file.

        to be honest: I am lost and don’t know what to do to get access to my data anymore…

  3. HC

    So, we observe that the .ui_info file changes from time to time.. How can that be, and why

    I think the solution may be in the name of the file .ui_INFO. It is perhaps an information file (info from the server to the client(s)), NOT a configuration file.

    Here is one model for what might be happening:

    1) The CrashPlan server starts

    2) The CrashPlan server reads the info in the .ui_info file, port, guid and ip address to listen to

    3) The crashplan server tries to honor what is written in the .ui_info file

    4) If something goes wrong continue at 4a otherwise at 5

    4a) The operating system will not allow the CrashPlan server to listen to the port/ip-address mentioned in the .ui_info file – what to do

    4b) The server selects – somehow I dont know how – a new port number (it probably has a list/interval of them to try)

    4c) If the server is able to set up listening on the new port/ip-address continue at 4x

    4d) Perhaps something similar where the server attempts to use only

    4x) The server is now listening to A port/ip-address, but not the same one listed in the .ui_info

    4y) The server writes a new .ui_info file. If that goes well goto 5 otherwise (perhaps because the file is read only) goto 4z

    4z) YRKKK, we have a listening server but no way to let the clients know where to connect… Whart to do… Hmm perhaps crash/restart untill it works sometime in the future

    5) We are up and running, BUT the .ui_info file may have changed

    The main thing to take away from here is that whenever the server restarts/crashes, the .ui_info file may change!

    Now what to do?

    Well, if we want to run the client on another computer we need to get the .ui_info file from the server some how.

    Here is how I did it.

    1) Create a directory somewhere you can access it. As an example here I use /volume1/data/technical/crashplan

    2) Set up a Scheduled Task (“Control-Panel” – “Advanced-Mode” – “Task Scheduler” – Create – user-defined-script)

    On the General-tab
    Task: CrashPlan copy .ui_info
    User: an admin user here denoted ADMIN_USER (A username with spaces will not work here) (perhaps root – Probably not a good idea) that has access to the /var/lib/crashplan/.ui_info file
    eth0=$(ip addr | grep ‘eth0:’ -A2 | tail -n1 | awk ‘{print $2}’ | cut -f1 -d’/’)
    ( /bin/cat /var/lib/crashplan/.ui_info | /bin/sed -e ‘s/’$eth0’/’ ) > /volume1/data/technical/crashplan/.ui_info
    /bin/chown ADMIN_USER:users /volume1/data/technical/crashplan/.ui_info

    On the Schedule-tab
    Run: Daily
    First run time: 00:00
    Frequency: Every 1 minute(s)
    Last run time: 23:59


    Now after one minute you should find a .ui_info file in the shared technical directory /volume1/data/technical/crashplan/

    Into the share, from the windows machine, add a batch file with the following content (Paths here reflect a local user installation):

    copy \\fs02\data\technical\crashplan\.ui_info “%APPDATA%\..\Local\CrashPlan\.ui_info”
    start “” “%APPDATA%\..\Local\Programs\CrashPlan\CrashPlanDesktop.exe”

    Now to start the client simply run the batch file – and you have got the Client running with the latest .ui_info.

    Many other things may go wrong, but now the .ui_info file is out of the picture…..

    A much better way may be to create a docker image with a linux distribution and run CrashPlan in there via X11 .. Can a docker image get reasonable access to /volumeX .. Hmmm… that will be for another day….

    HC – a Synology newbie on a DS1815+

  4. Mark

    Okay, so how do you change the default IP on the NAS? Mine was set to by default and I couldn’t figure out how to change it. I don’t know terminal commands and when I tried WinSCP and logged in under administrator, it wouldn’t let me edit or overwrite the ui_info file.

    I got lucky and restarting the Crashplan package on the NAS changed the GUID back to a, which let me connect from my remote client but I’d like to know how to fix this next time. I’m sure it must be easy, but googling it didn’t give me any helpful answers. I can confirm for other users that I could not connect using my remote client when the GUID on the NAS was using, but

  5. bjonas

    Finally got 4.4.1 working today, missed something obvious
    Edited “C:\ProgramData\CrashPlan\.ui_info”, overwrote the GUID with the one on the Synology but didn’t update to the IP address of the Synology.
    Also make sure to uncomment and enter the IP address in “C:\Program Files\CrashPlan\conf\”.
    After I did all of this it connected for me.

  6. Ian

    So looks like a recent upgrade to DSM has broken this again. CrashPlan version is 4.4.1-0034 and DSM is 5.2-5644. CrashPlan doesn’t start, and the log shows “I 11/05.15 12:06AM Synology repairing upgrade in” twice.

  7. acn

    I just wanted to let you guys know that I’ve created a forum specifically for CrashPlan installations on NAS systems, namely Synology DS:

    Feel free to use the forum for discussing any CrashPlan setup topic, I hope you’ll find these useful. I found that the two places for getting information about CrashPlan working on Synology NAS, were the [near infinite] comment threads at Patters and Chris Nelson’s websites, and a board based forum felt it could work better for all of us that rely on CrashPlan to backup data.

    I added sections for other NAS systems given I was a QNAP user myself a long time ago and would love to have a place like this back then.

    This is basically a spare time project of mine, by creating my first WordPress based community forum, so features/bugs will be adjusted as we go along.


    edit: I’m also working on Tapatalk support, for those who use it.

  8. BigVince

    Hi. I am trying to understand what the package actually does before installing. Currently I run the Crashplan app on my MacBook, which requires me to leave it on all the time as I am uploading about 750Gb of media. I am also running TimeMachine to my NAS. Will installing the package on the NAS allow me to back up files from my MacBook to my NAS, which then uploads the files to the Crashplan cloud for me?

    Thanks for your feedback! Vince

    1. acn

      With CrashPlan on a regular computer you have two things: the background CrashPlan service (which is what actually controls the backup of your local data) and the Graphical User Interface (GUI). These work separately.

      When you want to access CrashPlan running an headless machine, like our Synology DS’s you’re using just the local GUI to access the remote Service on the NAS.

      Right now, with CrashPlan using the .ui_token files, if you don’t edit that file (or remove it) it will access your local computer’s Service. If you edit it with the remote information of your NAS it will connect to the NAS remote service.

      The other thing is that kind of setup accounts for two computers – hence you need to have at least two CrashPlan Home subscriptions or a Family subscription.

      What I do to avoid doing that is turn on OneDrive on the NAS, for one way sync only, and backup that data from there.

      Hope this helps!
      Have a look at a forum forum I’ve created for crashplan users!

  9. Johnny Bane (@johnnybravobane)


    I was having similar problems when crashplan tried to update last Saturday but I updated the firmware (latest 5.2) yesterday and the client connected. So it went about its synchronisation and analysing my folders as it has done before. The client became disconnected again and I just left it. So rebooted my mac this morning, had to go and change the GUID, Ip address as normal (need to do it after every computer shutdown) and Yeh it connected! However, it looks like my Crashplan central backup is gone. I had over 512 GB backed up and it is telling me that there is only 4.5 GB there now. WFT. Crashplan is merrily scanning and backing up all my folders again because the old backup has vanished. Anyone got any ideas how this has happened and whether I could be at fault here. If I have f*cked up, I don’t want to do it again……..that is if it ever backups fully again. Is the old backup gone for good?

    Thanks in advance,


  10. Chris

    Folks – gotta ask…

    After the update last night to Crashplan 4.4.1-0035 (though not sure the version # changed), Log looks like it’s acting normally, I see it has backed up some files in the last ~12 hours.

    I see a notification that I can update Java to Java 1.8.0_65-0035 / Java 8u65

    Is this something I “need” to do or since it’s working, don’t mess with it yet? With all the problems that seem to be going on, I’d have to jack with this since it seems to be working, though since I’ve got an Intel Atom DS, I may be on borrowed time…???…

  11. Stevens420

    After updating to the latest Crashplan package on my DS214+, opting to SSH into the NAS and delete the erroneous failed upgrade folders instead of removing and reinstalling the CrashPlan package (which would require rescanning the backup), my log works again!

    1. stevens420

      It could be too early to say for sure, but it appears the client PC no longer requires repair installs to launch the CrashPlan app. Sometimes it worked in the past, but every couple days it would require a repair install before the app would open on the client PC. Currently, after the latest package upgrade, the configuration survived a reboot of the client PC, and I note that not only is the log working, but the times listed within are now correct.

  12. boohiss

    Since upgrading to 0035, I noticed the synology crashplan server starting and stopping every 2 minutes. Has anyone experienced this?

      1. boohiss

        Ah, yes you are correct. I thought I fixed it by doing it through the GUI and setting it via the command line but I didn’t realize that it had no effect. Had to set it in a file via ssh into the NAS. Thanks for the pointer! Backups are working again now!

      2. patters Post author

        Generally it’s the client that tends to change its token, so the recommendation is to copy the value from the NAS and apply that to the client, rather than the other way around.

  13. Jean Gionet

    Hi, after following your great tutorial I was able to get Crashplan running on my ds214se with DSM 6.0 beta and was able to get the client on my Windows 10 box to connect to it!
    Now, my problem is; even if I select files or folders to backup the client just says “waiting for backup”. I’ve tried pressing the PLAY/Start button and still no go. It just says to do: 0files. Completed: 0 files.
    am I missing something in my setup?

    1. Scott

      Did you ever get to the bottom of this issue? I am also having the issue. I have uninstalled, deleted all the left over files and reinstalled and still it cant see any files selected.

      1. Jean Gionet

        nope. It didn’t matter what I did it never synced anything even though everything seemed to be working properly. I wasn’t getting any errors that I could see that would prevent it from working.
        I’m looking at other solutions right now, perhaps I’ll check out CrashPlan again. My guess is the NAS I have doesn’t have enough horsepower to run properly. (it only has 256MB of RAM!)

  14. Dale

    Everything is working great, although apparently I still need to run a repair install on the client application every other time or so in order to get the application to open. Any ideas what would cause this?

  15. shareef777

    I’ve given up. Just cancelled my Crashplan service and will look for an alternative. At this point I’ll even consider buying a second/smaller Synology to keep at work for replication.

  16. Richard

    Amazon S3 works natively with Synology. I’m holding out hope that Backblaze will write or at least support a package for their new B2 service.

  17. Greg

    Is there a reason the ui_info file keeps changing? I upgraded the latest package and ran the ui_info command on the NAS and put that info in the ui_info file. Every couple of days I log into the client and it tries to back up my local laptop instead of the NAS. When I look at the ui_info file, it is different than the server. Any clue on why this keeps changing on my local machine?

    1. Greg

      I am going to post this again. Issue I am having is the ui_info file on my client keeps changing and the client keeps pointing to my laptop vs the NAS. Everytime it does this, CrashPlan wipes out 700GB of backup and I have to start all over again. What is causing this? My NAS is greyed out in backup sets and my laptop name is active. Please help.

      1. acn

        You don’t have to uninstall CrashPlan and restart the backup, as it is still running on the NAS. The .ui_info file changes for reasons no one knows exactly, but apparently it’s how Code42 wants it to run.
        In any case, you need to correct the Windows client .ui_info data, which is the one that tends to change the easiest.

        ssh the NAS and use ‘cat /var/lib/crashplan/.ui_info’ to get the new info. Copy and paste it onto the windows client .ui_info file and it should run just fine. You may also try to set .ui_info as readonly but I don’t know if it actually does anything useful.

        CrashPlan forum

      2. ahershler

        When you installed the CrashPlan client on your PC, it also installed the CrashPlan Backup Service on that same PC. This is the process that actually performs the backup (the client is just the GUI). Whenever the service on the PC restarts, it seems to rewrite the .ui_info file on the PC. If you do not use CrashPlan to actually directly back up your PC (for example you backup your PC to your NAS using anything else except CrashPlan), and the only reason you installed CrashPlan on the PC is so that you could use it as a client to control the backup service running on the NAS, then you should disable the CrashPlan Backup Service on your PC.
        To disable the service, open up Services from Administrative Tools; select and double-click CrashPlan Backup Service; click the Stop button to stop the service; next to Startup type select Disabled so the service will not run again; click OK and close Services. This will prevent the CrashPlan Backup Service from restarting.

  18. jbrerhel

    I am one of the ones who is giving up on CrashPlan on my Synology DS 212j. I just can’t keep investing the time. Switched to the Amazon Glacier package, and a couple weeks later, everything is uploaded and requires zero attention. I thought I’d miss the features of CP, but I haven’t yet…

      1. frank

        Im on 5.2 but I guess its my 716+ (I could see it with my previous 214play). Any other way to download?

      2. patters Post author

        I would also like you to run a few tests on your system, as I think I may be able to enable hardware transcoding on it.
        Can you run this from an ssh session:
        ls /lib/

        If that library is present then please run a special build of FFmpeg I have compiled:
        cd /volume1/@tmp
        mkdir test
        cd test
        tar xvJf serviio1.5-native-braswell.tar.xz
        ./ffmpeg -hwaccels

        Please post the resulting screen output. Thanks!

      3. patters Post author

        DS716+ has a new cpu architecture designation. Can you try again from the repo? You should see Java 8 and Serviio now. If they are visible, let me know and I’ll add support for the CrashPlan package too.

      4. patters Post author

        Ok, you should see CrashPlan now.
        Would it perhaps be possible for me to have remote access to your NAS to try and get the hardware transcoding support included into Serviio?

  19. Ian J

    Is there any other app other than Crashplan that would allow me to back up locally to a drive? I used to backup to the CP cloud under a prior deal but never renewed that and so I now backup to an external drive. CP has been great but lately its becoming harder and harder to achieve what I want.

  20. Dale

    After several days, I’ve noticed that every OTHER time I reboot the client machine, Crashplan (which is part of the startup) fails to load, requiring a repair install before it will open. The important files with modifications to point to the NAS are set to read-only, and are not affected by the repair installation. The times that Crashplan opens without issue, I notice that the Crashplan service is also running, but the times it fails to open, I notice the service is stopped. After the repair install, the app will open, but the service remains stopped, so I doubt the problems are related to the service itself. But I can’t figure out what if anything is being altered during the repair installation process. A quick perusal of the crashplan folders show the folders as being modified during the repair install, but the files within remain unmodified. Perhaps there is some other program cache being cleared?

  21. JT

    Just upgraded to the latest version on my Synology DS211 and it appears my backupArchives have been deleted. My systems appear to be doing full backups back to my Synology and my @appstore/CrashPlan/backupArchives folder is sitting at ~3GB right now.

    Anyone else run into this?

  22. AJ Kerrigan

    I am incredibly grateful to patters for creating and maintaining these packages over the years, but they’ve been pretty fragile for me (through no fault of his). I told myself I’d give Docker a shot the next time this CrashPlan died on me, so I put together a script to manage a CrashPlan container on a Synology NAS. It’s definitely not for everybody, but if anyone else is interested in trying to use or test it, feel free to check out I honestly don’t know if this will be of use to anyone but me, but I’m throwing it out there in case it is.

  23. Mattzed


    I am new there and very interested in CrashPlan on DSM.
    Unfortunately I am stopped at the first setting: when I try to add the repository, I am not able to receiving this message: “incorrect location”.

    Would you have an advice?

    Thank you.

    1. patters Post author

      Maybe try changing your NAS DNS server manually to (Google DNS) and see if that helps? It might be that your ISP’s DNS has got a corrupt IP for my domain or something.

  24. frank

    Thanks for building a 716+ version! Downloading and installing it now… I’ll let you know how it runs and if there are any tests you would like me to do, just let me know

    1. patters Post author

      It’s no different to the regular Intel version – just that it now detects braswell as a model definition. I would definitely like your help to get an optimized Serviio package with hardware transcoding going though. I’ll contact you directly…

  25. Pingback: Backup: sådan sikre du bedst dine data | TechSyd

  26. Bruce

    Starting yesterday, my CrashPlanProE client on an RS3614RPxs has started having issues. Have not performed any updates to DSM or CP in the mean time. Seeing two things happening:

    1) at some point the info in the .ui_info file changes both the port (from 4243 to 4253) and the “instance id”
    2) Package is constantly stopping and restarting.

    This same unit ran CP fine for a couple of weeks and we have a second identical unit that is not displaying the same symptoms.

    I have tried uninstalling the CP package and reinstalling, with no effect. Any assistance is appreciated.

    1. Bruce

      After reading through some more of the previous posts it sounds like number 1 is at least somewhat normal (not sure about the port changing still) although I haven’t seen it on my other unit.

      Number 2 on the other hand is a major issue.

  27. Dale

    Apparently CP is rolling out a new update again. My log says that it attempted to download a new version of CrashPlanPRO, then Installing upgrade version 1435726800450, which is followed by the upgrade failing. I wonder if this is why I need to repair install to get the app open due to changes from an incomplete update.

    1. patters Post author

      And by sheer coincidence my own system seems to be one of the last to get these updates each time, so I can’t even work on a fix until mine’s borked.
      This is really getting tedious.

      1. stevens420

        That does seem inconvenient. Based on prior experience, I’d say we have a few days before the update succeeds in which case the headless client will stop working. CrashPlan PRO still has the same version for download (4.4.1), so they have yet to put out a new executable for installation, but based on the previous updates, at some point they will put up a new installer. So there is still time to work on a fix before it becomes a major problem, but I agree this is getting tedious. If only there was some way to put a stop to the forced updates.

      2. patters Post author

        Based on prior experience it’s quite a while (weeks) before they update the installers. Thing is, I can’t figure out why the update is failing if my own system hasn’t received the update. And how come every single time they change how the update works in some subtle way that breaks it.

  28. Ian

    Has anyone had their crashplan show it’s running perfectly fine but under the folders to backup it shows that there is no data in the folders selected for it to backup even though there is about 6TB worth of data combined in those folders.

  29. eagleqc

    I got Crashplan working again using the Chris Nelson method before the latest update from Patters. Can someone tell me whether I still need to delete all but one of the failed numbered upgrade subfolders before updating to the latest version of the package? Or can I just go ahead?

  30. Flavio Endo

    After Crashplan going through all the Chris Nelson method again my Crashplan is up and running again.
    I have also updated the DSM to 5.2-5644 from 2015/11/12.

    Note that the file name for this CP version is 1435726800450_264.jar
    That is the name you have to use on the commands from Chris.

    Also, note that I have done the last command

    ls -l /var/packages/CrashPlan/target/upgrade/1435726800450_264.*
    mv /var/packages/CrashPlan/target/upgrade/1435726800450_264.whatevervalue/ /var/packages/CrashPlan/target/upgrade/1435726800450_264.whatevervalue/

    only on the lastest folder.. the other ones that I found, I simply deleted them (the older folders).

    I think this is ok.

    The last time I went folder by folder and changed the “”… that was a hassle.

    Can anyone else validate if this is ok? For me it was ok.

    Thanks Patters and community!

    1. Flavio Endo

      OK.. I guess this answers myself :-)

      from the changelog:
      …alternatively please delete all except for one of the failed upgrade numbered subfolders in /var/packages/CrashPlan/target/upgrade before upgrading. There will be one folder for each time CrashPlan tried and failed to start since Code42 pushed the update.

      Sorry for not seeing this before.


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