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 one that’s typically difficult to install on a NAS – therefore an obvious candidate for me to simplify into a package, given that I’ve made a few others. I tried and failed a few months ago, getting stuck at compiling the Jtux library for ARM CPUs (the Oracle Java for Embedded doesn’t come with any headers).

I noticed a few CrashPlan setup guides linking to my Java package, and decided to try again based on these: 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, complete with download links for the additional compiled ARM libraries. 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 picked out the few generic binaries that were needed (bash, nice and cpio) directly from the Optware repo.

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

Aside from the challenges of getting the library dependencies fixed for ARM and QorIQ PowerPC systems, there was also the matter of compliance – 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. It took a lot of slow testing, but I managed it!

CPPROe package info

My most recent package version introduces handling of the automatic updates which Code 42 sometimes publish to the clients. This has proved to be quite a challenge to get working as testing was very laborious. I can confirm that it worked with the update from CrashPlan PRO 3.2 to 3.2.1 , and from CrashPlan 3.2.1 to 3.4.1:




  • This package is for Marvell Kirkwood, Marvell Armada 370/XP, Intel and Freescale QorIQ/PowerQUICC PowerPC CPUs only, so please check which CPU your NAS has. It will work on an unmodified NAS, no hacking or bootstrapping required. It will only work on older PowerQUICC PowerPC models that are running DSM 5.0. It is technically possible to run CrashPlan on older DSM versions, but it requires chroot-ing to a Debian install. Christophe from has recently released packages to automate this.
  • In the User Control Panel in DSM, enable the User Homes service.
  • Install the package directly from Package Center in DSM. In Settings -> Package Sources add my package repository URL which is
  • You will need to install either one of my Java SE Embedded packages first (Java 6 or 7). Read the instructions on that page carefully too.
  • If you previously installed CrashPlan manually using the Synology Wiki, you can find uninstall instructions here.


  • 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.
  • CrashPlan is installed in headless mode – backup engine only. This is configured by a desktop client, but operates independently of it.
  • The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 512MB). This can be overridden in a persistent way if you are backing up very large backup sets by editing /volume1/@appstore/CrashPlan/syno_package.vars. If you’re 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 Intel models which come with 1GB RAM and can be upgraded to 3GB very cheaply. RAM is very limited on the ARM ones. 128MB RAM on the J series means CrashPlan is running with only one fifth of the recommended heap size, so I doubt it’s viable for backing up very much at all. My DS111 has 256MB of RAM and currently backs up around 60GB with no issues. 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.
  • As with my other syno packages, the daemon user account password is randomized when it is created using the openssl binary. DSM Package Center runs as the root user so my script starts the package using an su command. This means that you can change the password yourself and CrashPlan will still work.
  • 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.
  • The first time you run the server you will need to stop it and restart it before you can connect the client. This is because a config file that’s 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.
  • Once the engine is running, you can manage it by installing CrashPlan on another computer, and editing the file conf/ 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.:
    On Windows you can also disable the CrashPlan service if you will only use the client.
  • 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’re trying to troubleshoot an issue you will need to use an SSH session to inspect the two engine log files which are:
  • 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). You will need to wait several minutes in the event of this happening before you take action, because the update script tries to restart CrashPlan 10 times at 10 second intervals. After this, you simply start the package again in Package Center and my scripts will fix the update, then run it. One final package restart is required before you can connect with the CrashPlan Desktop client (remember to update that too).
  • After their backup is seeded some users may wish to schedule the CrashPlan engine using cron so that it only runs at certain times. This is particularly useful on ARM systems because CrashPlan currently prevents hibernation while it is running (unresolved issue, reported to Code 42). To schedule, edit /etc/crontab and add the following entries for starting and stopping CrashPlan:
    55 2 * * * root /var/packages/CrashPlan/scripts/start-stop-status start
    0  4 * * * root /var/packages/CrashPlan/scripts/start-stop-status stop

    This example would configure CrashPlan to run daily between 02:55 and 04:00am. CrashPlan by default will scan the whole backup selection for changes at 3:00am so this is ideal. The simplest way to edit crontab if you’re not really confident with Linux is to install Merty’s Config File Editor package, which requires the official Synology Perl package to be installed too (since DSM 4.2). After editing crontab you will need to restart the cron daemon for the changes to take effect:
    /usr/syno/etc.defaults/rc.d/ stop
    /usr/syno/etc.defaults/rc.d/ start

    It is vitally important that you do not improvise your own startup commands or use a different account because this will most likely break the permissions on the config files, causing additional problems. The package scripts are designed to be run as root, and they will in turn invoke the CrashPlan engine using its own dedicated user account.
  • If you update DSM later, you will need to re-install the Java package or else UTF-8 and locale support will be broken by the update.
  • If you decide to sign up for one of CrashPlan’s paid backup services as a result of my work on this, I would really appreciate it if you could use this affiliate link, or consider donating using the PayPal button on the right.

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_3.6.4_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_3.6.4_Linux.tgz"
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
  [ "${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}" == "armv5tel" ] && SYNO_CPU_ARCH="armle"
