CrashPlan packages for Synology NAS

6,692 Replies

UPDATE – CrashPlan For Home (green branding) was retired by Code 42 Software on 22/08/2017. See migration notes below to find out how to transfer to CrashPlan for Small Business on Synology at the special discounted rate.

CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient, particularly against the threat of ransomware.

There are now only two product versions:

  • Small Business: CrashPlan PRO (blue branding). Unlimited cloud backup subscription, $10 per device per month. Reporting via Admin Console. No peer-to-peer backups
  • Enterprise: CrashPlan PROe (black branding). Cloud backup subscription typically billed by storage usage, also available from third parties.

The instructions and notes on this page apply to both versions of the Synology package.

CrashPlanPRO-Windows

CrashPlan is a Java application which can be difficult to install on a NAS. Way back in January 2012 I decided to simplify it into a Synology package, since I had already created several others. It has been through many versions since that time, as the changelog below shows. Although it used to work on Synology products with ARM and PowerPC CPUs, it unfortunately became Intel-only in October 2016 due to Code 42 Software adding a reliance on some proprietary libraries.

Licence compliance is another challenge – Code 42’s EULA prohibits redistribution. I had to make the Synology package use the regular CrashPlan for Linux download (after the end user agrees to the Code 42 EULA). I then had to write my own script to extract this archive and mimic the Code 42 installer behaviour, but without the interactive prompts of the original.

 

Synology Package Installation

  • In Synology DSM’s Package Center, click Settings and add my package repository:
    Add Package Repository
  • The repository will push its certificate automatically to the NAS, which is used to validate package integrity. Set the Trust Level to Synology Inc. and trusted publishers:
    Trust Level
  • Now browse the Community section in Package Center to install CrashPlan:
    Community-packages
    The repository only displays packages which are compatible with your specific model of NAS. If you don’t see CrashPlan in the list, then either your NAS model or your DSM version are not supported at this time. DSM 5.0 is the minimum supported version for this package, and an Intel CPU is required.
  • Since CrashPlan is a Java application, it needs a Java Runtime Environment (JRE) to function. It is recommended that you select to have the package install a dedicated Java 8 runtime. For licensing reasons I cannot include Java with this package, so you will need to agree to the licence terms and download it yourself from Oracle’s website. The package expects to find this .tar.gz file in a shared folder called ‘public’. If you go ahead and try to install the package without it, the error message will indicate precisely which Java file you need for your system type, and it will provide a TinyURL link to the appropriate Oracle download page.
  • To install CrashPlan PRO you will first need to log into the Admin Console and download the Linux App from the App Download section and also place this in the ‘public’ shared folder on your NAS.
  • If you have a multi-bay NAS, use the Shared Folder control panel to create the shared folder called public (it must be all lower case). On single bay models this is created by default. Assign it with Read/Write privileges for everyone.
  • If you have trouble getting the Java or CrashPlan PRO app files recognised by this package, try downloading them with Firefox. It seems to be the only web browser that doesn’t try to uncompress the files, or rename them without warning. I also suggest that you leave the Java file and the public folder present once you have installed the package, so that you won’t need to fetch this again to install future updates to the CrashPlan package.
  • CrashPlan is installed in headless mode – backup engine only. This will configured by a desktop client, but operates independently of it.
  • The first time you start the CrashPlan package you will need to stop it and restart it before you can connect the client. This is because a config file that is only created on first run needs to be edited by one of my scripts. The engine is then configured to listen on all interfaces on the default port 4243.
 

CrashPlan Client Installation

  • Once the CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
  • Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.
  • The Linux CrashPlan PRO client must be downloaded from the Admin Console and placed in the ‘public’ folder on your NAS in order to successfully install the Synology package.
  • By default the client is configured to connect to the CrashPlan engine running on the local computer. Run this command on your NAS from an SSH session:
    echo `cat /var/lib/crashplan/.ui_info`
    Note those are backticks not quotes. This will give you a port number (4243), followed by an authentication token, followed by the IP binding (0.0.0.0 means the server is listening for connections on all interfaces) e.g.:
    4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0
    port,--------------token-----------------,binding
    Copy this token value and use this value to replace the token in the equivalent config file on the computer that you would like to run the CrashPlan client on – located here:
    C:\ProgramData\CrashPlan\.ui_info (Windows)
    “/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for all users)
    “~/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for single user)
    /var/lib/crashplan/.ui_info (Linux)
    You will not be able to connect the client unless the client token matches on the NAS token. On the client you also need to amend the IP address value after the token to match the Synology NAS IP address.
    so using the example above, your computer’s CrashPlan client config file would be edited to:
    4243,9ac9b642-ba26-4578-b705-124c6efc920b,192.168.1.100
    assuming that the Synology NAS has the IP 192.168.1.100
    If it still won’t connect, check that the ServicePort value is set to 4243 in the following files:
    C:\ProgramData\CrashPlan\conf\ui_(username).properties (Windows)
    “/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for all users)
    “~/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for single user)
    /usr/local/crashplan/conf (Linux)
    /var/lib/crashplan/.ui_info (Synology) – this value does change spontaneously if there’s a port conflict e.g. you started two versions of the package concurrently (CrashPlan and CrashPlan PRO)
  • As a result of the nightmarish complexity of recent product changes Code42 has now published a support article with more detail on running headless systems including config file locations on all supported operating systems, and for ‘all users’ versus single user installs etc.
  • You should disable the CrashPlan service on your computer if you intend only to use the client. In Windows, open the Services section in Computer Management and stop the CrashPlan Backup Service. In the service Properties set the Startup Type to Manual. You can also disable the CrashPlan System Tray notification application by removing it from Task Manager > More Details > Start-up Tab (Windows 8/Windows 10) or the All Users Startup Start Menu folder (Windows 7).
    To accomplish the same on Mac OS X, run the following commands one by one:

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

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

 

Migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO)

  • Leave the regular green branded CrashPlan 4.8.3 Synology package installed.
  • Go through the online migration using the link in the email notification you received from Code 42 on 22/08/2017. This seems to trigger the CrashPlan client to begin an update to 4.9 which will fail. It will also migrate your account onto a CrashPlan PRO server. The web page is likely to stall on the Migrating step, but no matter. The process is meant to take you to the store but it seems to be quite flakey. If you see the store page with a $0.00 amount in the basket, this has correctly referred you for the introductory offer. Apparently the $9.99 price thereafter shown on that screen is a mistake and the correct price of $2.50 is shown on a later screen in the process I think. Enter your credit card details and check out if you can. If not, continue.
  • Log into the CrashPlan PRO Admin Console as per these instructions, and download the CrashPlan PRO 4.9 client for Linux, and the 4.9 client for your remote console computer. Ignore the red message in the bottom left of the Admin Console about registering, and do not sign up for the free trial. Preferably use Firefox for the Linux version download – most of the other web browsers will try to unpack the .tgz archive, which you do not want to happen.
  • Configure the CrashPlan PRO 4.9 client on your computer to connect to your Syno as per the usual instructions on this blog post.
  • Put the downloaded Linux CrashPlan PRO 4.9 client .tgz file in the ‘public’ shared folder on your NAS. The package will no longer download this automatically as it did in previous versions.
  • From the Community section of DSM Package Center, install the CrashPlan PRO 4.9 package concurrently with your existing CrashPlan 4.8.3 Syno package.
  • This will stop the CrashPlan package and automatically import its configuration. Notice that it will also backup your old CrashPlan .identity file and leave it in the ‘public’ shared folder, just in case something goes wrong.
  • Start the CrashPlan PRO Synology package, and connect your CrashPlan PRO console from your computer.
  • You should see your protected folders as usual. At first mine reported something like “insufficient device licences”, but the next time I started up it changed to “subscription expired”.
  • Uninstall the CrashPlan 4.8.3 Synology package, this is no longer required.
  • At this point if the store referral didn’t work in the second step, you need to sign into the Admin Console. While signed in, navigate to this link which I was given by Code 42 support. If it works, you should see a store page with some blue font text and a $0.00 basket value. If it didn’t work you will get bounced to the Consumer Next Steps webpage: “Important Changes to CrashPlan for Home” – the one with the video of the CEO explaining the situation. I had to do this a few times before it worked. Once the store referral link worked and I had confirmed my payment details my CrashPlan PRO client immediately started working. Enjoy!
 

Notes

  • The package uses the intact CrashPlan installer directly from Code 42 Software, following acceptance of its EULA. I am complying with the directive that no one redistributes it.
  • The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 512MB). This can be overridden in a persistent way if you are backing up large backup sets by editing /var/packages/CrashPlan/target/syno_package.vars. If you are considering buying a NAS purely to use CrashPlan and intend to back up more than a few hundred GB then I strongly advise buying one of the models with upgradeable RAM. Memory is very limited on the cheaper models. I have found that a 512MB heap was insufficient to back up more than 2TB of files on a Windows server and that was the situation many years ago. It kept restarting the backup engine every few minutes until I increased the heap to 1024MB. Many users of the package have found that they have to increase the heap size or CrashPlan will halt its activity. This can be mitigated by dividing your backup into several smaller backup sets which are scheduled to be protected at different times. Note that from package version 0041, using the dedicated JRE on a 64bit Intel NAS will allow a heap size greater than 4GB since the JRE is 64bit (requires DSM 6.0 in most cases).
  • If you need to manage CrashPlan from a remote location, I suggest you do so using SSH tunnelling as per this support document.
  • The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache. Upgrades can now take place without requiring a login from the client afterwards.
  • If you remove the package completely and re-install it later, you can re-attach to previous backups. When you log in to the Desktop Client with your existing account after a re-install, you can select “adopt computer” to merge the records, and preserve your existing backups. I haven’t tested whether this also re-attaches links to friends’ CrashPlan computers and backup sets, though the latter does seem possible in the Friends section of the GUI. It’s probably a good idea to test that this survives a package reinstall before you start relying on it. Sometimes, particularly with CrashPlan PRO I think, the adopt option is not offered. In this case you can log into CrashPlan Central and retrieve your computer’s GUID. On the CrashPlan client, double-click on the logo in the top right and you’ll enter a command line mode. You can use the GUID command to change the system’s GUID to the one you just retrieved from your account.
  • The log which is displayed in the package’s Log tab is actually the activity history. If you are trying to troubleshoot an issue you will need to use an SSH session to inspect these log files:
    /var/packages/CrashPlan/target/log/engine_output.log
    /var/packages/CrashPlan/target/log/engine_error.log
    /var/packages/CrashPlan/target/log/app.log
  • When CrashPlan downloads and attempts to run an automatic update, the script will most likely fail and stop the package. This is typically caused by syntax differences with the Synology versions of certain Linux shell commands (like rm, mv, or ps). The startup script will attempt to apply the published upgrade the next time the package is started.
  • Although CrashPlan’s activity can be scheduled within the application, in order to save RAM some users may wish to restrict running the CrashPlan engine to specific times of day using the Task Scheduler in DSM Control Panel:
    Schedule service start
    Note that regardless of real-time backup, by default CrashPlan will scan the whole backup selection for changes at 3:00am. Include this time within your Task Scheduler time window or else CrashPlan will not capture file changes which occurred while it was inactive:
    Schedule Service Start

  • If you decide to sign up for one of CrashPlan’s paid backup services as a result of my work on this, please consider donating using the PayPal button on the right of this page.
 

