CrashPlan packages for Synology NAS

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. Peter's avatarPeter

    I have a Synology 716+ running DSM 6.0 Beta 2. I just successfully installed crashplan 4.5.2 by first installing the built-in Synology ‘Java 8(beta)’ package, 1.8.0_60 with a default CLASSPATH of /var/packages/Java8/target/j2sdk-image/jre and then installing Crashplan from http://packages.pcloadletter.co.uk. Everything worked on the first try. I’ll post if I find any issues.

    patters — I’ve been using your crashplan packages for years, you have helped so many people out by providing these packages and by staying on top of so many updates. Thank you!!

    Reply
    1. swynth's avatarswynth

      I have a DS213+ and have used CP for a couple of years but the recently as it’s been so intermittent at working I started looking at doing it via Windows PC. I haven’t got that far, but I’ve seen a few people have a bit of success lately – is it worth me moving back to running on the NAS?

      Reply
      1. goslow2gofast's avatargoslow2gofast

        Naturally this is somewhat of a personal decision, but I was in the exact same place myself about 4 months ago. I had been running CP on my DS413 for a while and it was working okay. But then there were a few months of turbulence when a new version of CP or DSM would upset the balance and I had to wait for a fix or poke at it until it worked again. It feels like that has continued since then also. So I decided to move the backup engine to a Windows 10 machine, and back up the NAS from there. That has been running without a problem since then, with no problems over several CP updates, etc. I think the throughput is even higher than I was seeing off my NAS. So I’m not saying it can’t be done natively on the NAS, but it’s clear Synology and CP have no plans to get a supported version there, so it will continue to be “crowd supported”. Thank goodness for patters and others who are lending a hand, but without them it would be a struggle. So while part of me wants to accept the challenge of running it right on the NAS, another part of me is more than happy to spend the time I was spending on keeping it going in other areas, and knowing that my backups are running every night uninterrupted. I’m not saying anything bad about Synology, CrashPlan, or patters and all the helpful people here, just sharing my situation, decision and results in case it helps you.

      2. swynth's avatarswynth

        Thanks for info. How did you set the folders to backup on the PC? I’ve tried a couple of methods and it always seems to say ‘missing’.

      3. goslow2gofast's avatargoslow2gofast

        All I did was map a drive to a NAS share where the files are I want to backup, and made it persistent so it is preserved across Windows restarts. Then in CrashPlan Desktop app referenced the mapped drive.

    2. doezel's avatardoezel

      I noticed that crashplan now doesn’t correctly see that a folder is updated:

      Although some files changes almost every minute, crashplan doesn’t detect these changes anymore since I upgraded from 5.2 to 6.0 rc.

      Is this a known issue? Should I refresh something? Restarting the Crashplan service on the Synology didn’t resolve this.

      Reply
  2. Ian's avatarIan

    Just installed the latest DSM update DSM 5.2-5644 Update 3, and Crashplan has uninstalled itself… its not in my list of installed packages and if I go and look in the Community feed its there to be installed.

    Does this mean I need to do m y entire 3TB backup again?!

    Reply
    1. bertxl's avatarbertxl

      no, your backup is linked to your CP account/machine and not to your installation. After you’ve reinstalled CP and logged on again, it should recognize the machine and restart the backup from where it was. If it does not, you can tell it to do so by selecting the option ‘Adopt backup from a different machine’ (even if it is the same machine)

      Reply
      1. rich's avatarrich

        This is my experience as well.. the only other point to mention is it may need to re-scan everything. so for a while (maybe a day if you have a big file set) it can look like it is doing a backup

    2. Ian's avatarIan

      OK thanks. I have just tried to install it again. It error’ed asking me to manually download the file and place it in the ‘public’ directory. So I made a ‘public’ shared folder, gave all users access to it and then tried again, which worked. Back up and running :)

      Reply
  3. James Coleman-Powell's avatarJames Coleman-Powell

    I’m also a long term user of your packages – thank you so much for your contributions. I have an issue currently however, CrashPlan seems to have gotten itself in a bit of a muddle, in a cycle of:

    CrashPlan Started, Version 4.5.2
    Scanning for files to backup
    Backup Schedule to Always Run
    Starting Backup to CrashPlan Central
    Stopping CrashPlan

    It happens every single minute. I don’t recall whether 4.5.2 is a recent release and perhaps I should be looking to roll it back to an earlier?

    Any ideas / thoughts would be appreciated!

    Reply
  4. James Coleman-Powell's avatarJames Coleman-Powell

    Is anyone seeing a restart loop on the most recent release of Crashplan? Mine Starts, starts scanning the files, starts the backup and quickly crashes. There are no clues in the logs and I’ve been a long standing user of the package so I know the initial configuration is good. Any ideas?

    Reply
    1. C's avatarC

      I have the same symptoms but I’m seeing disconnects. I also updated the Java package so I’m not sure whether that has something to do with it (maybe SSL is disabled or something like that).
      However looking back, likely the fault lies with Crashplan.

      Reply
      1. James Coleman-Powell's avatarJames Coleman-Powell

        I can confirm that raising the RAM allocation has fixed this, give it a try and hopefully it will work for you too.

      2. C's avatarC

        In my case it looked like the old process was still running so the two kept tripping on each other.
        Discovered that by looking into the console and killing the old one.

  5. Yvonus's avatarYvonus

    Allow me to thank you for your work. Knowing that an “easy” CrashPlan solution was available was one of the key parameter to dump my old, unsupported Windows Home Server, to a Synology box.
    I’ve decided to try the Java Download Manager which looked easier to install to me. Only later did I notice that you built custom off-the-shelf java packages.
    Sadly, the crashplan package installation failed. I’ve taken a quick look at synopkg.log, which shows a clear cut error condition soon after the install begins :
    http://pastebin.com/vXMA2uq0

    2016/01/31 15:11:09 (system) trigger :
    Begin: /bin/tar xf /volume1/@tmp/@synopkg/@download/CrashPlan/@SYNOPKG_DOWNLOAD_CrashPlan -C /volume1/@tmp/56AE15FDA6D70304/ conf –no-same-owner
    /bin/tar: conf: Not found in archive
    /bin/tar: Exiting with failure status due to previous errors

    Any idea why this is happening ?
    Thanks for your help.

    Reply
  6. sebas's avatarsebas

    Somehow Chrashplan no longer connects to my Synology after updating both to 4.5.2. I’ve changed the token like after any update, but it just won’t connect. It looks like the port has changed to 4253 instead of 4243. I’ve changed that as well in both the ui.info and properties file, but that makes no change. Any ideas?

    Reply
      1. reuven's avatarreuven

        I had a similar problem, i fixed it by appending the actual i.p. address to the authentication token, instead of the 0.0.0.0 that was there. Don’t know why that worked but it did.

      2. Greg's avatarGreg

        I did too. Mine changed to 4273. Does the serviceport need to be changed in the ui.properties file to 4273? I can’t connect. .ui_info file matches NAS.

  7. Stoepsel2k's avatarStoepsel2k

    Hi there, i want to use CrashPlan for the first time.

    I have an DS415+
    Installed Java 1.7_79 and CrashPlan 4.5.2 on my Synology. I restartet the CrashPlan App 3-4 times.
    I installed CrashPlan 4.5.2 Client on my PC and changed .ui_info with the correct token and IP-Adress of my synology. I changed my ui.properties as well with the correct Synology IP-Adress.
    I added CrashPlan to the Firewall of Synology for testing.

    If i want to connect by the client on my pc, the client freeze and after a while i get an error with connection failed.

    My service log:

    Connectivity testing localhost, port=4242, connectionTimeout(ms)=100, retryDuration(ms)=100
    Failed to connect after duration=522, retryDuration=100, address=localhost, connectTimeout=100, e=null
    Connectivity testing localhost, port=4243, connectionTimeout(ms)=100, retryDuration(ms)=100
    Connectivity test done. localhost, false in 197 ms
    Connectivity testing localhost, port=4244, connectionTimeout(ms)=100, retryDuration(ms)=100
    Failed to connect after duration=690, retryDuration=100, address=localhost, connectTimeout=100, e=Connection refused
    Loaded address=0.0.0.0, port=4243, and token from location=/var/lib/crashplan/.ui_info
    MessageProvider(): options=MessageProviderOptions[name = UI, numWorkers = 2

    READY! Listening ports are PEER=4242, CPD=4243, HTTP=4244

    WE have an old version, localVersion=1435726800452 (2015-07-01T05:00:00:452+0000), remoteVersion=1446267600512 (2015-10-31T05:00:00:512+0000), remoteGuid=42

    Please, anyone who can help ?

    Reply
    1. patters's avatarpatters Post author

      Looks like a version mismatch somewhere:

      WE have an old version, localVersion=1435726800452 (2015-07-01T05:00:00:452+0000), remoteVersion=1446267600512 (2015-10-31T05:00:00:512+0000), remoteGuid=42

      Reply
  8. Alex's avatarAlex

    When I add your repository to the package sources I can see Java Manager but not CrashPlan.
    I tried this on three different DiskStations.
    How can I go about to debug and resolve this?

    Reply
    1. patters's avatarpatters Post author

      Java Manager is not my package. Mine are simply called Java 7 and Java 8. Are you sure you are looking at the Community section as indicated?

      Reply
      1. Alex's avatarAlex

        Oh wow, you’re right!
        I first tried your packages several months ago where they showed up under all.
        Also, I was under the impression that “All” actually meant everything.
        That nothing shows up when I search for crashplan, no matter what is selected, does not help either…
        Anyway, the package shows up under Community and I’ll try to install it later.
        Thanks a lot!

  9. ccanzone's avatarccanzone

    Hello,
    Once more the update failed. At first I’ve tried to use the unzip technique (that always worked) but this time it didn’t. Then I tried to upgrade through Package Center, and the wget got stuck when the file size was 33963774 (CrashPlan_4.5.2_Linux.tgz). Replacing wget did not work this time, neither manually downloading the file in the Public share.
    Regarding this Public share, a bunch of questions:
    – I created it in /volume1/public and gave read-write access to everyone
    – The correct name is Public or public? I did the latter
    – Out of despair, I chowned the directory with 777. Even this didn’t work.

    I wonder how the “download to Public share” does work, so I can check if I did something wrong.

    So, no CrashPlan for me so far. Any ideas?

    Thanks to everyone!

    Reply
  10. Peter Story's avatarPeter Story

    Hello! Any plans to add support for the new DS416j? I’m assuming your package doesn’t list it as supported, because you write: “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.”

    Reply
    1. patters's avatarpatters Post author

      Correct assumption – it’s a new SoC (Marvell Armada 388) which is a dualcore ARMv7 with NEON. So that I can add support, please can you log in via SSH and run:
      uname -a
      cat /proc/cpuinfo

      and post the results back here. Thanks

      Reply
      1. Nick's avatarNick

        Thank you so much for the work that you do. I have a new DS416J and here is what I get. Let me know if I screwed something up as SSH and terminal are not my best.

        “uname -a”

        Linux njn 3.10.35 #5644 SMP Thu Nov 12 17:16:22 CST 2015 armv7l GNU/Linux synolo gy_armada38x_ds416j

        “cat /proc/cpuinfo”

        processor : 0
        model name : ARMv7 Processor rev 1 (v7l)
        BogoMIPS : 2655.84
        Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
        CPU implementer : 0x41
        CPU architecture: 7
        CPU variant : 0x4
        CPU part : 0xc09
        CPU revision : 1

        processor : 1
        model name : ARMv7 Processor rev 1 (v7l)
        BogoMIPS : 2655.84
        Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
        CPU implementer : 0x41
        CPU architecture: 7
        CPU variant : 0x4
        CPU part : 0xc09
        CPU revision : 1

        Hardware : Marvell Armada 380/381/382/383/384/385/388 (Device Tree)
        Revision : 0000
        Serial : 0000000000000000

  11. hyperion's avatarhyperion

    For those with the repeated restart problem, it was a memory heap size issue for me. Edited the file at /var/packages/CrashPlan/target/syno_package.vars and make sure to uncomment the field, too! I used VI, read instructions here:

    https://www.cs.colostate.edu/helpdocs/vi.html

    It’s really easy, I changed it to 2048. Then just stop and start the service through the web interface. Works great on my 1518+.

    -hyp

    Reply
  12. Onward 123 (@onward123)'s avatarOnward 123 (@onward123)

    Hello. I am having an issue installing CrashPlan and hoping you can provide some guidance?

    I have followed Scott Hanselman’s instructions (http://www.hanselman.com/blog/UPDATED2014HowToSetupCrashPlanCloudBackupOnASynologyNASRunningDSM50.aspx) carefully through step 3 (installing Java). When I go to to install CrashPlan, I accept the license agreement, click Next, then Apply, and the Installing… dialog appears for a second or two and then is replaced with an error dialog that says “Failed to install CrashPlan.”

    Suggestions? What am I missing? Thanks in advance. (Hardware: DS214+)

    Reply
  13. firehorse's avatarfirehorse

    Thank you so much patters for all your excellent work. With the recent changes by Crashplan and after re-establishing the connection again and again with your help and the help of the community, I decided to cancel my subscription with Crashplan and told them, that their way of NOT supporting Synology is IMHO a wrong one. Thanks again for your efforts!

    Reply
  14. All Pinky, No Brain's avatarAll Pinky, No Brain

    I’ve gone through the instructions, and have got to the bit where I’m asked to edit the .ui_info file – except that I don’t have one! I’ve checked the different locations it might be in (i.e. the install for all users versus just me), but still no joy… anyone got any ideas?

    Reply
      1. DiKri's avatarDiKri

        Are you sure that you also enabled viewing of hidden files? On my mac, it’s in /Library/Application\ Support/CrashPlan/.ui_info
        Open a terminal and try cat /Library/Application\ Support/CrashPlan/.ui_info

  15. Marco's avatarMarco

    I got the following message:

    There was a problem downloading Crashplan_4.5.2Linux.tgz from the offcial downloadlink, which was “http://download.crashplan.com/installs/linux/CrashPlan/CrashPlan_4.5.2_Linux.tgz”

    Can anyone help me?

    Reply
  16. Tom K.'s avatarTom K.

    Continuing to suffer from the continuous stop/restart issue. I am dealing with approximately 2.4TB of backups (0.5M files or so), w/ max heap set to 3144M. I have cleared the cache files and both reinstalled and updated the CP and Java packages. I have even reduced the backup size. Not sure what more I can do to get past this….

    Reply
    1. Tom K.'s avatarTom K.

      Got it! Found a brief reference from Patters in an earlier post and decided to try to move past my 4GB heap size limitation.

      Removed Java Embedded and went with the full runtime Java SE package install. This enabled me to bump my max heap over 4GB and ended the constant restarts.

      Thanks to Patters for his continued efforts to keeping CP functional and all for your continued contributions to this forum.

      Reply
      1. Sam's avatarSam

        Hi Tom, I am having the same issues, but cannot upgrade the RAM on my model (DS214Play). What model have you got? I need to buy a new NAS.

    1. Tom K.'s avatarTom K.

      Well, in order to get Java 8 runtime installed, I first uninstalled Patter’s embedded SE release then upgraded to the current DSM beta. The package is supported by Synology directly. My understanding from a couple of other posts is that you can install the Java 8 runtime manually under DSM 5.2, but I figured that the 2nd beta release was probably stable enough for me to try that route.

      Not sure why I hit the 4GB requirement (actually I got an error a little under 512MB shy of the 4GB cap). Total backup was under 3TB, well under 1M files, and I had deduce turned off on all but one share (and even turning that off did not affect my issue).

      Fortunately, I have my unit loaded up with 16GB of RAM, so I had plenty of ceiling to work with.

      Reply
  17. Thor Egil Leirtrø's avatarThor Egil Leirtrø

    DS412+, 2GB RAM, Latest sofware of everything.
    I’ve noticed that when I restart the process I can get up towards 200KB/s upload speed. But after a day or two, especially if there has been nothing to do for a while and I hit it with more files to back up, the upload speed rarely goes over 40KB/s. If I restart the process again it is back up to 200KB/s.
    Any explanation to this?

    Reply
    1. Peter_M's avatarPeter_M

      You are getting 200KB/s when you are sending content that has already been sent so the dedup process is just verifying it. This is especially true when part of a large file was backed up, then crashplan was restarted and so the backup restarts on the same file — then the it shows 200KB/s when doing checksums on the part of the file that has already been backed up and it slows down when it gets to new data.

      Reply
      1. Singularity's avatarSingularity

        DeDupe isn’t files, it’s file blocks so if it finds matches to data you already have it won’t upload it even if they are new files…

  18. Pingback: An easy Backup Strategy for freelancers - Yann Graf

  19. Oliver Bishop's avatarOliver Bishop

    For some odd reason, my crashplan has created 8 folders called crashplan_# (# = 1 through 8). If I delete these folders they get re-created over time. Is there a reason why this is happening? Can these folders be hidden (assuming they are required) ?

    This is crashplan running on Synology DSM 5.2-5644u5 with headless client setup v.4.5.2-0037.

    Any help is appreciated!

    Reply
  20. Sam's avatarSam

    I’ve been suffering the start/stop problem on my DS214Play for months, presumably due to lack of RAM, so I’m going to buy a new Synology NAS. I’ve got 4Tb to back up. What model NAS should I get? I was thinking of the DS716+ which has 2Gb of RAM. Is this enough? Will CrashPlan work on it OK? Or what model would you recommend? Thanks again for your support.

    Reply
    1. Oliver Bishop's avatarOliver Bishop

      If your at all comfortable with hardware, why not build your own and use xpenology ? This allows you to run up to 12hdd, on potentially much better hardware then what they offer. I run mine on a 8 core AMD based system with 8GB of ram. Runs like a dream. My only suggestion (if you go the route of custom hardware), would be to invest in an IBM M1015 controller (~50-100$ JBOD controller).

      Reply
  21. rob's avatarrob

    CrashPlan was working fine up until a couple days ago. The log indicates that it is trying to update. I’ve followed all the previous guides of unzipping the .jar file and renaming the upgrade.sh. However, this time it doesn’t seem to work. Any ideas?

    Reply
      1. spyrule's avatarspyrule

        you can. Turn off automatic updates. NAS > Package Center > Settings > Auto Updates.

        Personally, I uncheck auto updates for all packages (I prefer to have manual control over them, it prevents these kind of annoying auto-update failures).

      2. Nick's avatarNick

        Crash plan updates its engine in the background when the service is stopped and started I think. This is different than the package you download or update in the package center. I ended up getting this to work by uninstalling Crashplan and then reinstalling it. I think all of the old engine update folders were hosing it up somehow. Good luck.

      3. spyrule's avatarspyrule

        I don’t know where you heard that from, but I’ve looked through my Crashplan/NAS logs quite carefully (comparing them to my firewall data transmit logs), and I don’t see any indication that it updates its engine automatically at all. Its engine is version numbered to match the current client version, so an update is required to update the engine. Now, the client is designed to point to an DNS name and resolve that to a C&C server for actual backup, but that has nothing to do with the updating of the client.

      4. Elvisizer's avatarElvisizer

        Crash plan absolutely tries to upgrade it self direct from the CP servers outside of the synology’s package management system. Check your logs when the version installed is behind th version on CP’s servers. Failed upgrade attempts will be logged.

      5. Patrick's avatarPatrick

        I was wondering, to avoid the automatic upgrade, if it would be possible to add a bogus record to the hosts file on the Synology to avoid the download…

      6. Carlos Clavero's avatarCarlos Clavero

        It is quite easy to see that it autoupdates, it is in the crashplan logs and in the crashplan app log in the package center. The update that fails is number 1435813200460, it has it’s own folder and .jar file in the updates folder inside the CrashPlan installation directory.
        The autoupdate feature is known from the crashplan website. The problem here is that if the app autoupdates and that update fails the server stops working until the update pass. I’ll take a look and see if the autoupdate can be disabled from the config files.

      7. rob's avatarrob

        I just double checked my settings on my Synology, and auto-updates is turned off. However earlier, I peeked at the log files, and in the engine_error.log, it gives the error:

        cannot execute binary file: Exec format error.

        Clearing that log file and starting the CrashPlan package again results in the same error.

  22. spyrule's avatarspyrule

    Forgot to add, I can also tell you that, since I disabled all automatic updates, I have ceased having these update problems (or my client no longer running). The only time I’ve had any issues, is when i manually update, and there is a manual bug/fix for that patch. However, since the past few versions, the updates have been smooth sailing for me.

    Reply
    1. Kyos's avatarKyos

      Yes, CrashPlan is trying to download an update. The version number is 1435813200460 and it fails the installation. Due to that it stopped working but if you uninstall and install again it will not work either because the update is done just after the installation. I managed to make it start and I was unable to recover my backup so a little job has to be done here.

      Reply
  23. Kyos's avatarKyos

    Well… I have the same issue. Yesterday it worked fine but today CrashPlan does not start. My synology log tells that is trying to repair. I uninstalled and reinstalled the package on the synology and it just don’t work. The server engine doesn’t start because it wants to update. The new version it downloads is 1435813200460.
    I hope it gets fixed soon.

    Reply
  24. Sam's avatarSam

    Thanks Oliver, but I’m not. I would love to learn from Patters or anyone if the DS716+ which has 2Gb of RAM is going to be enough to solve the start/stop problem on my DS214Play that has prevented me backing up for months, presumably due to lack of RAM. I need to buy a new Synology NAS. I’ve got 4Tb to back up. What model NAS should I get? Will CrashPlan work on the DS716+ OK? Or what model would you recommend? Thanks again for your support.

    Reply
    1. spyrule's avatarspyrule

      Its a fairly simple set of questions to ask tdetermine best nas for you:
      How much do you need in future storage, and whats your budget?

      Those two should determine which model to get. My opinion, get the one with the most drive bays and ram you can afford.

      Reply
      1. Sam's avatarSam

        Thanks, but the key question for me is: what is the minimum amount of RAM the NAS needs so that Crashplan doesn’t keep crashing and restarting itself (and not backing anything up). At the moment I have 3Tb to back up (and 1Gb of RAM on my existing NAS) but would want it to work up to 8Tb, In terms of budget, I don’t want to spend any more than necessary. I just want to know the minimum RAM size I need. Thanks for helping.

      2. Rich's avatarRich

        This is mostly anecdotal, but based on observations. It makes a difference whether you have 10,000 files comprising that 8Tb, or 800 million. It seems the memory is more consumed by the _list_ of the files, rather than the data contents. At least, that seems to be my experience backing up 16Tb. Also, you may want to try splitting up the volume into different smaller number of files backup sets. Hope that helps.

      3. Marie's avatarMarie

        I have a DS412+ that I too am having a problem because of the ram limitations. I would like to know if switching to DS1515+ with 6gb of ram will be sufficient for CrashPlan to work without issues.
        Thanks!!!!!

      4. Shane's avatarShane

        Yes. I run one at home and another at work. Home synology is limited to 3 gb ram but the work one has 6 gb. I find that with 6 gb there is more ram for other services.

        Both of mine are working but have not upgraded to DSM 6 yet.

      5. Marie Torres-Shepherd's avatarMarie Torres-Shepherd

        I’d like to know if upgrading from DS412+ to DS1515+ will solve stopping/starting issues and uploading limitations? I plan on installing an additional 4gb for a total of 6gb on the newer model.
        Thanks in advance for your help!

  25. Jables's avatarJables

    Having a similar issue with the Crashplan app trying to update and not working the past few days, seems stuck in an endless loop. What are the steps to fix? I’ve tried uninstalling and reinstalling as you guys mentioned, but it just tries to update again. In the log, I get “Upgrade failed” and then a batch of “Synology repairing upgrade in”

    Reply
    1. George's avatarGeorge

      These are the steps I used for 4.5.2 on DS214se.

      I did this, on the Synology via SSH, after stopping CP. Note that my DS has not yet updated to Update 2.

      unzip -o /var/packages/CrashPlan/target/upgrade/1435726800450_270.jar ‘*.jar’ -d /var/packages/CrashPlan/target/lib/
      unzip -o /var/packages/CrashPlan/target/upgrade/1435726800450_270.jar ‘lang/*’ -d /var/packages/CrashPlan/target/

      I then deleted any directories named 1435726800450_270. as well as 1435726800450_270.jar (or you can move jar file out of Crashplan directory structure).

      Reply
      1. Dave G's avatarDave G

        Me too…

        Now all I see is this in the CP log. Any solution to this yet?? I am on DSM 5.2-5644 Update 5

        I 03/08/16 01:11AM Installing upgrade – version 1435813200460
        I 03/08/16 01:11AM Upgrade failed – version 1435813200460
        I 03/08/16 01:41AM Downloading a new version of CrashPlan.
        I 03/08/16 01:41AM Installing upgrade – version 1435813200460
        I 03/08/16 01:41AM Upgrade failed – version 1435813200460
        I 03/12/16 07:01PM Stopping CrashPlan
        I 03/12/16 07:05PM Synology repairing upgrade in
        I 03/17/16 09:56AM Synology repairing upgrade in
        I 03/17/16 09:57AM Synology repairing upgrade in
        I 03/17/16 09:57AM Synology repairing upgrade in
        I 03/17/16 10:00AM Synology repairing upgrade in
        I 03/17/16 10:08AM Synology repairing upgrade in
        I 03/17/16 10:08AM Synology repairing upgrade in

  26. Tom K.'s avatarTom K.

    Ditto on the upgrade failure issue to 1435813200460 under DSM 6 RC. Tried manual unzip (via 7z utility w/ DSM 6) of the upgrade file as per general structure of Chris Nelson instructions too. No joy and currently down.

    Reply
      1. Tom K.'s avatarTom K.

        Wrote a small script (fix_cp_patch.sh) to accomplish the Chris Nelson fix on DSM 6 as it was getting to be a PITA to run multiple over and over. Example use: sudo ./fix_cp_patch.sh 1435813200460_359.jar

        #!/bin/bash
        #
        #fix_cp_patch.sh – A short script to automate stalled CrashPlan patches on Synololgy.
        #
        #Please note that this script must be run via sudo (at your own risk)

        if [ -z “$1” ]
        then
        /bin/echo “Usage: fix_cp_patch.sh {Crashplan Jar Filename}”
        exit
        fi

        cp_jarfile=$1
        cp_patch_dir=${cp_jarfile%%.*}.[0-9]*
        cp_package_target=/var/packages/CrashPlan/target

        /bin/echo
        /bin/echo “FIX_CP_PATCH: Extracting Lib Files”
        /bin/echo
        /bin/7z e -y -o$cp_package_target/lib $cp_package_target/upgrade/$cp_jarfile “*.jar”

        /bin/echo
        /bin/echo “FIX_CP_PATCH: Extracting Lang Files”
        /bin/echo
        /bin/7z e -y -o$cp_package_target/lang $cp_package_target/upgrade/$cp_jarfile “lang/*”

        /bin/echo
        /bin/echo “FIX_CP_PATCH: Moving Upgrade Script File”
        /bin/echo
        cd $cp_package_target/upgrade/$cp_patch_dir &>/dev/null
        /bin/mv upgrade.sh upgrade.sh.old 1>/dev/null
        cd – &>/dev/null

        /bin/echo
        /bin/echo “FIX_CP_PATCH: Done!”
        /bin/echo
        ~

      2. Tom K.'s avatarTom K.

        Mark – At a really simple level the format you would likely wish to use is as follows:

        /bin/7z e -y -o

      3. Tom K.'s avatarTom K.

        Not sure why it cut that off:

        /bin/7z e -y -oOUTPUT_FILE ARCHIVE_FILE WILD_CARD_FILE_ARGUMENTS

      4. devedse's avatardevedse

        For some reason my upgrade created multiple upgrade.sh files. I changed this piece of script which solved the problem:

        echo
        echo “FIX_CP_PATCH: Moving Upgrade Script File”
        echo
        find $cp_package_target/upgrade/ -name “upgrade.sh” | while read line
        do
        mv “$line” “$line.old”
        done
        cd – &>/dev/null

        Can you include that in your complete script?

      5. Tom K.'s avatarTom K.

        Devedse – Interesting. The only time I’m aware that you would see multiple upgrade.sh files would be in a situation wherein you have multiple upgrade patches present in the directory. As others have noted, the best way to resolve this issue is to delete all but the most recent upgrade patch prior to manually applying it.

        If I have some time in the next few days, I will look into incorporating the removal of extraneous patch downloads in the prior straw script I posted; but you are also welcome to update and/or repost any updates you feel may be helpful to the group here.

      6. caspertolsen's avatarcaspertolsen

        I’m currently on DSM 6.0 and it wont upgrade to the only jar in my package folder “1435813200460_382.jar” – i was trying using that upgrade script Tom K. posted but it gives me this error:

        “-ash: ./fix_cp_patch.sh: Permission denied”

      7. Tom K.'s avatarTom K.

        caspertolsen – DSM 6 incorporates increased security features around administrative (or elevated) system rights. As a result, you will be required to make use of the ‘sudo’ command in performing administrative-level functions at the command line. Command syntax can be found by typing ‘sudo –help’ at the command line.

    1. brennok's avatarbrennok

      I am still on DSM 5 so not sure what is going on. I tried running the Chris Nelson instructions again, since I forgot the _359, but I get permission issues trying to delete the old even though I am logged into admin and CrashPlan obviously isn’t running.
      error: cannot delete old /var/packages/CrashPlan/target/lib/bcpkix-jdk15on.jar
      Permission denied

      Reply
    2. Michael Gittelman's avatarMichael Gittelman

      Same here. Manual unzip with 7z instead of unzip like I usually do. Files appear to be where they are supposed to be but service won’t start. Running DSM 6 RC.

      Reply
    1. Sam's avatarSam

      Many thanks Tom. No wonder it’s smooth! How can you get 16GB in there? I thought you could only boost it 2GB to 6GB?

      Reply
      1. Tom K.'s avatarTom K.

        6GB is the Synology officially supported limit on the unit (Please note that the use of unsupported RAM configurations may void the OEM warranty). The OS kernel is capable supporting much higher limits. The real limit, in this case, is that the board only support 2 SODIMM slots. I replaced the OEM RAM slot and filled the open bank with 16GB of Corsair Vengeance RAM (2x8GB).

  27. Tom K.'s avatarTom K.

    Apologies in advance with any complications and/or the lack of much variable validation. It’s been about 15 years or so since I’ve had to write any scripts. :-)

    Reply
  28. Sascha's avatarSascha

    After upgrading my DS214+ from DSM 5.2 to 6.0 RC, CrashPlan package starts and keeps running, but doesn’t do anything. The Windows Client connects to NAS, but backup doesn’t start, it only says “Waiting for backup”, even if I force it via “Play” button. Uninstalling and reinstalling the package didn’t help. Any idea?

    Reply
    1. Scott's avatarScott

      Hi, did you ever figure this out? I’m having the same issue. I got the 4.6.0 upgrade running, but still having the ‘Waiting for backup’ problem.

      Reply
  29. mgittelman's avatarmgittelman

    I’m having the same issue where I use 7z to do the Chris Nelson fix for the latest update on DSM 6 RC and it’s not working. Unable to start service even after all the files are extracted properly. Any ideas?

    Reply
  30. Marinos Stylianou's avatarMarinos Stylianou

    For some weird reason the installation tries to wget the file and never finishes. Manually wget the file finishes without issues. Is there any other way to point the installer to the installation file already downloaded?

    Reply
  31. Daniel Odievich's avatarDaniel Odievich

    Hi there,

    DS415+ got upgraded to DSM 5.2-5644 Update 5

    CrashPlan was already stuck in endless loop of failed upgrade:
    I 03/14/16 10:42PM Downloading a new version of CrashPlan.
    I 03/14/16 10:42PM Installing upgrade – version 1435813200460
    I 03/14/16 10:42PM Upgrade failed – version 1435813200460
    I 03/14/16 11:02PM Stopping CrashPlan
    I 03/14/16 11:02PM Not ready for backup from REDACTED. Reason: The destination is not available
    I 03/15/16 07:32AM Synology repairing upgrade in
    I 03/16/16 07:32AM Synology repairing upgrade in
    I 03/17/16 07:32AM Synology repairing upgrade in
    I 03/17/16 11:22AM Synology repairing upgrade in
    I 03/17/16 11:23AM Synology repairing upgrade in
    I 03/17/16 11:30AM Synology repairing upgrade in

    I decided to remove the CrashPlan package and just install it again.
    While I was it, I upgraded Java to /volume1/public/ejdk-8u73-linux-i586.tar.gz with your package manager
    Now to my surprise I do not see the CrashPlan package in Community section of Package Center. I see Java SE Embedded 7 and 8, Minecraft, OpenRemote, SANE Backend and Serviio. But no Crashplan.

    Where could it be?

    Reply
  32. Tom K.'s avatarTom K.

    Just checking in to see if anyone has seen any progress/resolution on the issue with DSM 6 RC not working with CP v4.5.2-0037.

    Reply
    1. Mark Venn's avatarMark Venn

      Tom, I had no issues getting 4.5.2 to run under DSM 6 beta 2 (not sure if that is the same as RC, but I’m not being prompted to update DSM right now). 4.6.0 … no joy with that as yet.

      Reply
  33. Tom K.'s avatarTom K.

    Mark,

    Well, I was able to get the package back up and running this AM. It took another manual patch intervention; but it is up and running. It appears that the issue that I have now (again) is that the recent patch is utilizing some 32-bit Java code that restricts the Java Max Heap back under 4M. I do have the full 8 JDK (8u74 x64) installed. I’m done re-syncing, I suspect that CP will be back in the crash/restart cycle once that has completed…

    Reply
    1. Peter's avatarPeter

      I found the same issue with Max Heap size now being under 4M even though I’m using x64 JDK. I have 4.6.0 – Build: 359 up and running on DSM 6 beta 2 after manual upgrade using usual methods and reverting /volume1/@appstore/CrashPlan/syno_package.vars to under 4M.

      Reply
    2. Mike's avatarMike

      Tom, I’m still having the same issue. Did you do anything different to get it up and running this time?

      Reply
      1. Tom K.'s avatarTom K.

        Mike, To get myself back up and “running” this time around: I first removed the existing Java and CP installs. I then reinstalled both Java 8 and upgraded to the 8u74 x64 release. Once done with that, I reinstalled CP. After CP started, downloaded build 359, and subsequently failed the patch install; I manually applied the patch (per my prior notes on patch process with DSM 6).

        When restarting CP after the above, the error log will reflect an issue with any Max Heap value set over ~3.5MB. This is indicative of a 32-bit Java release and not the 64-bit release installed with the Java 8 x64 JDK. I am currently making the assumption that the libraries that were updated with the current 359 build are to blame.

      2. ahershler's avatarahershler

        I am surprised at the above.

        I have been running Patters’ CrashPlan package for a long time, on Java x64, with 4 GB allocated. Recently, CrashPlan started notifying me that it downloaded a new version of CrashPlan (4.6.0), but the upgrade failed every time. Eventually, CrashPlan stopped working.

        To get CrashPlan back up and running, I just uninstalled the CrashPlan package from the Synology Package Center, and then re-installed it (which required me to redo all of the various steps to get it to run headless on the Synology with 4 GB of memory, with a Windows computer as its GUI). To begin with, the CrashPlan package ran CrashPlan version 4.5.2, but it almost immediately notified me that it was downloading a new version of CrashPlan (4.6.0). It proceeded to install the upgrade, which failed (again). I stopped the CrashPlan package and restarted it, whereupon the message “Synology repairing upgrade in /var/packages/CrashPlan/…” appeared in the log. Upon another stop and start, CrashPlan version 4.6.0 started running. I did not need to do any manual steps to get the upgrade to work, and I did not have any further issues. I do not have any messages in the log about CrashPlan complaining of the MaxHeap size I have set.

        Please note that I am running DSM 5.0; however, CrashPlan 4.6.0 is the same Java code regardless of what version of DSM it is running on.
        Do note that I am running Java 1.7.0_79 for x64, not Java 8.

        Excerpt from my log:
        03/18/16 04:29PM CrashPlan started, version 4.5.2, GUID 564632043456036871
        03/18/16 04:29PM Downloading a new version of CrashPlan.
        03/18/16 04:29PM Download of upgrade complete – version 1435813200460.
        03/18/16 04:29PM Installing upgrade – version 1435813200460
        03/18/16 04:29PM Upgrade failed – version 1435813200460
        03/18/16 04:32PM Stopping CrashPlan
        03/18/16 04:32PM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1435813200460_359.1458311387123
        03/18/16 04:32PM CrashPlan started, version 4.6.0, GUID 564632043456036871

      3. Mike's avatarMike

        Thanks Tom. Tried all that and still can’t get it to start. I think I will wait another few days to see if Patters can work some magic before fussing with it any more.

      4. Rich's avatarRich

        Not to jinx things but I have not had issues in months, at least through 2 or 3 periods where there seemed to be a spike in others having issues with upgrades. I didn’t do anything special, so wondering why I am not having these issues any more

      5. Rui Marinho's avatarRui Marinho

        Found the solution for switching from java7u77 32-bit to java8 from Synology. It looks like CrashPlan is favouring its bundled java runtime, so go to /var/packages/CrashPlan/target/install.vars and change:

        JAVACOMMON=/volume1/@appstore/CrashPlan/jre/bin/java

        to

        JAVACOMMON=/var/packages/Java8/target/j2sdk-image/jre/bin/java

        Stop and start the service and check /var/packages/CrashPlan/target/log/service.log.0 to see if the following string is there:

        JVM=Java(TM) SE Runtime Environment (1.8.0_77-b03, 64-bit)

        Now you can increase the heap size without any issue!

  34. Tom K.'s avatarTom K.

    Well, for the 1st time in two weeks my backups are running again. I’m actually a bit surprised that I’m not seeing the start/stop issue as I’ve only got my Max Heap value set to 3.5M (prior settings of less than 4M have failed). So on one hand, I’m elated that I’m pushing block data again. On the other hand, I’m pretty sure my euphoria will not last…

    Reply
  35. Eponym's avatarEponym

    My DS213+ DSM 5.2 Java 8 Crashplan 4.5.2 was down for 10 days. All I needed to do to get it back up is to follow patters intructions from 0035 06/Nov/15 by deleting all except for one of the failed upgrade numbered subfolders in /var/packages/CrashPlan/target/upgrade. After that I had to start the Crashplan package twice and was back in business, now running 4.6

    Reply
  36. Troy's avatarTroy

    Just a question – has anyone noticed that CrashPlan rate limits the hell out of backup connections down to as low as 100Kbps. It’s insane just how slow the backup will is throttled. I’m thinking of experimenting with another service — thoughts on this topic?

    Reply
    1. Thor Egil Leirtrø's avatarThor Egil Leirtrø

      No. It is no longer possible to log in to SSH with the root account, so I’m not able to fix the CrashPlan upgrade files. I just get access denied using the Admin account.

      I didn’t see the consequences of this small note in the 6.0 release notes:
      “Root account is replaced by administrators group credentials to log into SSH to enhance security.”

      Is there a workaround for this?

      Reply
      1. Mark Venn's avatarMark Venn

        Thor – the workaround is to ssh in as admin and then run all of the commands with “sudo”. In DSM 6.0 you will need to use 7z rather than unzip; the command syntax has been kindly provided by Tom K earlier in the comments.

      2. Thor Egil Leirtrø's avatarThor Egil Leirtrø

        Update: Running commands through sudo seems to take care of the Access denied problem.
        But the unzip command seems to have disappeared.
        My CrashPlan is running at the moment, after a few failed restarts. Let’s see how it develops.

      3. Mark Venn's avatarMark Venn

        No worries, Thor. I’ve been unsuccessful at getting 4.6.0 to run under what is (I assume) the GA release of DSM 6.0 – I get as far as repairing CrashPlan and then the application stops and will not restart. I cannot get enough detail from the CrashPlan application history or the Log Centre to figure this one out.

      4. Gert Serneels's avatarGert Serneels

        Mark,

        Don’t forget to check out the engine_error.log:
        /var/packages/CrashPlan/target/log/engine_error.log

        Is it saying “Cannot execute binary file: Exec format error”?
        If so, than you have the same problem as me. Upgraded succesfully now, but it cannot start anymore.

        Gert

      5. Ian_H's avatarIan_H

        Use sudo -i … I struggled with this … and finally noticed it was mentioned in the online help! :-)
        “SSH/Telnet only supports logging into the system with accounts belonging to the administrators group. To switch to a root account, please log into the system with SSH/Telnet as a user belonging to the administrators group, run the command sudo -i, and then enter the password of the account used to log in.”

    2. Ian H's avatarIan H

      My setup is failing with DSM 6. After installing the upgrade, the service failed to start so I
      – uninstalled Java7 package
      – uninstalled CP package
      – installed Java8 package
      – installed CP package- it tried to upgrade .. not sure this worked … service fails to start … engine_error.log says
      “/var/packages/CrashPlan/scripts/start-stop-status.sh: line 167: /volume1/@appstore/CrashPlan/jre/bin/java: cannot execute binary file: Exec format error”

      history.log show …
      I 03/24/16 12:30PM CrashPlan started, version 4.5.2, GUID 680804743381516290
      I 03/24/16 12:34PM Downloading a new version of CrashPlan.
      I 03/24/16 12:37PM Download of upgrade complete – version 1435813200460.
      I 03/24/16 12:37PM Installing upgrade – version 1435813200460
      I 03/24/16 12:38PM Upgrade installed – version 1435813200460
      I 03/24/16 12:38PM CrashPlan stopped, version 4.5.2, GUID 680804743381516290
      I 03/24/16 12:50PM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1435813200460_382.1458823073270

      Reply
  37. Gert Serneels's avatarGert Serneels

    I have just updated my DS715 to DSM 6.0-7321, that was not a good idea, Crashplan stopped working. I removed Crashplan and reinstalled it succesfully. The package runs and after a few seconds is starts to download the upgrade 1435813200460. It installs the uptrade and logs “Upgrade installed”, than Crashplan stops. When I restart Crashplan it start to repairing the upgrade 1435813200460_382.1458810768468 and than the package stops and nothing happens. If I restart, nothing happens, nothing is logged, even if I remove the update, nothing happens.

    Please help, I reinstalled Crashplan and Java, everytime the same problem: when I start the Crashplan package it stops allmost immediately and nothing is logged…

    Thanks

    Reply
  38. Pete's avatarPete

    I’ve just set this up on a DS216Play running DSM 6.0

    I couldn’t get your Java Embedded Package to install, then noticed that Synology have a Java 8 package in their Package Center.

    Installed the Synology Java 8 package then picked up your instructions from installing the CrashPlan package and all is now working.

    I did have to stop and start the CrashPlan package 2 or 3 times before it would connect, but now all seems to be working

    Reply
  39. Ian_H's avatarIan_H

    Use sudo-i to login as root
    SSH/Telnet only supports logging into the system with accounts belonging to the administrators group. To switch to a root account, please log into the system with SSH/Telnet as a user belonging to the administrators group, run the command sudo -i, and then enter the password of the account used to log in.

    Reply

Leave a reply to bertxl Cancel reply