[ "${SYNO_CPU_ARCH}" == "armv7l" ] && SYNO_CPU_ARCH="armle"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
cat /proc/cpuinfo | grep "Comcerto 2000" > /dev/null && SYNO_CPU_ARCH="armhf"
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
TEMP_FOLDER="`find / -maxdepth 2 -name '@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 ()
  #make sure engine is stopped
  /var/packages/${SYNOPKG_PKGNAME}/scripts/start-stop-status stop
  exit 0

postuninst ()
  if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
    source ${SYNOPKG_PKGDEST}/syno_package.vars

  if [ "${LIBFFI_SYMLINK}" == "YES" ]; then
    sed -i "/^LIBFFI_SYMLINK/d" ${SYNOPKG_PKGDEST}/syno_package.vars
  [ -e ${OPTDIR}/lib/* ] && rm ${OPTDIR}/lib/*
  #delete symlinks that no longer resolve
  if [ ! -e /lib/ ]; then
    [ -L /lib/ ] && rm /lib/
  if [ ! -e /lib/ ]; then
    [ -L /lib/ ] && rm /lib/
    #repair symlink on DSM 5.0 now that it's included by default
    ln -s /lib/
  #remove firewall config
  if [ "${SYNOPKG_PKG_STATUS}" == "UNINSTALL" ]; then
    /usr/syno/bin/servicetool --remove-configure-file --package ${SYNOPKG_PKGNAME}.sc > /dev/null

  #remove legacy daemon user and homedir
  DAEMON_USER="`echo ${SYNOPKG_PKGNAME} | awk {'print tolower($_)'}`"
  synouser --del ${DAEMON_USER}
  [ -e /var/services/homes/${DAEMON_USER} ] && rm -r /var/services/homes/${DAEMON_USER}
 exit 0

preupgrade ()
  #make sure engine is stopped
  /var/packages/${SYNOPKG_PKGNAME}/scripts/start-stop-status stop

  #if identity from legacy package version exists migrate it
  DAEMON_USER="`echo ${SYNOPKG_PKGNAME} | awk {'print tolower($_)'}`"
  if [ -d ${DAEMON_HOME}/.crashplan ]; then
    mkdir -p ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
    mkdir -p /var/lib/crashplan
    mv ${DAEMON_HOME}/.crashplan/.identity /var/lib/crashplan/
    chown -R root:root /var/lib/crashplan/

  #if identity exists back up config
  if [ -f /var/lib/crashplan/.identity ]; then
    mkdir -p ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf

  #if config data exists back it up  
  if [ "${CONFIG_MIGRATION}" == "true" ]; then
      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}

    #fix permissions on migrated settings and manifest from legacy package versions which used a daemon user account
    chown -R root:root ${SYNOPKG_PKGDEST}
    if [ -f ${SYNOPKG_PKGDEST}/conf/my.service.xml ]; then
      MANIFEST_FOLDER=`cat ${SYNOPKG_PKGDEST}/conf/my.service.xml | grep "<manifestPath>" | cut -f2 -d'>' | cut -f1 -d'<'`
      chown -R root:root ${MANIFEST_FOLDER}

    #tidy up some legacy settings
    sed -i "/^CRON_SYNOPKG_PKGNAME/d" ${SYNOPKG_PKGDEST}/syno_package.vars
    sed -i "/^CRON_SYNOPKG_PKGDEST/d" ${SYNOPKG_PKGDEST}/syno_package.vars
  exit 0


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

TEMP_FOLDER="`find / -maxdepth 2 -name '@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 until the above changes are made so we need to
  #find it and start it, if it exists
  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
    cd ${SCRIPT_HOME}
    exit 0

  #updates may also overwrite our native binaries
  [ -e ${OPTDIR}/bin/ ] && cp -f ${OPTDIR}/bin/ ${OPTDIR}/
  cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/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
  if [ "${SYNO_CPU_ARCH}" != "x86_64" ]; 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"
    #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"
    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



  • 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’s 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
  • 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
About these ads

2,898 thoughts on “CrashPlan packages for Synology NAS

  1. Mike

    Anyone else having issues with the client randomly disconnecting? I’m running 3.64-0028 on a DS415+ with the Patters embedded Java 7 (7u71). I have 2GB allocated in syno_package.vars (I’ve upgraded my DS415+ to 8GB memory). I can remote connect the client and it runs for a random period of time and then just quits. There are zero entries in the engine_error log. I have multiple backup sets due to the size of my backup.

    1. Eric Henson

      I’m having this issue as well. The service restarts regularly, and the client closes itself whenever the service restart occurs.

    2. Marcus

      Mike, I’d like to know what memory module you bought. If possible a link to the item in the online store where you bought it. I’m going to buy a DS1815+ and would like to upgrade the memory to at least 8GB. Thanks!

    3. Mike

      Looks like this is a memory issue. I’ve upped the memory allocation in sync_package to 3072M and the client has been running successfully for over 1hr with no disconnects.

      1. Eric Henson

        Mike, I’d love to try this on our unit. Could you please direct me to where you changed that setting? I was unable to find any file with that name on the Synology device after poking around on the file system, but perhaps my Linux-fu is weak today.

    4. Mike

      Hi Eric

      You need to ssh or telnet into your box, and the file is /volume1/@appstore/Crashplan/syno_package.vars

      You’ll see an entry for USR_MAX_HEAP which you can modify. (Just make sure the line isn’t commented out, i.e. has a # at the beginning).

      You’ll need to restart the CrashPlan package on your box for it to read the new config.


      1. Eric Henson

        Mike, thanks so much! I’ve found the file (I guess my Linux-fu was indeed weak), and I’ll experiment with this. Might have to make a trip to get another RAM module, too.

      2. Eric Henson

        Mike, thanks very much for the tip. I wish I could report success, but uncommenting and bumping it from 512 to 1024 (our device presently only has 2GB RAM) produced no change in the resetting behavior.

    5. Mike

      If you’ve not already, I’d also try breaking your back up into sets. One strategy I also used when I was tight on memory was to bump up the memory allocation in increments until the disconnections happened. Then I’d set the backup sets to run at specific times overnight when the box wasn’t in use, and use the scheduling options in DSM to stop & start the CrashPlan package. That way I could allocate most of the boxes memory without affecting daily activities.

      1. Chris (@g0afr3ak)

        Having the same issue here. My DS 412+ has 2 GB of RAM. Before updating to DSM 5.1 everything was working perfectly, heap size for 1024MB was enough for almost 1.000.000 files. Now it’s crashing constantly. I tried to set the heap size to 2048MB, then the backup is running fine again, but the RAM usage on my DS is 80-90% all the time affecting the overall performance, so this is not a choice. I’m removing some directories from the backup now, hopefully reaching a stable state with 1024MB heap size again.
        I’m really wondering, why this happened after the update to DSM 5.1, as before that everything was smooth and easy…

  2. Jeff Mason

    I’ve read the thread pretty closely, but couldn’t find any updates on the “High iSCSI Utilization” with in my case DS412+, CrashPlan (headless on DS412+). I definitely have high, 100% iSCSI utilization when CrashPlan is running. As soon as I shit it down utilization goes back to 1-2%.

    Any updates that I missed?

  3. jeffmmason

    I have read and am following this thread concerning the “High Volume / iSCSI Utilization” with CrashPlan and Synology NASs, specifically DS 412+.

    I haven’t come across a solution and was wondering if I’ve missed anything concerning a solution, fix, update, ect?

    Configuration for future use:
    DSM 412+
    I haven’t come across a solution and was wondering if I’ve missed anything concerning a solution, fix, update, ect?

    Configuration for future use:
    DSM 5.1-5004
    CrashPlan 3.6.4 (headless on synology DS412+ according to PC LOAD)

  4. goslow2gofast

    Well, I followed the process and was able to get CrashPlan installed and running on my Synology DS413 on 11/08/2014, nd configured it from my Windows client fine, and had it backing up a modest test folder of some pictures. It ran for several days, but the last log entry is from 11/11/2014 saying “scanning for files completed”. I noticed today that it’s status was “stopped” so I tried starting it. It flips to running for a second or two, then goes back to stopped. No entries in its log file. Any thoughts, I didn’t make any changes to the NAS during that time.


  5. Chris (@g0afr3ak)

    Update to my previous post: The problem with the restarting client has to some kind of generic problem. I drastically reduced my backup directories to 5 with about 400.000 files, and still with 1024MB heap size the client is crashing all the time. Again, before the DSM 5.1 update I was backing up almost 1.000.000 files with 1024MB heap size!
    Another test: Heap size 1500MB. Now it’s working again, but my RAM usage is at 84% constantly. I don’t think this is an acceptable condition on the long term…

    Anyone has any suggestions why this is happening and how I can reduce the RAM usage of the client? Does the Java version (6-7-8) affect the RAM usage? I’m currently using version 1.8.0_06.

  6. Michael

    Hi: I have used CrashPlan on my PC and Macbook for a couple of years. I wanted to use it for my Synology as well. It is successfully installed and running on the NAS – but when I change the on my PC client to add the Synology IP address, it seems that I can no longer back up my PC? Isn’t it possible to have both? Any assistance appreciated.

  7. Alexandre

    I got a problem with crashplan. All is working on 4 NAS. But on a DS413, crahplan never worked. I never found the package in repo and i needed to install it manually.

    Then i can access crash, configure it, all is running well but when it finish to scan the files to save the backup never start. it s waiting for connection ( i test on crashplan server or another computer).

    Do i need to check a port is open or something like that ?

  8. John

    I would like to know how to re-install the previous version also, when i try the old install package was not available online. The crashplan packages are great and have come to rely on them, great work and thanks Patters.

  9. Hal Sandick


    First, Thanks all your work on this.

    I installed crashplan using your instructions about 17 months ago. the version on my server is 3.6.3. Now the java packages are showing up but not the crashplans ones. I tried deleting the link to your packages, rebooting and re entering it. Still only your java packages. i’m running the most recent version of dsm, DSM 5.1-5004,and have a ds213+

    any suggestions?


    1. Brad Sieve

      I could be wrong but last I heard (and have no success myself) getting the 213+ (powerpc) to work with the newest crashplan. There are comments about it before in the line and no updates I have seen,

  10. Tiestor

    I was running Crashplan on a DS414, and it worked perfectly and I loved it. After upgrading to DSM 5.1 and Crashplan 3.6.4 it stopped working properly, it’s starting and stopping after a few minutes. When I try to go back to Crashplan 3.6.3 by installing crashplan3.6.3-merged-0027.spk I get the error: “There was a problem downloading crashplan-native-armv7l.tgz from the official download link, which was “” Alternatively, you may download this file manually and place it in the ‘public’ shared folder.”

    Unfortunately, that file is removed so I am not able to restore the old working version of Crashplan, is there a way to resolve one of these issues to get back to a working version of Crashplan? Thanks in advance and I love your work.

  11. Enjoy


    I uninstalled version 3.6.3-0028 because did not work (I’ve written about this before).
    I downloaded version 3.6.3-0027 (crashplan3.6.3-merged-0027.spk) and I can not install.
    Also, at the moment I do not have CrashPlan on Synology :( Any idea?

    Could not update “CrashPlan”.
    There was a problem downloading crashplan-native-armv7l.tgz from the official download link, which was “”
    Alternatively, you may download this file manually and place it in the ‘public’ shared folder.

  12. Enjoy

    wOw :) uninstalled the latest version (after updating 3.6.3-> 3.6.4) and installed again 3.6.4 and now it works :)

    1. Eric Henson

      Congrats! Hopeful after hearing of your success, I tried reinstalling as well. It didn’t seem to solve the problem, but I then also doubled the NAS’s installed RAM from 2GB to 4GB and increased Java’s heapsize from 512MB to 2GB, which has allowed us to resume our backup with no more crashing!

      I don’t know about the long-term viability of this fix, but I’m just happy to be backing up again.

  13. ed

    Upgrading tonight to Synology DSM 5.1, Intel architecture DS1512+

    Using either the package center, or trying to use the spk from your package area, I get a ‘This package does not contain a digital signature’ error, and the update fails.

    1. ed

      That was quick resolution.

      There’s a new, or new to me anyway, Trust Level option in package center, General tab. Setting that to allow anyone allows the update to take. However, the update didn’t run. Not sure why. After 3 failed attempts I tried the combined package from your package center and manually installed. That ran, and backup complete. Go figure. Will Synology ever quit playing games on this package and just finally support it already. Without it, I’d just as soon toss this NAS in the trash.

      1. ed

        Interesting, come to notice it won’t run any longer, hasn’t since 4 days back when it ran successful the first time, backed files up, and now no longer runs. Trying to downgrade to prior version.

  14. Sid Mautte

    Anyone have any experience getting this to work with a pair of DS412+ configured in an HA cluster? Will the install via the primary interface cover both? Does the Crashplan need to be for 1 system or multiple to cover this scenario?

  15. Richard

    I installed your package on a 1812+ with 2Gb of RAM and it has been running great for about a week but since I just rebooted my NAS, the package won’t stay running, it says it started but then stops again almost immediately. I’ve tried reinstalling Java and rebooted again but it still won’t run – any ideas for what else to check next?


  16. Richard

    Here is the message in the log file

    Moss-Nas> cat engine_output.log
    [11.19.14 17:24:37.780 INFO main root ] JVM temp directory /var/@tmp does not exist!

    I simply went to that directory and did ‘Mkdir @tmp’ and now it stays running.

    1. John B.

      You could Instead just update the bin/run.conf file to point to a real existing @tmp folder,
      e.g. change “” to “”

      The real temporary folders are emptied on restart.

      1. bushwhackers

        A heads-up if anyone uses Richard’s solution.

        Looks like on re-boot, the @tmp directory you add at /var gets nuked at re-boot.(John B.’s comment now makes alot more sense)

        Have not tried updating the bin/run.conf file per John B.

  17. Stephen Cranfill

    Apologies if this has been discussed elsewhere, but I can’t find it if it has been.

    In troubleshooting an issue I was having, I uninstalled/reinstalled the Crashplan Pro package and am now getting the message:

    destination unavailable — you have an older version

    This is a freshly installed 3.6.4 package and the GUI install on my machine is also running 3.6.4. DSM is 5.1-5004. Anyone else seeing this?


  18. Stephen Cranfill

    As an addendum to this…. I attempted to revert to 3.6.3 without success, so I uninstalled 3.6.3 (I couldn’t get it to run). I then reinstalled 3.6.4 and it prompted me for a username and password as if the configuration has been removed (which I had tried to do manually earlier by renaming CrashPlan in /volume1/@appstore/). After re-entering that, all seemed to be well in the world again–no more “older version” message. Fab!


  19. Nicolas


    I have looked a bit a this topic because since the latest updates i have a constant crashplan restarting, making it unable to complete a backup.

    It’s running on a DS1010+ with 1gb ram. Crashplan was running fine but one day we noticed it had crashed. i couldn’t see the crasplan package on the package center ( old dsm version ) so i made all the DSM updates and reinstalled the latest crashplan package.

    I have a large set of files ( > 1.000.000 and more than 1Tb of data ). If i disallow the backup, it succeed the scanning and wait. But when it try to backup, the service restart after ~3 minutes…

    Any idea on how to fix this ?

    1. John B.

      Break your backup into small backup sets.
      Start with a single small set and keep reducing it until it works. Only then add a single extra set and repeat as before.
      I’m not sure what a sweet-spot is for you, but I have 6 sets. One of them contains 25k files at 81GB (i.e. large number of files) and another one with only 363 files but at 1.2TB (i.e. few but large files).

      1. Eric Henson

        I pushed off my similar issue by adding more RAM to the NAS, but I’m sure I’ll be dealing with this again one day as the backup size grows.

        John, I’d like to try out your backup sets solution, but I have a question about it. I presently have one very large set (~700,000 files at 1.8TB), and it’s backed up 70%. If I enable sets and then break this one up into multiple sets, am I going to have to restart the upload, or is CrashPlanPro smart enough to recognize it as duplicate data?

      2. John B.

        @Eric – there is a “Data de-duplication” setting in the Advanced backup settings.
        Personally, I’m using all types in my backup sets (Minimal, Full or Automatic), depending on what my needs are and what I am willing to wait for.
        I’m not sure what happens when you move a folder from one set to another, but you could test it with a smaller number of files.

      3. Eric Henson

        @John – Thanks for the encouragement to try! I broke my massive backup set into several smaller ones, and after a quick resync, it picked up right where it left off, with no progress lost! Disabling de-duplication (this is lots of archival data that doesn’t change) sped the process up from 2.5 Mbps to 15.0 Mbps. Hooray!

      1. Nicolas


        Thanks for the advice, i will test that right now.
        About dataset. If i remove a folder from one dataset and add it in an other data set, will i loose the versionning files infos of old backups ? the popup when un-selecting a folder is kinda scary about that.

  20. Johnny B


    I have a DS213j which was working sweetly with crashplan on 5.0. I have tried lots of the suggestions above to no avail (tried to install an older package, uninstalling, installing, upgrading the crashplan PC client). I am now running the latest version of the headless client, JAVA 7 package and PC client. The engine basically stops a few minutes after starting and the log file is empty of any information. The front end client cannot connect I have only 512 mb of RAM and its not easy I believe to increase that. Is this the end of the road. 16 months left on a 2 year subscription. Ah well. if there any updates on this situation I would love to hear it.


  21. Lonny

    I’m Testing this out on a rackststion with the latest dsm and 16Gb ram. When I assign more than 3.5gm ram to the java heap setting then Crashplan will not start. I’m thinking there might be a 64bit java needed. Anyone have any experience with this? I have about 12TB to backup.

  22. Pondo

    I see only the ProE version on the Repo, am I doing something wrong? Thanks for taking the time to make these work!

  23. Marcel

    Hi there … are there any news regarding the PPC-problem? … I own a DS213+ and Crashplan is still not running … :-(

    Thanks for your work!

    Best regards

  24. marc

    I own also a DS213+ which runs on a PowerPC with DSM 5.1. So the newest version of your package (3.6.4 0028) does not run. It always stays in the mode “waiting for backup”.

    So I tried to downgrade to 3.6.3 0027 which installs without any errors. But after starting – stopping – restarting it does not download and install the upgrade to 3.6.4 from the crashplan server. Any idea why this does not happen? Last time I tried this (some weeks ago) it worked perfectly … :-(


  25. Eric Henson

    Okay, I’m past my wit’s end, and lapsing into despair. Adding RAM, increasing the heapsize, and breaking up the data sets worked for a while, but we threw some more data onto the NAS, and it’s back to crash loops.

    I further divided the backup sets such that no set is over 1TB (problems seemed to previously begin around 1.9TB or so), but now there’s no change. The client crashes out and restarts during the initial scan, and never makes it to backing up files.

    I’m out of ideas, and I’m ready to throw this box out a window. Does anybody have any ideas for a desperate man?

    1. Eric Henson

      Further research suggests that CrashPlan requires about 1GB of available memory for every 1TB to be backed up, regardless of backup set breakdown. The amount of archival data we have to backup therefore makes a Synology/CrashPlanPro solution unsuitable. Heck, the whole CrashPlan system is pretty unscalable if that’s the case. “Unlimited storage” indeed.

      Thanks to everyone for their help, but I give up. Time to explore other backup solutions.

      1. Marcus

        This is not correct. I have 11 TB. And this worked perfectly well with my DS412+ which used 2 GB for Crashplan. It is only the number of files per backup set which matters.

      2. Eloi

        14tb with 300k files over 6 backup sets on 2gb of ram so I believe this solution does work. Although it did crash sometime but oh well no cheaper option than crash plan to date that work with nas or should I say nothing work with nas except for crashplan unless you count Amazon glacier.


      3. OecherWolke

        Hi Eric, this “rule” isn’t true. It depends on the amount of files, the settings (deduplication/compression) and the file size. Really huge files need more RAM for compression and deduplication. A big number of files in one job needs more RAM for the selection/analyzing process. I save about 11TB on a DS1513+ with only 4GB of RAM. The jobs are quite different. A “office”-job (office documents) and some “graphics-jobs” (JPEG, TIFF, PSD, PSB files) with sizes up to 3GB per file.

  26. goslow2gofast

    So, I have a DS413, and have had reasonable success with CrashPlan installed for the last month or so. But this weekend an update to DSM 5.1 was installed, and the machine rebooted, and now when I try to start the CrashPlan package it won’t stay running for more than a few seconds. No entries in it’s log file. Is this common, is there a fix?


  27. Daniel

    I have a Synology 214se and had everything working on DSM 5.1 until the 5004 update. Since DSM has updated, the crashplan app won’t run. Is there any simple way of getting it back to life? I tried re-installing Java SE 7, but it didn’t help. Installation according to PCload. Thank you!

  28. Aaron

    I just updated Crashplan on my Snynology 214+ running 5.1-5004 update 2. I also updated Java 7. Java 7 is running but Crashplan won’t start. When I try to run it manually I get the following message. “Failed to run the package service. Check package log……” Any ideas on getting Crashplan running again?

  29. B. Goodman

    On my stock DS412+, I’m currently running:
    DSM 5.1 Update 1
    Patters Java 1.7.0_71-0029
    CrashPlan 3.6.3-0027

    I’m being prompted to upgrade to:
    DSM 5.1 Update 2
    CrashPlan 3.6.4

    I’m thinking about staying where I am rather than risking breaking the whole thing. Constructive advice would be greatly appreciated!

  30. Maxime

    Hello i bought the new 215j and added the repo, but only 3 packets show ( open remote, minecraft, craftbukkit ). Does this mean the packages aren’t available for my processor (Marvell Armada 370 Dual Core)?
    Thanks for your work.

    1. patters Post author

      I will need to add in support for that CPU type, which is new (Marvell Armada 375). Please can you connect to your NAS with SSH and reply back here with the result of running this command:
      uname -a

      1. Maxime

        Thank you, here’s the message :
        Linux xxxx 3.2.40 #5004 SMP Sat Nov 29 01:35:02 CST 2014 armv7l GNU/Linux synology_armada375_ds215j

      2. Maxime

        Processor : ARMv7 Processor rev 1 (v7l)
        processor : 0
        BogoMIPS : 1594.16

        processor : 1
        BogoMIPS : 1594.16

        Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
        CPU implementer : 0x41
        CPU architecture: 7
        CPU variant : 0x4
        CPU part : 0xc09
        CPU revision : 1

        Hardware : Marvell Armada-375 Board
        Revision : 0000
        Serial : 0000000000000000

  31. belnas

    hi, all good,
    but after a reboot, the backup folders appear as “missing” on the crashplan desktop.
    but when I click them, it opens the NAS filesystem and the folders appear as selected.

    any advise?


  32. John

    I tried the CrashPlanPRO package and it seemed to be working, but upon rebooting the synology server the application does not restart. I tried restarting it manually using the start-stop-status script, but it reported directory errors. I uninstalled PRO then installed basic CrashPlan and it does restart when the server reboot.

    I think the PRO startup script has a bug.

  33. Jens

    Hi All!

    I successfully added the repository and was able to install Java (I took Version 7) and checked it is running. When I navigate to Community I see “Bliss, CraftBukkit, Java 6/7/8, Minecraft, Openremote and Servilo”, but Crashplan is missing! :-(
    I updated the package list, restarted my DS (it’s a DS413 with DSM 5.0-4528 Update 2) with no luck – the Crashplan Client is still not visible! :-(

    Can anyone PLEASE help??!?


  34. naPS

    Trying to download the package now, and it’s telling me it doesn’t have a digital signature. This is after the latest Syno update.

  35. WiFied

    Has anyone updated to DSM 5.1-5021? Any problems with Crashplan following the update? Crashplan been very stable for me on 5.1-5004, so just trying to avoid problems on DS1512+.


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