Package scripts

For information, here are the package scripts so you can see what it’s going to do. You can get more information about how packages work by reading the Synology 3rd Party Developer Guide.

installer.sh

#!/bin/sh

#--------CRASHPLAN installer script
#--------package maintained at pcloadletter.co.uk


DOWNLOAD_PATH="http://download2.code42.com/installs/linux/install/${SYNOPKG_PKGNAME}"
CP_EXTRACTED_FOLDER="crashplan-install"
OLD_JNA_NEEDED="false"
[ "${SYNOPKG_PKGNAME}" == "CrashPlan" ] && DOWNLOAD_FILE="CrashPlan_4.8.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_4.*_Linux.tgz"
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
  CP_EXTRACTED_FOLDER="${SYNOPKG_PKGNAME}-install"
  OLD_JNA_NEEDED="true"
  [ "${WIZARD_VER_483}" == "true" ] && { CPPROE_VER="4.8.3"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_480}" == "true" ] && { CPPROE_VER="4.8.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_470}" == "true" ] && { CPPROE_VER="4.7.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_460}" == "true" ] && { CPPROE_VER="4.6.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_452}" == "true" ] && { CPPROE_VER="4.5.2"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_450}" == "true" ] && { CPPROE_VER="4.5.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_441}" == "true" ] && { CPPROE_VER="4.4.1"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
  [ "${WIZARD_VER_430}" == "true" ] && CPPROE_VER="4.3.0"
  [ "${WIZARD_VER_420}" == "true" ] && CPPROE_VER="4.2.0"
  [ "${WIZARD_VER_370}" == "true" ] && CPPROE_VER="3.7.0"
  [ "${WIZARD_VER_364}" == "true" ] && CPPROE_VER="3.6.4"
  [ "${WIZARD_VER_363}" == "true" ] && CPPROE_VER="3.6.3"
  [ "${WIZARD_VER_3614}" == "true" ] && CPPROE_VER="3.6.1.4"
  [ "${WIZARD_VER_353}" == "true" ] && CPPROE_VER="3.5.3"
  [ "${WIZARD_VER_341}" == "true" ] && CPPROE_VER="3.4.1"
  [ "${WIZARD_VER_33}" == "true" ] && CPPROE_VER="3.3"
  DOWNLOAD_FILE="CrashPlanPROe_${CPPROE_VER}_Linux.tgz"
fi
DOWNLOAD_URL="${DOWNLOAD_PATH}/${DOWNLOAD_FILE}"
CPI_FILE="${SYNOPKG_PKGNAME}_*.cpi"
OPTDIR="${SYNOPKG_PKGDEST}"
VARS_FILE="${OPTDIR}/install.vars"
SYNO_CPU_ARCH="`uname -m`"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
[ "${SYNO_CPU_ARCH}" == "armv5tel" ] && SYNO_CPU_ARCH="armel"
[ "${SYNOPKG_DSM_ARCH}" == "armada375" ] && SYNO_CPU_ARCH="armv7l"
[ "${SYNOPKG_DSM_ARCH}" == "armada38x" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "comcerto2k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine4k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "monaco" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "rtd1296" ] && SYNO_CPU_ARCH="armhf"
NATIVE_BINS_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-${SYNO_CPU_ARCH}.tar.xz"   
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
OLD_JNA_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-old-${SYNO_CPU_ARCH}.tar.xz"   
OLD_JNA_FILE="`echo ${OLD_JNA_URL} | sed -r "s%^.*/(.*)%\1%"`"
INSTALL_FILES="${DOWNLOAD_URL} ${NATIVE_BINS_URL}"
[ "${OLD_JNA_NEEDED}" == "true" ] && INSTALL_FILES="${INSTALL_FILES} ${OLD_JNA_URL}"
TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
#the Manifest folder is where friends' backup data is stored
#we set it outside the app folder so it persists after a package uninstall
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
LOG_FILE="${SYNOPKG_PKGDEST}/log/history.log.0"
UPGRADE_FILES="syno_package.vars conf/my.service.xml conf/service.login conf/service.model"
UPGRADE_FOLDERS="log cache"
PUBLIC_FOLDER="`synoshare --get public | sed -r "/Path/!d;s/^.*\[(.*)\].*$/\1/"`"
#dedicated JRE section
if [ "${WIZARD_JRE_CP}" == "true" ]; then
  DOWNLOAD_URL="http://tinyurl.com/javaembed"
  EXTRACTED_FOLDER="ejdk1.8.0_151"
  #detect systems capable of running 64bit JRE which can address more than 4GB of RAM
  [ "${SYNOPKG_DSM_ARCH}" == "x64" ] && SYNO_CPU_ARCH="x64"
  [ "`uname -m`" == "x86_64" ] && [ ${SYNOPKG_DSM_VERSION_MAJOR} -ge 6 ] && SYNO_CPU_ARCH="x64"
  if [ "${SYNO_CPU_ARCH}" == "armel" ]; then
    JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
    JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
  elif [ "${SYNO_CPU_ARCH}" == "armv7l" ]; then
    JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
    JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
  elif [ "${SYNO_CPU_ARCH}" == "armhf" ]; then
    JAVA_BINARY="ejdk-8u151-linux-armv6-vfp-hflt.tar.gz"
    JAVA_BUILD="ARMv6/ARMv7 Linux - VFP, HardFP ABI, Little Endian 1"
  elif [ "${SYNO_CPU_ARCH}" == "ppc" ]; then
    #Oracle have discontinued Java 8 for PowerPC after update 6
    JAVA_BINARY="ejdk-8u6-fcs-b23-linux-ppc-e500v2-12_jun_2014.tar.gz"
    JAVA_BUILD="Power Architecture Linux - Headless - e500v2 with double-precision SPE Floating Point Unit"
    EXTRACTED_FOLDER="ejdk1.8.0_06"
    DOWNLOAD_URL="http://tinyurl.com/java8ppc"
  elif [ "${SYNO_CPU_ARCH}" == "i686" ]; then
    JAVA_BINARY="ejdk-8u151-linux-i586.tar.gz"
    JAVA_BUILD="x86 Linux Small Footprint - Headless"
  elif [ "${SYNO_CPU_ARCH}" == "x64" ]; then
    JAVA_BINARY="jre-8u151-linux-x64.tar.gz"
    JAVA_BUILD="Linux x64"
    EXTRACTED_FOLDER="jre1.8.0_151"
    DOWNLOAD_URL="http://tinyurl.com/java8x64"
  fi
fi
JAVA_BINARY=`echo ${JAVA_BINARY} | cut -f1 -d'.'`
source /etc/profile


pre_checks ()
{
  #These checks are called from preinst and from preupgrade functions to prevent failures resulting in a partially upgraded package
  if [ "${WIZARD_JRE_CP}" == "true" ]; then
    synoshare -get public > /dev/null || (
      echo "A shared folder called 'public' could not be found - note this name is case-sensitive. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Please create this using the Shared Folder DSM Control Panel and try again." >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    )

    JAVA_BINARY_FOUND=
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz ] && JAVA_BINARY_FOUND=true
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar ] && JAVA_BINARY_FOUND=true
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.tar ] && JAVA_BINARY_FOUND=true
    [ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.gz ] && JAVA_BINARY_FOUND=true
     
    if [ -z ${JAVA_BINARY_FOUND} ]; then
      echo "Java binary bundle not found. " >> $SYNOPKG_TEMP_LOGFILE
      echo "I was expecting the file ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Please agree to the Oracle licence at ${DOWNLOAD_URL}, then download the '${JAVA_BUILD}' package" >> $SYNOPKG_TEMP_LOGFILE
      echo "and place it in the 'public' shared folder on your NAS. This download cannot be automated even if " >> $SYNOPKG_TEMP_LOGFILE
      echo "displaying a package EULA could potentially cover the legal aspect, because files hosted on Oracle's " >> $SYNOPKG_TEMP_LOGFILE
      echo "server are protected by a session cookie requiring a JavaScript enabled browser." >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    fi
  else
    if [ -z ${JAVA_HOME} ]; then
      echo "Java is not installed or not properly configured. JAVA_HOME is not defined. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    fi

    if [ ! -f ${JAVA_HOME}/bin/java ]; then
      echo "Java is not installed or not properly configured. The Java binary could not be located. " >> $SYNOPKG_TEMP_LOGFILE
      echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
      exit 1
    fi

    if [ "${WIZARD_JRE_SYS}" == "true" ]; then
      JAVA_VER=`java -version 2>&1 | sed -r "/^.* version/!d;s/^.* version \"[0-9]\.([0-9]).*$/\1/"`
      if [ ${JAVA_VER} -lt 8 ]; then
        echo "This version of CrashPlan requires Java 8 or newer. Please update your Java package. "
        exit 1
      fi
    fi
  fi
}


preinst ()
{
  pre_checks
  cd ${TEMP_FOLDER}
  for WGET_URL in ${INSTALL_FILES}
  do
    WGET_FILENAME="`echo ${WGET_URL} | sed -r "s%^.*/(.*)%\1%"`"
    [ -f ${TEMP_FOLDER}/${WGET_FILENAME} ] && rm ${TEMP_FOLDER}/${WGET_FILENAME}
    wget ${WGET_URL}
    if [[ $? != 0 ]]; then
      if [ -d ${PUBLIC_FOLDER} ] && [ -f ${PUBLIC_FOLDER}/${WGET_FILENAME} ]; then
        cp ${PUBLIC_FOLDER}/${WGET_FILENAME} ${TEMP_FOLDER}
      else     
        echo "There was a problem downloading ${WGET_FILENAME} from the official download link, " >> $SYNOPKG_TEMP_LOGFILE
        echo "which was \"${WGET_URL}\" " >> $SYNOPKG_TEMP_LOGFILE
        echo "Alternatively, you may download this file manually and place it in the 'public' shared folder. " >> $SYNOPKG_TEMP_LOGFILE
        exit 1
      fi
    fi
  done
 
  exit 0
}


postinst ()
{
  if [ "${WIZARD_JRE_CP}" == "true" ]; then
    #extract Java (Web browsers love to interfere with .tar.gz files)
    cd ${PUBLIC_FOLDER}
    if [ -f ${JAVA_BINARY}.tar.gz ]; then
      #Firefox seems to be the only browser that leaves it alone
      tar xzf ${JAVA_BINARY}.tar.gz
    elif [ -f ${JAVA_BINARY}.gz ]; then
      #Chrome
      tar xzf ${JAVA_BINARY}.gz
    elif [ -f ${JAVA_BINARY}.tar ]; then
      #Safari
      tar xf ${JAVA_BINARY}.tar
    elif [ -f ${JAVA_BINARY}.tar.tar ]; then
      #Internet Explorer
      tar xzf ${JAVA_BINARY}.tar.tar
    fi
    mv ${EXTRACTED_FOLDER} ${SYNOPKG_PKGDEST}/jre-syno
    JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
    [ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
    #change owner of folder tree
    chown -R root:root ${SYNOPKG_PKGDEST}
  fi
   
  #extract CPU-specific additional binaries
  mkdir ${SYNOPKG_PKGDEST}/bin
  cd ${SYNOPKG_PKGDEST}/bin
  tar xJf ${TEMP_FOLDER}/${NATIVE_BINS_FILE} && rm ${TEMP_FOLDER}/${NATIVE_BINS_FILE}
  [ "${OLD_JNA_NEEDED}" == "true" ] && tar xJf ${TEMP_FOLDER}/${OLD_JNA_FILE} && rm ${TEMP_FOLDER}/${OLD_JNA_FILE}

  #extract main archive
  cd ${TEMP_FOLDER}
  tar xzf ${TEMP_FOLDER}/${DOWNLOAD_FILE} && rm ${TEMP_FOLDER}/${DOWNLOAD_FILE} 
  
  #extract cpio archive
  cd ${SYNOPKG_PKGDEST}
  cat "${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}"/${CPI_FILE} | gzip -d -c - | ${SYNOPKG_PKGDEST}/bin/cpio -i --no-preserve-owner
  
  echo "#uncomment to expand Java max heap size beyond prescribed value (will survive upgrades)" > ${SYNOPKG_PKGDEST}/syno_package.vars
  echo "#you probably only want more than the recommended 1024M if you're backing up extremely large volumes of files" >> ${SYNOPKG_PKGDEST}/syno_package.vars
  echo "#USR_MAX_HEAP=1024M" >> ${SYNOPKG_PKGDEST}/syno_package.vars
  echo >> ${SYNOPKG_PKGDEST}/syno_package.vars

  cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/CrashPlanEngine ${OPTDIR}/bin
  cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/run.conf ${OPTDIR}/bin
  mkdir -p ${MANIFEST_FOLDER}/backupArchives    
  
  #save install variables which Crashplan expects its own installer script to create
  echo TARGETDIR=${SYNOPKG_PKGDEST} > ${VARS_FILE}
  echo BINSDIR=/bin >> ${VARS_FILE}
  echo MANIFESTDIR=${MANIFEST_FOLDER}/backupArchives >> ${VARS_FILE}
  #leave these ones out which should help upgrades from Code42 to work (based on examining an upgrade script)
  #echo INITDIR=/etc/init.d >> ${VARS_FILE}
  #echo RUNLVLDIR=/usr/syno/etc/rc.d >> ${VARS_FILE}
  echo INSTALLDATE=`date +%Y%m%d` >> ${VARS_FILE}
  [ "${WIZARD_JRE_CP}" == "true" ] && echo JAVACOMMON=${JRE_PATH}/bin/java >> ${VARS_FILE}
  [ "${WIZARD_JRE_SYS}" == "true" ] && echo JAVACOMMON=\${JAVA_HOME}/bin/java >> ${VARS_FILE}
  cat ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/install.defaults >> ${VARS_FILE}
  
  #remove temp files
  rm -r ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}
  
  #add firewall config
  /usr/syno/bin/servicetool --install-configure-file --package /var/packages/${SYNOPKG_PKGNAME}/scripts/${SYNOPKG_PKGNAME}.sc > /dev/null
  
  #amend CrashPlanPROe client version
  [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ] && sed -i -r "s/^version=\".*(-.*$)/version=\"${CPPROE_VER}\1/" /var/packages/${SYNOPKG_PKGNAME}/INFO

  #are we transitioning an existing CrashPlan account to CrashPlan For Small Business?
  if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ]; then
    if [ -e /var/packages/CrashPlan/scripts/start-stop-status ]; then
      /var/packages/CrashPlan/scripts/start-stop-status stop
      cp /var/lib/crashplan/.identity ${PUBLIC_FOLDER}/crashplan-identity.bak
      cp -R /var/packages/CrashPlan/target/conf/ ${OPTDIR}/
    fi  
  fi

  exit 0
}


preuninst ()
{
  `dirname $0`/stop-start-status stop

  exit 0
}


postuninst ()
{
  if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
    source ${SYNOPKG_PKGDEST}/syno_package.vars
  fi
  [ -e ${OPTDIR}/lib/libffi.so.5 ] && rm ${OPTDIR}/lib/libffi.so.5

  #delete symlink if it no longer resolves - PowerPC only
  if [ ! -e /lib/libffi.so.5 ]; then
    [ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
  fi

  #remove firewall config
  if [ "${SYNOPKG_PKG_STATUS}" == "UNINSTALL" ]; then
    /usr/syno/bin/servicetool --remove-configure-file --package ${SYNOPKG_PKGNAME}.sc > /dev/null
  fi

 exit 0
}


preupgrade ()
{
  `dirname $0`/stop-start-status stop
  pre_checks
  #if identity exists back up config
  if [ -f /var/lib/crashplan/.identity ]; then
    mkdir -p ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
    for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
      if [ -f ${OPTDIR}/${FILE_TO_MIGRATE} ]; then
        cp ${OPTDIR}/${FILE_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE}
      fi
    done
    for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
      if [ -d ${OPTDIR}/${FOLDER_TO_MIGRATE} ]; then
        mv ${OPTDIR}/${FOLDER_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig
      fi
    done
  fi

  exit 0
}


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

start-stop-status.sh

#!/bin/sh

#--------CRASHPLAN start-stop-status script
#--------package maintained at pcloadletter.co.uk


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


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

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

  #fix up some of the binary paths and fix some command syntax for busybox 
  #moved this to start-stop-status.sh from installer.sh because Code42 push updates and these
  #new scripts will need this treatment too
  find ${OPTDIR}/ -name "*.sh" | while IFS="" read -r FILE_TO_EDIT; do
    if [ -e ${FILE_TO_EDIT} ]; then
      #this list of substitutions will probably need expanding as new CrashPlan updates are released
      sed -i "s%^#!/bin/bash%#!$/bin/sh%" "${FILE_TO_EDIT}"
      sed -i -r "s%(^\s*)(/bin/cpio |cpio ) %\1/${OPTDIR}/bin/cpio %" "${FILE_TO_EDIT}"
      sed -i -r "s%(^\s*)(/bin/ps|ps) [^w][^\|]*\|%\1/bin/ps w \|%" "${FILE_TO_EDIT}"
      sed -i -r "s%\`ps [^w][^\|]*\|%\`ps w \|%" "${FILE_TO_EDIT}"
      sed -i -r "s%^ps [^w][^\|]*\|%ps w \|%" "${FILE_TO_EDIT}"
      sed -i "s/rm -fv/rm -f/" "${FILE_TO_EDIT}"
      sed -i "s/mv -fv/mv -f/" "${FILE_TO_EDIT}"
    fi
  done

  #use this daemon init script rather than the unreliable Code42 stock one which greps the ps output
  sed -i "s%^ENGINE_SCRIPT=.*$%ENGINE_SCRIPT=$0%" ${OPTDIR}/bin/restartLinux.sh

  #any downloaded upgrade script will usually have failed despite the above changes
  #so ignore the script and explicitly extract the new java code using the chrisnelson.ca method 
  #thanks to Jeff Bingham for tweaks 
  UPGRADE_JAR=`find ${OPTDIR}/upgrade -maxdepth 1 -name "*.jar" | tail -1`
  if [ -n "${UPGRADE_JAR}" ]; then
    rm ${OPTDIR}/*.pid > /dev/null
 
    #make CrashPlan log entry
    echo "I ${TIMESTAMP} Synology extracting upgrade from ${UPGRADE_JAR}" >> ${DLOG}

    UPGRADE_VER=`echo ${SCRIPT_HOME} | sed -r "s/^.*\/([0-9_]+)\.[0-9]+/\1/"`
    #DSM 6.0 no longer includes unzip, use 7z instead
    unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -d ${OPTDIR}/lib/ || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -o${OPTDIR}/lib/ > /dev/null
    unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -d ${OPTDIR} || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -o${OPTDIR} > /dev/null
    mv ${UPGRADE_JAR} ${TEMP_FOLDER}/ > /dev/null
    exec $0
  fi

  #updates may also overwrite our native binaries
  [ -e ${OPTDIR}/bin/libffi.so.5 ] && cp -f ${OPTDIR}/bin/libffi.so.5 ${OPTDIR}/lib/
  [ -e ${OPTDIR}/bin/libjtux.so ] && cp -f ${OPTDIR}/bin/libjtux.so ${OPTDIR}/
  [ -e ${OPTDIR}/bin/jna-3.2.5.jar ] && cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib/
  if [ -e ${OPTDIR}/bin/jna.jar ] && [ -e ${OPTDIR}/lib/jna.jar ]; then
    cp -f ${OPTDIR}/bin/jna.jar ${OPTDIR}/lib/
  fi

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

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

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

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

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

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

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

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

  #increase the system-wide maximum number of open files from Synology default of 24466
  [ `cat /proc/sys/fs/file-max` -lt 65536 ] && echo "65536" > /proc/sys/fs/file-max

  #raise the maximum open file count from the Synology default of 1024 - thanks Casper K. for figuring this out
  #http://support.code42.com/Administrator/3.6_And_4.0/Troubleshooting/Too_Many_Open_Files
  ulimit -n 65536

  #ensure that Code 42 have not amended install.vars to force the use of their own (Intel) JRE
  if [ -e ${OPTDIR}/jre-syno ]; then
    JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
    [ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
    sed -i -r "s|^(JAVACOMMON=).*$|\1\${JRE_PATH}/bin/java|" ${OPTDIR}/install.vars
    
    #if missing, set timezone and locale for dedicated JRE   
    if [ -z ${TZ} ]; then
      SYNO_TZ=`cat /etc/synoinfo.conf | grep timezone | cut -f2 -d'"'`
      #fix for DST time in DSM 5.2 thanks to MinimServer Syno package author
      [ -e /usr/share/zoneinfo/Timezone/synotztable.json ] \
       && SYNO_TZ=`jq ".${SYNO_TZ} | .nameInTZDB" /usr/share/zoneinfo/Timezone/synotztable.json | sed -e "s/\"//g"` \
       || SYNO_TZ=`grep "^${SYNO_TZ}" /usr/share/zoneinfo/Timezone/tzname | sed -e "s/^.*= //"`
      export TZ=${SYNO_TZ}
    fi
    [ -z ${LANG} ] && export LANG=en_US.utf8
    export CLASSPATH=.:${OPTDIR}/jre-syno/lib

  else
    sed -i -r "s|^(JAVACOMMON=).*$|\1\${JAVA_HOME}/bin/java|" ${OPTDIR}/install.vars
  fi

  source ${OPTDIR}/bin/run.conf
  source ${OPTDIR}/install.vars
  cd ${OPTDIR}
  $JAVACOMMON $SRV_JAVA_OPTS -classpath $FULL_CP com.backup42.service.CPService > ${OPTDIR}/log/engine_output.log 2> ${OPTDIR}/log/engine_error.log &
  if [ $! -gt 0 ]; then
    echo $! > $PID_FILE
    renice 19 $! > /dev/null
    if [ -z "${SYNOPKG_PKGDEST}" ]; then
      #script was manually invoked, need this to show status change in Package Center      
      [ -e ${PKG_FOLDER}/enabled ] || touch ${PKG_FOLDER}/enabled
    fi
  else
    echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" > "${SYNOPKG_TEMP_LOGFILE}"
    echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" >&2
    exit 1
  fi
}

stop_daemon ()
{
  echo "I ${TIMESTAMP} Stopping ${DNAME}" >> ${DLOG}
  kill `cat ${PID_FILE}`
  wait_for_status 1 20 || kill -9 `cat ${PID_FILE}`
  rm -f ${PID_FILE}
  if [ -z ${SYNOPKG_PKGDEST} ]; then
    #script was manually invoked, need this to show status change in Package Center
    [ -e ${PKG_FOLDER}/enabled ] && rm ${PKG_FOLDER}/enabled
  fi
  #backup identity file in case DSM upgrade removes it
  [ -e ${OPTDIR}/conf/var-backup ] || mkdir ${OPTDIR}/conf/var-backup 
  cp /var/lib/crashplan/.identity ${OPTDIR}/conf/var-backup/
}

daemon_status ()
{
  if [ -f ${PID_FILE} ] && kill -0 `cat ${PID_FILE}` > /dev/null 2>&1; then
    return
  fi
  rm -f ${PID_FILE}
  return 1
}

wait_for_status ()
{
  counter=$2
  while [ ${counter} -gt 0 ]; do
    daemon_status
    [ $? -eq $1 ] && return
    let counter=counter-1
    sleep 1
  done
  return 1
}


case $1 in
  start)
    if daemon_status; then
      echo ${DNAME} is already running with PID `cat ${PID_FILE}`
      exit 0
    else
      echo Starting ${DNAME} ...
      start_daemon
      exit $?
    fi
  ;;

  stop)
    if daemon_status; then
      echo Stopping ${DNAME} ...
      stop_daemon
      exit $?
    else
      echo ${DNAME} is not running
      exit 0
    fi
  ;;

  restart)
    stop_daemon
    start_daemon
    exit $?
  ;;

  status)
    if daemon_status; then
      echo ${DNAME} is running with PID `cat ${PID_FILE}`
      exit 0
    else
      echo ${DNAME} is not running
      exit 1
    fi
  ;;

  log)
    echo "${DLOG}"
    exit 0
  ;;

  *)
    echo "Usage: $0 {start|stop|status|restart}" >&2
    exit 1
  ;;

esac
 

install_uifile & upgrade_uifile

[
  {
    "step_title": "Client Version Selection",
    "items": [
      {
        "type": "singleselect",
        "desc": "Please select the CrashPlanPROe client version that is appropriate for your backup destination server:",
        "subitems": [
          {
            "key": "WIZARD_VER_483",
            "desc": "4.8.3",
            "defaultValue": true
          },          {
            "key": "WIZARD_VER_480",
            "desc": "4.8.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_470",
            "desc": "4.7.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_460",
            "desc": "4.6.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_452",
            "desc": "4.5.2",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_450",
            "desc": "4.5.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_441",
            "desc": "4.4.1",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_430",
            "desc": "4.3.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_420",
            "desc": "4.2.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_370",
            "desc": "3.7.0",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_364",
            "desc": "3.6.4",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_363",
            "desc": "3.6.3",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_3614",
            "desc": "3.6.1.4",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_353",
            "desc": "3.5.3",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_341",
            "desc": "3.4.1",
            "defaultValue": false
          },
          {
            "key": "WIZARD_VER_33",
            "desc": "3.3",
            "defaultValue": false
          }
        ]
      }
    ]
  },
  {
    "step_title": "Java Runtime Environment Selection",
    "items": [
      {
        "type": "singleselect",
        "desc": "Please select the Java version which you would like CrashPlan to use:",
        "subitems": [
          {
            "key": "WIZARD_JRE_SYS",
            "desc": "Default system Java version",
            "defaultValue": false
          },
          {
            "key": "WIZARD_JRE_CP",
            "desc": "Dedicated installation of Java 8",
            "defaultValue": true
          }
        ]
      }
    ]
  }
]
 

Changelog:

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

6,692 thoughts on “CrashPlan packages for Synology NAS”

  1. RAJ's avatarRAJ

    Just in case this helps anyone:

    Current setup:

    DS1511+ – Upgraded to 3G Memory
    DSM 5.1-5022 Update 3
    Patter’s CrashPlan Version 3.7.0-0030
    Patter’s Java SE Embedded 7 Version 1.7.0_75-0031
    CrashPlan + 3 Version 3.7.0
    3.4 TB backed up to CrashPlan

    Been using Patter’s packages for a couple of years now… and EVERY SINGLE TIME, I’ve had start/stop issues… it was because of memory. As my needs grew, I needed to upgrade ram, and allocate more and more as my archives grew. Aside from using the above, and upgrading to 3GB of memory… the following 3 tweaks help me get it all working seemlessly. Using Putty to SSH onto the DS1511+, and logging in as root:

    1. EDIT syno_package.vars
    a. cd /volume1/@appstore/CrashPlan
    b. vi syno_package.vars
    c. Change “#USR_MAX_HEAP=512M” to “USR_MAX_HEAP=2944M” removing the # and bumping up to 2944.
    d. Hit “ESCAPE” – “:wq” – “ENTER”

    2. EDIT run.conf
    a. cd /volume1/@appstore/CrashPlan/bin
    b. vi run.conf
    c. Change to “-Xms256m -Xmx2944m” on first line
    d. Change to “-Xms128m -Xmx1024m” on second line
    d. Hit “ESCAPE” – “:wq” – “ENTER”

    3. EDIT CrashPlanEngine
    a. cd /volume1/@appstore/CrashPlan/bin
    b. vi CrashPlanEngine
    c. Add lines (a couple of line above “# Common functions used for…”:
    #Increase open files limit
    ulimit -n 65536
    d. Hit “ESCAPE” – “:wq” – “ENTER”

    Not sure if all of the above is required, but it works, and I don’t feel like playing around. During actual encryption and upload to CrashPlan… memory usage peaks at 95%-97, but then drops to 33% during idle state… which is good cause it used to stay pegged at 95%+ all the time… so I’m happy.

    Hope this helps,…. and a thousand thanks again Patters!

    RAJ

    Reply ↓
    1. patters's avatarpatters Post author

      Apparently the newest release of Java 8 (main not embedded) includes significant memory management improvements, so it may be that all the CrashPlan memory issues could possibly be caused by the update to Java rather than CrashPlan.

      Reply ↓
      1. Eamon's avatarEamon

        Hi Patters,

        I’m getting the following error after upgrading to 3.70.0-0030 “synology repairing upgrade in ….” Is there anything I can try?

        Thanks,

        Eamon.

    2. Brian's avatarBrian

      Raj – is there another way to make this change? I do not know how to use PuTTY or SSH. I was hoping not to have to invest the time learning yet another piece of software that I will use once.

      Reply ↓
      1. RAJ's avatarRAJ

        Hi Brian… Unfortunately I don’t know, but it really wasn’t too hard… give it a shot (as you may have to do it often – at least once after every major update)… The steps I have are exactly what you need to key after you log in as root…. GL!!!

    3. patters's avatarpatters Post author

      btw changes 2 and 3 you listed there are unnecessary. That same entry in run.conf is populated by my startup script each start of CrashPlan using the value from syno_package.vars, and the third command is already executed by the start script.

      Reply ↓
    4. Ian H's avatarIan H

      Hi … I was looking for an app that would backup my Synology NAS to CrashPlan Cloud … correct me if I’m wrong, but this app looks to back from my PC to my NAS using CrashPlan as the app

      Reply ↓
    6. Scott Bowen's avatarscottlbowen

      DSM 5.2 broke crashplan…… No dice…. did this with no luck… also upgraded java to v8 embedded… no luck. Uninstalled and re-installed crashplan….. no luck still. ;(

      Reply ↓
    8. Peter's avatarPeter

      Crashplan just got updated to v4.2 and it stopped working on my DS415play. There’s not yet any update to the Crashplan synology package. Anyone tried doing the manual update on this? (there were some instructions floating around earlier (3.6->3.7 perhaps) including downbloading, unpacking and manually installing the proper jar-files. I’ve not tried to track that down this time (somewhat low on time this spring :()

      Ps. Thanks for helping provide a nice product on the Synologies :)

      Reply ↓
      1. B. Goodman's avatarB. Goodman

        I can confirm that I followed those instructions and in 5 minutes had my DS412+ CrashPlan working just fine!  I will add that my PC ‘front end’ had upgraded already to 4.2.  I’ve read that some people’s PCs were still on 3.7 and they weren’t able to get CrashPlan working again.

      3. ethan berke's avatarethan berke

        I updated to DSM 5.2 and the ability to download Crashplan disappeared. Only the Pro version remains.
        Was great on CP 3.7 but now on 4.2 and can’t download or get to run . Will have to wait for new version to appear – thanks Patters!

    9. News's avatarNews

      My Crash plan stopped working one day last week and I can’t get it to work again, it seems like it tries to update after installation and steppes after updating, when trying to manually run it shows attempting to repair update. I’m posting the log here and if someone could please help it would be greatly appreciated.

      I 05/19/15 11:56PM CrashPlan started, version 3.7.0, GUID 607185053101526678
      I 05/19/15 07:56PM Stopping CrashPlan
      I 05/19/15 11:56PM CrashPlan started, version 3.7.0, GUID 607185053101526678
      I 05/19/15 11:58PM Upgrades available at central.crashplan.com:443
      I 05/19/15 11:58PM Downloading a new version of CrashPlan.
      I 05/19/15 11:58PM Download of upgrade complete – version 1425276000420.
      I 05/19/15 11:58PM Installing upgrade – version 1425276000420
      I 05/19/15 11:58PM Upgrade installed – version 1425276000420
      I 05/19/15 11:58PM CrashPlan stopped, version 3.7.0, GUID 607185053101526678
      I 05/19/15 08:01PM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1425276000420.1432079895125
      I 05/19/15 08:04PM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1425276000420.1432079895125

      Reply ↓
  2. Brandon Rodkewitz's avatarBrandon Rodkewitz

    Crashplan through bootstrap stopped working for me several months ago, and I can’t seem to get your much easier method to work. Pretty sure I successfully removed any traces of previous versions. I’ve installed the syno Java Manager and the Crashplan package, stopped and started it, and rebooted just because. Java and Crashplan claim to be running but I don’t believe it. Can’t connect from client, ports aren’t open, there are no log files in the Crashplan package, or messages in the log manager. Any insight would be invaluable, I haven’t backed up in 4+ months. Everything’s up to date. DS1813+ DSM 5.1-5022 Update 3, Syno Java Manager, Java 7 update 75, Crashplan 3.7.0-0030. Could there be some other conflict with bootstrap?

    Reply ↓
    1. Brandon Rodkewitz's avatarBrandon Rodkewitz

      Solved this. May post about it on the syno forums.
      http://forum.synology.com/enu/viewtopic.php?f=190&t=93754#p355582
      I have bootstrap setup and the start-stop-status script in the Crashplan package sources /root/.profile. I’ve altered this to automatically start bash when I log in as root (rarely). Turned that off and everything is working as it should now.

      Thank you for this immensely helpful package. Have you considered posting the source code on GitHub so others can help contribute?

      Reply ↓
  3. My2Furballz's avatarMy2Furballz

    Hello Everyone…

    Before I lash out and buy a DS1515+ 5 Bay NAS, can I confirm that Crashplan is running OK on this model with the current Firmware?

    Thanks..!!

    Reply ↓
    1. nilrog's avatarnilrog

      Yes, i’m running CrashPlan on my DS1515+. In general it has been working fine, and it does so now again. But during the latest DSM update it stopped working. But after a restart, or killing an old process that was consuming a lot of memory, it started working again.

      Reply ↓
    2. AJ Willmer's avatarAJ Willmer

      Yes works for me as well. Synology Java 7 install, and patters’ Crashplan install. I run quite (very?) large backups and have increased RAM on DS1515+ and Java heap size (as you will see documented in various places here).

      Reply ↓
      1. Brandon Rodkewitz's avatarBrandon Rodkewitz

        I’ve also got a very large backup set. Have you changed anything besides the RAM allotment for java? I changed the data deduplication settings in my.services.xml as well, which gets me upload speeds that are many times faster.

        Sorry OP for hijacking. I’m on a DS1813+ so I can’t speak to the newer model, but I see no reason why it shouldn’t, and it sounds like your question’s been answered!

      2. AJ Willmer's avatarAJ Willmer

        Oops. I am on DS1513+ not DS1515+. Yes I too have changed advanced backup settings to minimal data deduplication and automatic compression. I can pretty much backup up at my full ISP up speed of 20Mb/s to ‘Friends’ CP servers.

    1. Brandon Rodkewitz's avatarBrandon Rodkewitz

      Thanks, this is very helpful! I’ll probably break out my data into backup sets when I’m uploading more than just my massive photo/video archive, so I have more finite control of versioning and whatnot.

      Setting deduplication to minimal had no affect for me. I had to actually change the XML node for “dataDeDupAutoMaxFileSizeForWan” to 1(byte), effectively turning it off. This bumped my upload speed from ~1.5Mbps to almost 40Mbps (on a 75Mb connection). Do you know if/how this affects the way data is stored on Crashplan Central?

      Why turn off compression for photo/video? I’m guessing it’s just that there’s not much gain for file types that are already compressed?

      Reply ↓
      1. AJ Willmer's avatarAJ Willmer

        Yes, the NAS’s are often CPU bound it seems. I have other tasks including video and audio streaming off the NAS, so although I have not A/B tested, I decided that there would little or no gain from compression of audio and video. Once I got to my full 20Mb/s UP bandwidth I stopped tweaking.

  5. vanardenne's avatarvanardenne

    I’m considering an upgrade to newer Synology to get things working again. I have an DS411 now and thinking of the DS415+. Is Crashplan working for other people with the 415+?

    Reply ↓
  6. Chuck's avatarChuck

    I purchased a DS1515+ to replace my DS413… I also upgraded to 6gb of RAM. I would like to change the memory allocation to at least 2048mb using vi (I have a 1.5tb crash plan archive to adopt). I telnet into the system as admin… make my way over to the syno_package.vars file and make the changes using vi but when I go to save, it says read only. I cannot figure out how people are changing this file. Any help would be appreciated.

    Reply ↓
    1. RAJ's avatarRAJ

      Hi Chuck… Try logging in as “root”, password should be the same as the admin password… Then try again. GL.

      Reply ↓
      2. Micah Cooper (@coopermj)'s avatarMicah Cooper (@coopermj)

        Actually, to provide additional information:

        Synology 1815+ with your Java 8 package. Installs and does initial run without a hitch. Can even restart it without a problem. When I connect with the desktop client, it performs an update and after that, it won’t start. Saw in the instructions to give it a bit, but even after waiting 24 hours, will not restart.

        If I ssh in and run
        /var/packages/CrashPlan/scripts/start-stop-status start

        I get the predicted error:
        /bin/ps: invalid option — ‘e’

        I think it’s coming from
        /var/packages/CrashPlan/target/upgrade/1425276000420.1431740353051/upgrade.sh

        But, when I switched -eo to w in that file, I get
        upgrade.sh: line 10: ../../bin/CrashPlanEngine: not found in upgrade.log

        And explicitly setting the path to CrashPlanEngine doesn’t help.

  8. Robert's avatarRobert

    Help needed. I have a Synology DS1511+ w/Intel Atom D525, 1GB ram DSM 5.1-5021 Update 2 running. I’m following the instructions… Enabled Home, Installed Java Mgr, installed Java version 1.7.0_51 which is running no problem. I tried next to install Crashplan and always get “Failed to install CrashPlan”…. Is anyone else having this problem? I can’t find any logs to reference why it is failing.

    Reply ↓
  9. Wes's avatarWes

    I can confirm it does not work with latest dsm 5.2 beta on ds413 ppc . It seems to hang on analyzing files.

    I can upload logs, but for now gonna see what others are seeing.

    Reply ↓
  10. Durando's avatarDurando

    Hello,
    Is anyone has kept the archive ot the 3.6.3 file? Because this version doesn’t exist anymore in download section. However, the 3.6.3 version is the last one which works with Synology DSM4.2 and inferior (I have a synology DS 209 and DSM 5 is not supported)
    Thanks

    Reply ↓
  11. Mark's avatarMark

    Here’s an update for those interested in how this package is working with the DS213j…

    My setup:
    DS213j
    DSM 5.1-5022 Update 4
    Java SE Embedded 7 (Patters) – 1.7.0_75-0031
    CrashPlan (Patters) – 3.7.0-0030
    Backing up 1.1TB to CrashPlan Central
    Receiving backups from 1 “friend” (16.4GB)

    Everything is working great. I was even able to upgrade from Update 3 to Update 4 without having to reinstall Java!!!

    Thanks again, Patters!

    Reply ↓
  12. michaelfanous's avatarmichaelfanous

    I have not been able to backup anything since March 19, not sure what happened or changed, but I am using the most recent DSM, most recent Code42 from Community Package to backup my DS1513+ It keeps stopping and shutting down. Have not been able to get it to work ever since. I have no memory issues either, checked that as well. Thoughts?

    Reply ↓
  13. sadler's avatarsadler

    I have a family subscription to Crashplan and a Synology 415Play. On one of my computers that are backed up to Crashplan, I edited the file conf/ui.properties so that the line: #serviceHost=127.0.0.1 was uncommented (by removing the hash symbol) and set to the IP address of my NAS. I have successfully started the backup of my NAS to Crashplan. My question is: Is my laptop still being backed up to crashplan? How can I check this?
    Do I simply undo the changes in the conf/ui.properties file to the original settings?
    Will that mess up the NAS backup to Crashplan?
    Thanks for the fantastic outline.

    Reply ↓
    1. patters's avatarpatters Post author

      Yes, because the CrashPlan Engine Service will still be running on your PC, regardless of what you’re connecting to with the management application. You can check this by logging into your account at crashplan.com and you should see the last activity of all the hosts you’re backing up.

      Reply ↓
  14. powderpig's avatarpowderpig

    Help! I have installed Java and CrashPlan on my 412+ synology but nothing happens. In the logs, it just starts and stops. Since CrashPlan can’t connect to the server, I can’t edit the config file to have it back up my synology. I’m not sure what to do. I’ve tested the ports and can “listen” to 4242 and 4243. I’ve tried updating the packages using ssh, but I get this error message:

    cannot find or open /var/packages/CrashPlan/target/upgrade/1388728800370.jar, /var/packages/CrashPlan/target/upgrade/1388728800370.jar.zip or /var/packages/CrashPlan/target/upgrade/1388728800370.jar.ZIP

    I’ve tried looking at the log file but get this error message:

    synology> /volume1/@appstore/CrashPlan/log/engine_output.log
    -ash: /volume1/@appstore/CrashPlan/log/engine_output.log: not found

    What can I do to get crashplan on my synology connecting to my server so that I can connect via my computer.

    I can get the client working (backing up my computer), but when I edit the config file for the IP address of the server (which is pingable) – specifically remove the hash, then it says unable to connect to the backup engine.

    Any ideas?

    Reply ↓
  15. powderpig's avatarpowderpig

    Help!

    I’ve installed Java and Crashplan on my 412+ synology, but it isn’t connecting to the server and (I think) that is why my computer can’t redirect the config file to the synology. Crashplan on synology just starts and stops and there is no activity in the log file via the web ui.

    On the computer, when I run the client and change the config file (change the IP address and remove the hash), it says that it is unable to connect to the backup server. The moment I remove the hash, it finds my computer, even though the IP address of the server (pingable) is in the config file.

    Trying to edit:

    unzip -o /var/packages/CrashPlan/target/upgrade/1388728800370.jar *.jar -d /var/packages/CrashPlan/target/lib/

    returns an “unable to find” error

    trying to find the output log returns an unable to find error as well

    The ports are open (4243) and I can “listen” to the synology through ssh.

    What can I do? Help!

    Reply ↓
  16. michaelfanous's avatarmichaelfanous

    Having difficulties for the last week….currently running the latest Java SE 7 u 75, the latest DSM 5.1 5022 Update 4, the latest Crashplan package from PC Load Letter, and the Crashplan app 3.7.0. No log errors, No memory errors, yet, the Crashplan app keeps starting and stopping and crashing repeatedly. I have already uninstalled everything and re-installed at least 3x so far. Still no luck…anyone have better suggestions????

    Reply ↓
  17. George's avatarGeorge

    Thank you for post on this. Have successfully installed Crashplan on my DS241se as my Crashplan server (my primary aim is to Diskstation use as backup destination for other systems), replacing a PC system. For others who have a similar aim, some comments on moving (as I did) existing archives to Diskstation to “seed” backups, so that you don’t have to redo lengthy backups onto the Diskstation.

    Take a copy of your existing backup archive directory on your current Crashplan server and copy to a shared drive on the Diskstation. This can be anywhere as it is temporary. You need to do this because you cannot access the crashplan shared folder (/volume1/crashplan/backuparchives) directly on the Diskstation, as it is owned by root and is not shared or visible in File Station. Do not mess with the permissions of this folder.

    Connect vis SSH as root (your Diskstation admin password is root password) and copy the backup archive directory from its temporary location to /volume1/crashplan/backuparchives directory. (note, I had trouble with move, hence copy). Once copied, you can delete from the temporary location.

    Now you can start the Crashplan client on the system you are backing up and start a backup to your Diskstation. It will recognise the archive you copied and verify the archive and not do a complete backup.

    Once you are happy that Crashplan is backing up to Diskstation, you can deactivate computer that used to be destination for your backup.

    Hope this helps.

    Reply ↓
    1. George's avatarGeorge

      A clarification on visbility of /volume1/crashplan/backuparchives – I have found that this directory is visible on an NFS share, so copy of backup archive to temp location may not be neccessary. I may have had a caching issue which delayed display of directory after installing crshplan on Synology.

      Reply ↓
  18. Crazy X's avatarCrazy X

    Hi there,

    I have one problem with the backups from my friends. I can’t change the Location. If I do that and click save I got ‘System Error : if problem persists re-install crashplan’.
    He remember the location, but allways uses ‘/volume1/@appstore/CrashPlan/backupArchives’.
    Have someone an idea? Many thx… It had costs me a lot of time and I don’t find a solution, very frustrating. THX

    Best
    Crazy X

    Reply ↓
  19. maxx's avatarmaxx

    Hi Patters,

    I Posted a couple of times back in February (included below). I am still unable to connect to crash plan. Sorry to ask but would you be able to offer any assistance?
    I am happy to provide any info required.
    Regards, and thanks for you time.
    max

    Post 1 – February 23, 2015 at 06:22
    I am in a similar situation as Chip. I have CrashPlan installed however I am not able to connect to the CrashPlan engine. I cant logon using the client configured to point to the servers ip address, and the clients cant connect to preform the back up. The service reports that it is running and there are no errors in the logs. I have two Synology servers both the same, on one it works (it has only one volume), on the other i have the problem (its has two volumes). It was previously working on both.

    I have tried reinstalling both java and the crashplan package. I have increased the memory as discussed. When comparing the one that is working and the one that is not, I notice that in the /volume1/@appstore/CrashPlan/log/app.log Under the License section it says ServiceModel.authorized=false. Could that be the problem or perhaps just because I have not reconfigure the engine since restarting?

    I also while logged on as root over ssh I tried to run this command to see the status but was given a security error.
    /var/packages/CrashPlan/scripts/start-stop-status status.

    Any advice how I can diagnose the issue preventing CrashPlan from loading correctly?
    I am considering removing the second volume to see if this is the cause.
    Regards, and thanks for the package.
    Post 2 – February 24, 2015 at 03:13

    I removed my second volume to see if it was causing the issue. I also removed (moved) my old archives and then reinstalled Crashplan. No change to the issue as described above. I also see the message WE have an old version, localVersion=1388728800370. However the working server is running the same version.
    I also see a some disconnections after this occurs.

    Reply ↓
  20. domgreener77176's avatardomgreener77176

    Hello, I am looking for a solution about Crashplan Client for windows. I have no way to run the client to my Nas Synology on windows. I try many time SSH tunneling – nothing works. It’s very strange because i have nothing to do with Crashplan Client for Mac, just an update in ui.properties where i put my nas @ and it works. On windows i try several time to do the same thing and it refuse to works. Of course i stop services into services.msc.

    Any idea to use Crashplan Client Windows as a simple client for Synology Crashplan server, i have no idea to solve it.

    Thanks in advance.
    Dom from Paris

    Conf :
    Server Crashplan
    Nas Synology Ds213+
    Client
    MacBook Air
    Crashplan Client for Mac os
    ui.properties modifiied
    Pc Windows 7
    Crashplan Client for Windows
    ui.properties modifiied
    Services.msc modified

    Reply ↓
  21. domgreener77176's avatardomgreener77176

    Hello, I wrote a comment yesterday about Windows Client for Crashplan and the fact that it won’t works on Windows as a simple client without any local active service. Then, I found the solution myself, it is very easy, the ui.properties included into Program Files is not the only one, you may find into AppData Folder of the local user another one ui.properties. This last file “is” the file you have to setup properly to access your Synology Nas.
    No need to change or set any tunneling through SSH if you ar only local, it works like that.
    I forget just one thing, we are on Windows 7 now and it is finished the time when you can have a simple OS and a very easy configuration to do.
    I was looking to find a solution to a friend of mine and this friend like Windows, I don’t know why, I am in love with Mac Os…

    It is why i am on Mac Os or Linux, its already easy to find and maintain a configuration staying stable long time.

    Great wishes for all.
    Best regards.
    @Greener77176

    Reply ↓
  22. phaedon1224's avatarphaedon1224

    I just want to throw this out there. I own a DS1813+ with about 24TB of HD space and an expanded 4GB memory on the Synology box. I am getting the distinct impression from Crashplan that ~1GB RAM allows for ~1TB of uploads. After which point, Crashplan starts to stall and then crashes.

    This is in fact happening to me, wondering if anyone else is running into the same problem. WTF.

    Reply ↓
    1. Brandon Rodkewitz's avatarBrandon Rodkewitz

      I have an 1813+ with 8x4TB drives, maxed out RAM, very similar setup. You are correct in that rough assumption, ~1GB RAM = ~1TB of data backed up to the CrashPlan Servers. If you haven’t yet, you should allocate more RAM to CrashPlan using patters’ package config file: /volume1/@appstore/CrashPlan/syno_package.vars

      Give Java HEAP more than 1GB but not not all 4 and definitely no more than that. Who knows what kind of ugly situation you’d run into if Java was trying to work in swap space.

      That will solve your problem at the 1GB ceiling, but if you were planning to backup a significant portion of your 24TB, you’ll probably be very disappointed with the service. CrashPlan does aggressive data deduplication on the client side which makes large backup sets horribly inefficient. They ignore all file names and folder structure, break your entire backup set into blocks, calculate a hash for each block, and check every block against every hash before sending anything to the cloud. 1TB of data ends up being about 1GB worth of hash values, all continuously stored in RAM. I confirmed with CrashPlan support that this is inherent to their software and there is no workaround. I’m currently using 90% of my RAM to backup 4.1TB and starting to look for a better solution.

      That said, I do want to say thanks again to patters for making this setup process so much less painful by way of a package. Getting his package up and running was a breeze compared to other older methods, and it’s been running flawlessly through several DSM updates (mostly security updates).

      Reply ↓

  23. Pingback: CrashPlan on a Synology DS214play | More Popcorn

  24. Bunjicat's avatarBunjicat

    Hi Patters. Is there support for MARVELL Armada XP MV78230 in the latest RS815? Expected soon? thanks for your work.

    Reply ↓
  25. Martijn's avatarMartijn

    Hi Patters,

    First off, great work on this package. Been using it for a while now. Unfortunately I’m running into the hybernation issue on my Synology. And although I’m using the start and stop scripts, HDD will not spin down, let alone the nas itself goes into hybernation.

    Is there any word on the ticket that is reported with code42?
    “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).”

    Reply ↓
  26. noirnet's avatarnoirnet

    Hi –

    I really love, and have been using with great success your CrashPlan installation on my Synology 1815+ monitored by the CrashPlan desktop app on Mac OS 10.10.3 So far, things have been running quite smoothly and as expected.

    However, for the last week or so, the CP desktop app keeps crashing, yet when checking on the Synology, it seems to be running just fine. Now CrashPlan Central has been sending me e-mails for the past few weeks claiming that it hasn’t been able to make any backups for the last 3 days. (several times now)

    Can I send you the ‘ui.log’ to see if we can get to the bottom of this? I really just want your excellent implementation to keep working like it was before!

    Many thanks in advance,

    – noirnet

    Reply ↓
  27. Phil Starke's avatarPhil Starke

    Like several others I have the issue of Crashplan stopping and starting after each file is backed up (I’ve broken my backups into 4 backup sets, 100s of GB each). I recognize the memory limitations of my DS414 (1 GB RAM) and understand that this is likely the result of the interaction between Java & Crashplan (not Patters’ amazing work – thank you!), but I notice that JAVA_HOME points to /volume1/@appstore/java8/ejdk1.8.0_33/linux_arm_sflt/jre. Earlier Crashplan directions here recommended using the *Hard Floating Point* “hflt” bundle (ejdk-8u33-fcs-linux-armv6-vfp-hflt.tar.gz at oracle.com) but Patters Java SE Embedded 8 only allows installing the *Soft Floating Point* “sflt” bundle. Could forcing the DS414 (which supports HardFP) to use the SoftFP be a contributor to my Crashplan start/stop loop condition? If so, might I ask, Patters, if your Java 8 package might be modified to allow hflt?

    I’m running DSM 5.1, Crashplan (3.7.0-0030), Patters Java SE Embedded 8 (1.8.0_33-0031), and ejdk-8u33-fcs-linux-arm-sflt.tar.gz on a DS414.

    Reply ↓
    1. patters's avatarpatters Post author

      It’s been a while now so it’s hard to recall for certain, but I’m fairly sure I already tried the HardFP Java build on those systems and Java wouldn’t run.

      Reply ↓
    2. Brandon Rodkewitz's avatarBrandon Rodkewitz

      I can’t comment on hard vs soft floating point, and patters has already chimed in. However, if your problem is indeed being caused by a lack of RAM, it’s worth noting that breaking your data into backup sets and scheduling them at different frequencies/times will have no affect on RAM usage. Data deduplication happens across the entire sum of data you’re backing up using your account, regardless of which backup set it’s working on at any given time.

      Reply ↓
      1. B. Goodman's avatarB. Goodman

        What happens if you turn off the data deduplication, which I believe I’ve read is possible. (Thought I haven’t attempted to confirm.)

      2. Brandon Rodkewitz's avatarBrandon Rodkewitz

        It is possible, but does not reduce RAM usage. The GUI has dropdown options for “how much” deduplication to do. This corresponds to lines in the my.services.xml file:

        1000000000
        1000000000

        Your numbers in here may vary. The Wan setting here is the largest file size (in bytes) that the engine will check against its hashes before sending to the cloud. 0 = infinity, or any file size. 1 = 1 byte, effectively turning deduplication off.

        This dramatically increases your upload speed because the CrashPlan engine stops checking every data block against the entire hash table before sending things over the network. After 24 hours of my first backup I was at 1Mbps and slowing. Making this change instantly took my upload speed to 36-42Mbps depending on the time of day. I’m on an 80Mbps pipe.

        Unfortunately while this will make it possible to upload a large backup set in a reasonable amount of time, it doesn’t stop CrashPlan from generating hashes of your entire backup set and storing them in RAM. I fully understand what they’re going for with the deduplication process, but in practice it completely cripples the software. They should do minimal checks (like file name/modification time) before sending, and do their own block-level deduplication on their end.

        Note: IIRC I’ve only tried turning off the WAN setting because I manage local backups outside of CrashPlan. Maybe setting both to 1 byte will stop the engine from building the hash tables? Might be worth a try.

  28. Brandon Rodkewitz's avatarBrandon Rodkewitz

    Oy, that xml didn’t paste correctly. It’s supposed to be:

    dataDeDupAutoMaxFileSize 1000000000 dataDeDupAutoMaxFileSize
    dataDeDupAutoMaxFileSizeForWan 1000000000 dataDeDupAutoMaxFileSizeForWan

    …with tag symbols

    Reply ↓
  29. Jon's avatarJon

    Will your latest package work with a 64-bit JDK on Intel-based NAS? I was using CrashPlan with a 32-bit JDK fine, then realized that I need to set the max heap > 4096M due to the size of my volume–which obviously doesn’t work with a 32-bit JDK.

    So I removed the 32-bit JDK, installed a 64-bit JDK using Synopsys Java Manager (I had to rename the downloaded file to indicate i586, but it installed fine), then completely removed the CP package and reinstalled it. The hope was that it would recognize the 64-bit JDK and auto-configure itself appropriately.

    My laptop’s CP client connects to the CP engine on the NAS (after editing ui.properties), but it refuses to get past “waiting for backup”. A quick look in the engine_error.log on the NAS indicates that it couldn’t find com.code42.jna.inotify.InotifyManager. I suspect that it is trying to use the 32-bit JNI libs, and the 64-bit JVM doesn’t like that.

    Before I invest more time into what might be a dead end, I’m hoping you can clarify whether it is even possible to use your CP package with a 64-bit JDK.

    Reply ↓
    1. patters's avatarpatters Post author

      Not sure, and unfortunately I can’t check – I only have an i686 system (evansport). I think it may work if you use all the Linux binary libraries that CrashPlan supplies, rather than my modified ones. To stop my scripts from breaking stuff, copy the clean jna-3.2.5.jar from say a Windows CrashPlan/lib folder into /volume1/@appstore/CrashPlan/bin (not lib). My script takes this one and copies it over the one in lib each startup.

      Then I believe you’ll need to find yourself a copy of libffi.so.5 for amd64 architecture and that will need to go in /lib on your NAS. Your NAS should only have /lib/libffi.so.6 by default, my modded jna-3.2.5.jar uses this one you see. Here’s one I’ve extracted from Debian Wheezy for amd64. Let me know if it works.
      https://dl.dropboxusercontent.com/u/1188556/libffi5_amd64.tar.gz

      Reply ↓
      1. Jon's avatarJon

        Thank you very much, that does seem to work!

        For posterity, here’s what I did:

        1. I installed a 32-bit JDK using the Synology Java Manager, and then installed the CrashPlan package. Things were working fine.
        2. I stopped the CrashPlan package on the NAS
        3. I downloaded a 64-bit JDK from Oracle (jdk-7u79-linux-x64.tar.gz)
        4. I renamed the JDK, replacing “x64” with “i586” so the Java Manager would accept it
        5. I upgraded my Java install using Java Manager, specifying the jdk-7u79-linux-i586.tar.gz from steps 3 and 4
        6. I renamed jna-3.2.5.jar in /volume1/@appstore/CrashPlan/bin on the NAS, to jna-3.2.5.jar.orig
        7. I copied jna-3.2.5.jar from C:\Program Files\CrashPlan\lib on my Windows PC to /volume1/@appstore/CrashPlan/bin on the NAS
        8. I downloaded the libffi.so.5 from your Dropbox, extracted it from the tarball, and copied it into /lib on my NAS (that’s really “/lib” from the root directory, not under /volume1/@appstore/CrashPlan)
        9. I changed my heap size to be > 4096 in /volume1/@appstore/CrashPlan/syno_packages.vars
        10. I started the CrashPlan package and things seem to be working well

        I did try starting the package after step 7 (i.e. before installing libffi.so.5), and it started fine. It didn’t allow me to start a backup, though, so I thought it wasn’t quite working properly. At that point, I stopped CrashPlan and did steps 8-10. After I changed some files on the NAS, I was able to do a backup. I didn’t think to change files after step 7, so it’s possible that things would have worked without libffi.so.5. I mention that because you stated that your modded jna-3.2.5.jar uses libffi.so.5, but I believe that I removed your modded jna-3.2.5.jar in step 7.

      2. patters's avatarpatters Post author

        The stock jna-3.2.5.jar contains libjnidispatch.so which depends upon libffi.so.5.
        My jna-3.2.5.jar contains a newer libjnidispatch.so which depends on libffi.so.6 which is included in DSM 5.0 onwards. This prevents my CrashPlan package having to mess with the /lib folder (older versions did) which is not desirable and could conceivably result in a broken NAS. Normally I’d compile my own libjnidispatch.so and set RPATH to force it to look for dependent libs in a relative path but I found it very difficult to successfully compile for some of the architectures, so I gave up and used a pre-made Debian binary for this lib. I still can’t get a working one for PowerPC – I have tried literally dozens of versions and none of them allow CrashPlan’s inotify support to work.

        Looking at my jar file it looks like I did include an amd64 build of libjnidispatch.so as a precaution, so you can get rid of the stock one and revert back to using the .jar.orig one. Then you should be able to delete /lib/libffi.so.5.

        So I guess that means the answer to your original question is: Yes – the CrashPlan package in its unmodified state does support a 64bit JRE, as long as you can install it. I presume this is a full JRE not the Java for Embedded which I package up?

      3. Jon's avatarJon

        Correct, I used the standard, full JDK from Oracle rather than the embedded version (which I believe is limited to 32-bit).

        Simply installing the 64-bit JDK did not work, however. In that case, I would get the error about InotifyManager. For what it’s worth, your jna jar is much smaller than the stock:

        -rw-r–r– 1 root root 946973 May 6 09:31 jna-3.2.5.jar
        -rw-r–r– 1 root root 179284 May 6 09:30 jna-3.2.5.jar.orig

        Maybe I got a package without the amd64 .so, or I’m missing some glue that lets the package choose the right one. In any case, I’m happy to stick with the stock jna jar and v5 libffi, as that seems to be working now.

        Thanks again for your help and for making the package available in the first place.

      4. patters's avatarpatters Post author

        I made it smaller just by getting rid of all the architectures I know we don’t need (BSD, Mac OS etc.). Rename a copy of the Windows stock jna-3.2.5.jar from .jar to .zip and you’ll see what I mean. Odd that the amd64 lib in my jar file doesn’t work, since I would have pulled it from the same newer Debian package as the i386 one. I’ll check its dependencies tomorrow.

  30. Pingback: Installing CrashPlan on a Synology DiskStation - S^2 Blog

  31. Stephen's avatarStephen

    My Crashplan installation just stopped seemingly due to an update pushed out by Crashplan. I followed the steps that had previously been given when an update caused it to break but adjusted them for this release. I’ve copied them below incase anyone else experiences the same issue. You’ll need to be logged in as admin or sudo before the commands and in the final mv command you will need use the result from the ls command which will be a series of numbers:

    unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar *.jar -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar run.conf -d /var/packages/CrashPlan/target/bin/
    unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar lang/* -d /var/packages/CrashPlan/target/

    ls -l /var/packages/CrashPlan/target/upgrade/1425276000420.*
    mv /var/packages/CrashPlan/target/upgrade/1425276000420.LS_RESULT/upgrade.sh /var/packages/CrashPlan/target/upgrade/1425276000420.LS_RESULT/upgrade.sh.old

    Reply ↓
    1. scornelius1's avatarscornelius1

      PLEASE DONT FOLLOW THESE STEPS.
      I’ve just seen that one of the commands doesnt complete which will cause the fix not to work properly

      Reply ↓
      1. scornelius1's avatarscornelius1

        Might have jumped the gun, after a restart Crashplan is now working fine and is showing the new correct version number (4.2.0)

    2. Atrus's avatarAtrus

      A few comments on this:

      The run.conf line doesn’t work (says file can’t be found), but the upgrade was still effective. So this line can probably be skipped?

      The first time I tried this process, it did not work. Crashplan would start and stop right away but not print anything in the log file. I uninstalled Crashplan, reinstalled, let it download the update again, did the SSH commands all over again, and it worked the second time.

      Reply ↓
  32. Troy's avatarTroy

    The first line you have to be in the crashplan directory to execute properly. The second line does not execute properly.

    unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar run.conf -d /var/packages/CrashPlan/target/bin/

    Reply ↓
  33. troy's avatartroy

    Stephen – I ran your commands above and the line with the run.conf doesn’t execute right. After i figured out what you meant by the last line by moving the upgrade.sh to upgrade.sh.old in the upgrade directory, I was able to get the Crashplan engine to start again but the version still shows 3.7.0 on mine.

    Reply ↓
  34. troy's avatartroy

    I take it back. If you look in the log file it shows 4.2.0, but on the package center tab it says 3.7.0. I apologize. I still wonder why that second line with run.conf gives that error. Maybe it’s because you took that command from a previous patch and there was a run.conf in the .jar file but with this latest update there isn’t one.

    Reply ↓
  35. jeff's avatarjeff

    Ive been using CP successfully since I got my 2415+ in march…..until an automatic upgrade that happened today… after, i cant start the app on my nas…. i checked the log files and see where the app updated itself today and restarted. The last line reads “5/11/15 Synology repairing upgrade in /var/packages/Crashplan/target/upgrade1425276000420.1431371749366”.

    I have hardbooted it and tried 4-ish times to restart the CP package & it fails everytime.

    I am not a linux guru and actually a n00b, but am trying. Any ideas guys?
    -a big thx to all the contributors for sharing their knowledge…

    Reply ↓
  36. BC's avatarBC

    DS213 w/Marvell Processor. Upgraded to DSM 5.1-5022 Update 5, and CP died. Fixed/upgraded the entire setup with thanks to a combination of Stephen and Troy’s comments above:

    1. Package Center settings – Enable any publisher. (had done this before, but guessing the DSM update reset these permissions)
    2. Updated Java package (in my case, actually uninstalled and moved to Java 8). Also had to deal with the file save bugs in Chrome. (Make sure to use “.tar.gz”)
    3. Upgraded CP package
    4. Still wasn’t working… CP log showed Crashplan’s recent upgrade causing shutdown (Just like Stephen!).
    5. Manually extracted and renamed using Stephen’s scripts (after editing thanks to Troy’s comments).

    Stable so far, files synchronizing, finger’s crossed.

    Reply ↓
  37. Walti's avatarWalti

    I did the above steps, and now crashplan is running. But, major problem, now i cn’t restore anything for NONE of my computers: the only message I get back from crashplan client is “incorrect archive encryption key”. WTF?

    Reply ↓
  38. stereimannStefan's avatarstereimannStefan

    Hi,
    great Job! but now i have a start issue. All worked fine with v3.7.0030 but since yesterday crashplan does not start anymore. I read this thread but ist still dont know what is the right workaround?

    pls help ;)

    Reply ↓
  39. Stephen's avatarStephen

    I’m not too sure about the run.conf part of the command but the file doesnt seem to be there so can be safely removed. My Crashplan has been up and running for 12hrs now so all looks fine. The package center version number will be updated when a new version is released by Patters but I think this is a suitable workaround until then and means he doesnt have to rush to get a fix out

    Reply ↓
  41. Mike S's avatarMike S

    This AM I noticed that there was an update to DSM 5.2-5565 that was released on Match 11, 2015. Before I did the update, I checked my CrashPlan to make sure it was running and noticed that it was not. Apparently early this morning (March 12th, 2015) it automatically updated itself to v4.2 and would not load. I used the guide at https://miketabor.com/install-crashplan-synology/ under “Fix, Crashplan on Synology won’t start”

    but had to change a few commands to the below:

    unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar *.jar -d /var/packages/CrashPlan/target/lib/

    unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar upgrade.sh -d /var/packages/CrashPlan/target/bin/

    unzip -o /var/packages/CrashPlan/target/upgrade/1425276000420.jar lang/* -d /var/packages/CrashPlan/target/

    ls -l /var/packages/CrashPlan/target/upgrade/1425276000420.*

    1425276000420.YOURVALUE:

    mv /var/packages/CrashPlan/target/upgrade/1425276000420.YOURVALUE/upgrade.sh /var/packages/CrashPlan/target/upgrade/1425276000420.YOURVALUE/upgrade.sh.old

    Everything seems to be running fine now. Hope this helps anyone else.

    Reply ↓
  42. Tazmanian's avatarTazmanian

    Hello, since update to DSM 5.2 Crashplan doesn’t start anymore. Anyone that can help?

    Reply ↓
  44. Mike Mitchell (@fmagic1)'s avatarMike Mitchell (@fmagic1)

    I have a DS413 and I noticed my CrashPlan package stopped running. I updated the package, and it started running again. Then, I noticed my DSM needed an upgrade from 5.1 to 5.2, so I performed that upgrade. Now, the CrashPlan package will not start. If I look in the log, it looks like CrashPlan started an automatic upgrade, and that broke it. Is there any way to resolve this without removal and reinstallation of the package? Also, a secondary question, does CrashPlan work with Java 8, or do I need to continue using Java 7?

    Reply ↓
  46. Pepijn's avatarPepijn

    It seems Crasplan updated the application yesterday and the package stopped working. The package log says: “Synology repairing upgrade in …” Anyone experiencing similar issues?

    Reply ↓
  47. pagocs's avatarpagocs

    The workaround solved the CrashPlan starting issue for me as well (on DSM 5.2). The version number remain the old in the DSM package center but this is normal I guess because not the installed package was updated.

    Anyway, anybody know how can be disabled CrashPlan built-in auto update function?

    Reply ↓
  48. Alan's avatarAlan

    Found Crashplan was stopped on DS214play+ server running 3.7.0-0030. The log says:

    I 05/12/15 03:28PM CrashPlan started, version 3.7.0, GUID 666742672830497028
    I 05/12/15 03:28PM Upgrades available at central.crashplan.com:443
    I 05/12/15 03:28PM Downloading a new version of CrashPlan.
    I 05/12/15 03:28PM Download of upgrade complete – version 1425276000420.
    I 05/12/15 03:28PM Installing upgrade – version 1425276000420
    I 05/12/15 03:28PM Upgrade installed – version 1425276000420
    I 05/12/15 03:28PM CrashPlan stopped, version 3.7.0, GUID 666742672830497028

    The upgrade log says, upgrade.sh: line 10: ../../bin/CrashPlanEngine: not found in many places.

    I uninstalled and reinstalled the package and got the same results. Any ideas how to fix it? I have the latest upgrades from Synology and all my packages are up-to-date.

    Thanks,
    Alan

    Reply ↓
    1. Stephen Cranfill's avatarStephen Cranfill

      Thanks, Chris! Your instructions worked like a charm for me! I just had to substitute “CrashplanPRO” for “Crashplan” since I’m running the PRO variant.

      Cheers,
      Stephen

      Reply ↓
      1. Jim's avatarJim

        Thanks for the link chrisn, It fixed mine, and the tip Stephen for substituting Crashplan with CrashplanPro. Now to update my pc side of it.

      2. fred's avatarfred

        Fixed worked great!! Also if you are using CrashplanPROe same idea with changing the name in the path

    4. cowboyGeek's avatarcowboyGeek

      Thanks Chris! This worked for me, as well.

      However, now I’m having problems with all the friends that back up to my Synology. I get “Not ready for backup from . Reason: The destination is not available.” I have issued this command, which fixed this issue in the past:

      chmod -R 777 /volume1/Backups/Friends/

      Clearly I have no clue what I’m doing. Can someone help?

      Reply ↓
      1. cowboyGeek's avatarcowboyGeek

        Clarification…the error reads:

        “Not ready for backup from [friend’s name]. Reason: The destination is not available.”

      1. RobB's avatarRobB

        Thanks Chris! Life saver – running DSM 5.2-5565 on DS713+ and your instructions were spot on.

      1. Anwar's avatarAnwar

        Dino. Just ran those commands a few minutes ago and CrashPlan seems to be running for the first time in over a week!

        Very much appreciated!!

    10. Shmuly's avatarShmuly

      Ran the instructions. Crashplan said it started. But there were no log entries. After a few minutes it stopped. The only log entries are the “repairing…” ones.

      Reply ↓
  50. ahershler's avatarahershler

    In view of this latest CrashPlan upgrade issue I just wanted to point out that I did not have to run any special commands after the latest upgrade. I am running DSM 4.3-3827 Update 8 on a RS3411xs with 8 GB RAM. Patters CrashPlan package version in Package Center is reported as 3.6.3-0027. As with earlier upgrades, all I needed to do on the server was to manually start, stop and restart the package. On the client I had to download and install the new CrashPlan version, stop and disable the local CrashPlan service and reconfigure the client to connect to the server.

    Here are the relevant lines from the log. Note that the upgrade installed on May 11 at 10:15 PM and CrashPlan was stopped until I dealt with it on May 13 at 12:30 AM. All I did on the server was start, stop, start:
    I 05/11/15 10:15PM Upgrades available at central.crashplan.com:443
    I 05/11/15 10:15PM Downloading a new version of CrashPlan.
    I 05/11/15 10:15PM Download of upgrade complete – version 1425276000420.
    I 05/11/15 10:15PM Installing upgrade – version 1425276000420
    I 05/11/15 10:15PM Upgrade installed – version 1425276000420
    I 05/11/15 10:15PM CrashPlan stopped, version 3.7.0, GUID XXXXXXXXXXXXXXXXXX
    I 05/13/15 12:30AM Synology repairing upgrade in /volume1/@appstore/CrashPlan/upgrade/1425276000420
    I 05/13/15 12:30AM CrashPlan started, version 4.2.0, GUID XXXXXXXXXXXXXXXXXX
    I 05/13/15 12:30AM Backup scheduled to always run
    I 05/13/15 12:32AM CrashPlan started, version 4.2.0, GUID XXXXXXXXXXXXXXXXXX
    I 05/13/15 12:32AM Backup scheduled to always run
    I 05/13/15 03:00AM [My Backup Set] Scanning for files to back up

    All I can add is: patters, your package rocks! Thanks again!

    Reply ↓
      1. ahershler's avatarahershler

        It looks similar but there are some more questions to answer:
        a. What model Synology?
        b. What version of DSM are you running?
        c. How much memory do you have installed?
        d. What version of Patter’s package do you have installed (look in Package Center)?
        e. What version of Java do you run?
        My guess is that only if all of the above are the same for you, is my experience relevant to you.

    2. Brad's avatarBrad

      Seriously? I cannot restart the package after it stops and I get the message, Synology repairing upgrade in var/packages/CrashPlan/target/upgrade/1425276000420. Do I need to restart my diskstation?

      Chrisn instructions work, but version 4.2 chews up memory like a hog and seriously slows down my diskstation. big bummer. I’m not sure what to do, I liked crashplan when it wasn’t monopolizing my memory to the extent that the new version seems to, now I’m not sure if I want to continue with the crashplan backup at all.

      Reply ↓

Leave a reply to ahershler Cancel reply