CrashPlan packages for Synology NAS

UPDATE – The instructions and notes on this page apply to all three versions of the package hosted on my repo: CrashPlan, CrashPlan PRO, and CrashPlan PROe.

CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient – it could even get stolen or destroyed and you would still have your data. Whilst you can pay a small monthly charge for a storage allocation in the Cloud, one neat feature CrashPlan offers is for individuals to collaboratively backup their important data to each other – for free! You could install CrashPlan on your laptop and have it continuously protecting your documents to your NAS, even whilst away from home.

CrashPlan-Windows

CrashPlan is a Java application, and difficult to install on a NAS. Way back in January 2012 I decided to simplify it into a Synology package, since I had already created a few others. As I started I used information from Kenneth Larsen’s blog post, the Vincesoft blog article for installing on ARM processor Iomega NAS units, and this handy PDF document which is a digest of all of them. I used the PowerPC binaries Christophe had compiled on his chreggy.fr blog, so thanks go to him. I wanted make sure the package didn’t require the NAS to be bootstrapped, so I bundled any dependent binaries. Back in 2012 I didn’t know how to cross compile properly so I had to use versions I had found, but over the years I have had to compile my own versions of many of these binaries, especially as I added support for Synology’s huge proliferation of different CPU architectures.

UPDATE – For version 3.2 I also had to identify and then figure out how to compile Tim Macinta’s fast MD5 library, to fix the supplied libmd5.so on ARM systems (CrashPlan only distributes libraries for x86). I’m documenting that process here in case more libs are required in future versions. I identified it from the error message in log/engine_error.log and by running objdump -x libmd5.so. I could see that the same Java_com_twmacinta_util_MD5_Transform_1native function mentioned in the error was present in the x86 lib but not in my compiled libmd5.so from W3C Libwww. I took the headers from an install of OpenJDK on a regular Ubuntu desktop. I then used the Linux x86 source from the download bundle on Tim’s website – the closest match – and compiled it directly on the syno using the command line from a comment in another version of that source:
gcc -O3 -shared -I/tmp/jdk_headers/include /tmp/fast-md5/src/lib/arch/linux_x86/MD5.c -o libmd5.so

Licence compliance is another challenge – Code 42 Software’s EULA prohibits redistribution of their work. I had to make the syno package download CrashPlan for Linux (after the end user agrees their EULA), then I had to write my own script to extract this archive and mimic their installer, since their installer is interactive

 

Synology Package Installation

  • In Synology DSM’s Package Center, click Settings and add my package repository:
    Add Package Repository
  • The repository will push its certificate automatically to the NAS, which is used to validate package integrity. Set the Trust Level to Synology Inc. and trusted publishers:
    Trust Level
  • 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.
  • 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 7 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.
  • 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 archive recognised, try downloading it with a different web browser. Some browsers try to help by uncompressing the file, or renaming it without warning. I have tried to code around most of these behaviours. Use Firefox if all else fails – it seems to be the only browser that doesn’t interfere with the file. 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 is configured by a desktop client, but operates independently of it.
  • The first time you start the CrashPlan package you will need to stop it and restart it before you can connect the client. This is because a config file that is only created on first run needs to be edited by one of my scripts. The engine is then configured to listen on all interfaces on the default port 4243.
  • If you previously installed CrashPlan manually using the Synology Wiki, you can find uninstall instructions here.
 

CrashPlan Client Installation

  • Once the CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
  • Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.
  • By default the client is configured to connect to the CrashPlan engine running on the local computer. You will need to edit the file conf/ui.properties in the CrashPlan folder on that computer so that this line:
    #serviceHost=127.0.0.1
    is uncommented (by removing the hash symbol) and set to the IP address of your NAS, e.g.:
    serviceHost=192.168.1.210
    Mac OS X users can edit this file from the Terminal using:
    sudo nano /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties
    (use Ctrl-X to save changes and exit)
  • Starting with CrashPlan version 4.3.0 you will also need to run this command on your NAS from an SSH session:
    echo `cat /var/lib/crashplan/.ui_info`
    Note those are backticks not quotes. This will give you a port number (4243), followed by an authentication token, followed by the IP binding (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 (this was a new requirement with CrashPlan version 4.4.1).
    so using the example above, your computer’s CrashPlan client config file would be edited to:
    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 file:
    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)
  • 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

 

Notes

  • The package downloads the CrashPlan installer directly from Code 42 Software, following acceptance of their EULA. I am complying with their wish that no one redistributes it.
  • Real-time backup does not work on PowerPC systems for some unknown reason, despite many attempts to cross compile libjna, and attempts to use binaries taken from various Debian distros (methods that work for the other supported CPU architectures).
  • The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 512MB). This can be overridden in a persistent way if you are backing up large backup sets by editing /var/packages/CrashPlan/target/syno_package.vars. If you are considering buying a NAS purely to use CrashPlan and intend to back up more than a few hundred GB then I strongly advise buying one of the models with upgradeable RAM. Memory is very limited on the cheaper models. I have found that a 512MB heap was insufficient to back up more than 2TB of files on a Windows server 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).
  • The default location for saving friends’ backups is set to /volume1/crashplan/backupArchives (where /volume1 is you primary storage volume) to eliminate the chance of them being destroyed accidentally by uninstalling the package.
  • If you need to manage CrashPlan from a remote location, I suggest you do so using SSH tunnelling as per this support document.
  • The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache. Upgrades can now take place without requiring a login from the client afterwards.
  • If you remove the package completely and re-install it later, you can re-attach to previous backups. When you log in to the Desktop Client with your existing account after a re-install, you can select “adopt computer” to merge the records, and preserve your existing backups. I haven’t tested whether this also re-attaches links to friends’ CrashPlan computers and backup sets, though the latter does seem possible in the Friends section of the GUI. It’s probably a good idea to test that this survives a package reinstall before you start relying on it. Sometimes, particularly with CrashPlan PRO I think, the adopt option is not offered. In this case you can log into CrashPlan Central and retrieve your computer’s GUID. On the CrashPlan client, double-click on the logo in the top right and you’ll enter a command line mode. You can use the GUID command to change the system’s GUID to the one you just retrieved from your account.
  • The log which is displayed in the package’s Log tab is actually the activity history. If you are trying to troubleshoot an issue you will need to use an SSH session to inspect these log files:
    /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
    This is particularly useful on ARM systems because CrashPlan currently prevents hibernation while it is running (unresolved issue, reported to Code 42). Note that regardless of real-time backup, by default CrashPlan will scan the whole backup selection for changes at 3:00am. Include this time within your Task Scheduler time window or else CrashPlan will not capture file changes which occurred while it was inactive:
    Schedule Service Start

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

Package scripts

For information, here are the package scripts so you can see what it’s going to do. You can get more information about how packages work by reading the Synology 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.7.0_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_4.7.0_Linux.tgz"
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
  CP_EXTRACTED_FOLDER="${SYNOPKG_PKGNAME}-install"
  OLD_JNA_NEEDED="true"
  [ "${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"
[ "${SYNO_CPU_ARCH}" == "armv7l" ] && SYNO_CPU_ARCH="armv7l"
[ "${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"
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_7}" == "true" ]; then
  DOWNLOAD_URL="http://tinyurl.com/javaembed"
  EXTRACTED_FOLDER="ejre1.7.0_75"
  #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="ejre-7u75-fcs-b13-linux-arm-sflt-headless-18_dec_2014.tar.gz"
    JAVA_BUILD="ARMv5 Linux - Headless EABI, SoftFP ABI, Little Endian"
  elif [ "${SYNO_CPU_ARCH}" == "armv7l" ]; then
    JAVA_BINARY="ejre-7u75-fcs-b13-linux-arm-vfp-sflt-client_headless-18_dec_2014.tar.gz"
    JAVA_BUILD="ARMv6/7 Linux - Headless - Client Compiler EABI, VFP, SoftFP ABI, Little Endian"
  elif [ "${SYNO_CPU_ARCH}" == "armhf" ]; then
    JAVA_BINARY="ejre-7u75-fcs-b13-linux-arm-vfp-hflt-client_headless-18_dec_2014.tar.gz"
    JAVA_BUILD="ARMv6/7 Linux - Headless - Client Compiler EABI, VFP, HardFP ABI, Little Endian"
  elif [ "${SYNO_CPU_ARCH}" == "ppc" ]; then
    JAVA_BINARY="ejre-7u75-fcs-b13-linux-ppc-e500v2-headless-18_dec_2014.tar.gz"
    JAVA_BUILD="Power Architecture Linux - Headless - e500v2 with double-precision SPE Floating Point Unit"
  elif [ "${SYNO_CPU_ARCH}" == "i686" ]; then
    JAVA_BINARY="ejre-7u75-fcs-b13-linux-i586-headless-18_dec_2014.tar.gz"
    JAVA_BUILD="x86 Linux Small Footprint - Headless"
  elif [ "${SYNO_CPU_ARCH}" == "x64" ]; then
    JAVA_BINARY="jre-7u80-linux-x64.tar.gz"
    JAVA_BUILD="Linux x64"
    EXTRACTED_FOLDER="jre1.7.0_80"
    DOWNLOAD_URL="http://tinyurl.com/java7x64"
  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_7}" == "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
  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_7}" == "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

    #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_7}" == "true" ] && echo JAVACOMMON=${SYNOPKG_PKGDEST}/jre-syno/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

  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
    sed -i -r "s|^(JAVACOMMON=).*$|\1\${OPTDIR}/jre-syno/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_470",
            "desc": "4.7.0",
            "defaultValue": true
          },
          {
            "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 (Java 7 is recommended):",
        "subitems": [
          {
            "key": "WIZARD_JRE_SYS",
            "desc": "Default system Java version",
            "defaultValue": false
          },
          {
            "key": "WIZARD_JRE_7",
            "desc": "Dedicated installation of Java 7",
            "defaultValue": true
          }
        ]
      }
    ]
  }
]
 

Changelog:

  • 0031 Added TCP 4242 to the firewall services (computer to computer connections)
  • 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
 
 

5,585 thoughts on “CrashPlan packages for Synology NAS

  1. OleDK

    I have the same issue as all of you guys with version Version: 4.7.0 – 1435813200470. It installs but the service stops immediately after being started.

    Reply
  2. mgittelman

    Strange, I tried command line and got:

    /var/packages/CrashPlanPRO/target/conf$ sudo /var/packages/CrashPlanPRO/scripts/start-stop-status.sh start
    Starting CrashPlanPRO …
    rm: cannot remove ‘/var/packages/CrashPlanPRO/target/*.pid’: No such file or directory
    /var/packages/CrashPlanPRO/scripts/start-stop-status.sh: line 71: unzip: command not found
    /var/packages/CrashPlanPRO/scripts/start-stop-status.sh: line 72: unzip: command not found
    Usage: /var/packages/CrashPlanPRO/scripts/start-stop-status.sh {start|stop|status|restart}

    Then ran it again and the service started. syno_package.vars was recreated without the USR_MAX_HEAP part. Added that back in manually, restarted, and the engine looks ok now.

    If you are running into the service not starting issue, maybe try it via command line a couple times?

    Reply
  3. oeekker

    Hmz… Crashplan manually upgraded and it’s running again, but according to the Package Center it isn’t :-/

    Reply
  4. Troy

    Patters – we really need the package upgraded. Any idea on an ETA on when we can get this fixed for everyone? I’ve been down for 3-4 days now.

    Reply
  5. L Smith

    Thanks Patters for all the work you’ve done (and I hope that the current problem can be fixed soon).

    To quickly change the subject, I wanted to make sure that the paypal “support my work” link on the bottom of the right collumn is a legitimate link (and not an extremely well placed add). You’ve done a great job making sure that crashplan any my synology get along, I’d like to donate something, but I want to make sure it will actually get to you.

    Reply
  6. ewilts

    I did the version number trick and it seems to have fixed it for me.

    cd /var/packages/Packages
    sudo cp INFO INFO.2016-07-14
    sudo vi INFO
    change version=”4.7.0-0040″ to version=”4.6.0-0040″
    save file
    – start the service
    – let it upgrade
    – start the service again
    tail -f target/log/history.log.0

    Reply
  7. tomcat1116

    Would be great if the next go around automatic upgrade from the CrashPlan side was turned off so that upgrades only came with a package upgrade of some sort. This wouldn’t be so bad if it didn’t just happen seemingly spontaneously. I don’t recall this ever happening without my permission on Windows installations.

    Reply
  8. ced

    Same issue for me. I just uninstalled and reinstalled the Patters package and it is working again.

    Reply
    1. Troy

      But that is a pointless fix. CrashPlan will just download the latest update and break your install again and that could happen within minutes of your previous install working because there is no way to disable the updates. We have to fix the current version with a new package

      Reply
      1. Martin

        I uninstalled, deleted the var/lib/crashplan folder and then reinstalled. I adopted my old backup and am up and running again. Checking the log I am now on the new build (see below), looks like patters script has grabbed the latest build. Been up 1 hour and crashplan hasn’t pushed anymore updates.

        CPVERSION = 4.7.0 – 1435813200470 (2015-07-02T05:00:00:470+0000) – Build: 344

      2. Martin

        I uninstalled and then deleted the var/lib/crashplan folder. I then did a new install and then adopted my old backup set. Looks like patters script has grabbed the lasted build and installed that, all working for me again on a DS213+. No more updates being pushed by code42, current build I am on from log.

        CPVERSION = 4.7.0 – 1435813200470 (2015-07-02T05:00:00:470+0000) – Build: 344

  9. Martin

    I uninstalled, deleted the var/lib/crashplan directory and then reinstalled. Adopted old backup and am back up and running. Doesn’t look like Crashplan is pushing any more updates. Current build from log below.

    4.7.0 – 1435813200470 (2015-07-02T05:00:00:470+0000) – Build: 344

    Reply
  10. OS

    Since the last update, I’ve been getting the following errors, and the service won’t start. Any idea?

    Jul 11 21:38:36 HomeDrive bash: BASH_ERR: report_error [ (6696)”/volume1/@appstore/java8/ejdk1.8.0_91/linux_arm_sflt/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx384m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Djava.io.tmpdir=/volume1/@tmp -Djava.net.preferIPv4Stack=true -classpath /var/packages/CrashPlan/target/lib/com.backup42.desktop.jar:/var/packages/CrashPlan/target/lang com.backup42.service.CPService” -> (30581)”/bin/bash upgrade.sh” -> (30650)”/bin/bash upgrade.sh” ] upgrade.sh: line 112: ../../bin/CrashPlanEngine: Permission denied
    Jul 11 21:38:36 HomeDrive bash: BASH_ERR: report_error [ (30581)”/bin/bash upgrade.sh” -> (30652)”/bin/bash upgrade.sh” -> (30653)”/bin/bash upgrade.sh” ] upgrade.sh: line 135: /bin/java: No such file or directory
    Jul 11 21:38:36 HomeDrive bash: BASH_ERR: report_error [ (30581)”/bin/bash upgrade.sh” -> (30656)”/bin/bash upgrade.sh” -> (30657)”/bin/bash upgrade.sh” ] upgrade.sh: line 139: /bin/java: No such file or directory
    Jul 11 21:39:08 HomeDrive bash: BASH_ERR: internal_error [ (6696)”/volume1/@appstore/java8/ejdk1.8.0_91/linux_arm_sflt/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx384m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Djava.io.tmpdir=/volume1/@tmp -Djava.net.preferIPv4Stack=true -classpath /var/packages/CrashPlan/target/lib/com.backup42.desktop.jar:/var/packages/CrashPlan/target/lang com.backup42.service.CPService” -> (30581)”/bin/bash upgrade.sh” -> (30693)”/bin/bash upgrade.sh” ] upgrade.sh: line 214: cpio: command not found
    Jul 16 11:28:07 HomeDrive -sh: BASH_ERR: builtin_error [ (9916)”sshd: admin [priv]” -> (9926)”sshd: admin@pts/2″ -> (9927)”-sh” ] -sh:0: cd: t: No such file or directory
    Jul 16 11:30:49 HomeDrive -sh: BASH_ERR: parse_error [ (9916)”sshd: admin [priv]” -> (9926)”sshd: admin@pts/2″ -> (9927)”-sh” ] -sh: syntax error near unexpected token `;’.

    Reply
  11. Barney Moss

    I do this to fix the constant update/fix cycle.
    In `/etc/crontab` I add the line
    “`
    5 * * * * root grep -q JAVACOMMON=/var/packages/Java8/target/j2sdk-image/jre/bin/java /volume1/@appstore/CrashPlan/install.vars || (sed -i.bak ‘s|^JAVACOMMON=${JAVA_HOME}/.*$|JAVACOMMON=/var/packages/Java8/target/j2sdk-image/jre/bin/java|’ /volume1/@appstore/CrashPlan/install.vars && /var/packages/CrashPlan/scripts/start-stop-status restart)
    “`
    Then `/usr/syno/sbin/synoservicectl –restart crond` to apply it, and every hour the cron service checks if JAVACOMMON has been reset during the latest upgrade, and if so, it fixes it and restarts CrashPlan.

    Reply
    1. patters Post author

      The section beginning at line 165 of start-stop-status.sh already checks this – I implemented that in either version 0039 or 0040 I think.

      Reply
  12. Adi

    @Wayne / @Toy

    I am an noob with command lines but got the crashplan on synology running fine for last 1yr and this July 11th update broke something

    -i followed all the instructions @wayne listed out except replacing Jar file. I am not able to open the crashplan from my mac (error:- not able to find the backup engine)

    -replaced the GUID with new install GUID in the info file and all that but its not starting, package is running fine in Synology.

    -can you please list the instructions to replace the jar file, i downloaded the specified file but dont know the commands to move it to the crashplan folder

    Reply
  13. nh_ets

    Why will it not start (or if it does, quit quickly) on a DS414 running latest DSM, but will work perfectly on my DS1513+? Does it have to do with ARM vs Intel chip?

    On the DS414 if have tried uninstall/reinstall, restart DSM, reloading Java (using Java 8) – nothing works anymore. Are there commands I should try to execute via SSH as admin on the Synology device?

    HELP!!!!!!

    Reply
    1. Zelda

      I’ve just fresh install new crashplan on my synology and the backup stays on “Synchronizing” all the time in the crashplan app in windows. I’ve started the backup yesterday.
      Any Idea ?

      Reply
    2. semperfidelis

      Does anybody know if patters is going to create a new Package?

      I have to admit I’ve lost patience with this as I really appreciate patters’ work but Crashplan makes it impossible to rely upon them.

      Backblaze is now supported on Synology Cloud Sync. I think I might give that a try.

      Reply
  14. Christian de Closset

    Hi Folks

    On July 13, a new update got installed on my DS413 (DSM 6.0.1-7393 Update 1 – DSM date:
    2016/06/20).
    Since then, the module won’t start.
    I haven’t found any recent comment about it, so I might be one of the first running into the issue.
    Any idea/suggestion welcome,

    Thanks,

    Christian

    Reply
    1. Troy

      The problem with this fix all you are doing is reinstalling the previous version and because we have no way to stop CrashPlan from upgrading the software, they will push the new update and it will be in the very same state. This is not a fix.

      Reply
      1. Per

        Hi,

        Well, I think you are wrong. My CP states version 4.7.0 – 1435813200470 (2015-07-02T05:00:00:470+0000) – Build: 344. Isn’t that the latest version?

        Regards,
        Per

      2. Troy

        That’s the version Patters last updated. The new version being pushed down is 470_344. We need Patters to upgrade the package to support this new version or someone has to come up with some real instructions that can make this one work or any/all work will end up back to where we all are with an non working CrashPlan. You can bet yours will stop working once they push 344 to you as well.

      3. George

        I agree with Per, the current CP package available in DSM is update 344 and there is nothing new for patters to update.

        DSM 6, DJ214se, ARM

        In my case, I didn’t realise I had update 317 installed, so the download of update 344 happened and the upgrade failed.

        So I decided to update CP via DSM package, and upgrade went without a hitch. Now I am running update 344. So until CP publishes an further update of 4.7, don’t expect any problems.

        Those who are having problems with 344 upgrade might follow earlier instructions to change version number in installed version and then update via DSM.

    2. Ian H

      These instructions worked for me as well … been running perfectly for 3 days now .. no upgrades pushed … not sure if I should be expecting any?
      It did take a couple of re-starts for the new _ui.info file to appear … had me worried for a bit .. it was created eventually.

      Reply
      1. Per

        My ver 344 is still running fine (at least until CP sends out the next version;-)). The instructions work fine.

        I’ve been using patters packages for years now (since the first stable releases) and it’s always a pain when CP pushes a new version. When I’ve compared with other solutions I still find CP to be the most competetive and also the only one that have 1 minute versioning.

  15. aadhoc78

    (I’m leery about the uninstall-reinstall approach, but I would if Patters says to :-)

    I looked into the problem a *little bit* more deeply. When I start the CrashPlan service (/var/packages/CrashPlan/scripts/start-stop-status.sh start), I end up with the engine error (/var/packages/CrashPlan/target/log/engine_error.log) saying “Error: Could not find or load main class com.backup42.service.CPService”

    The new upgrade extract must have failed.
    I noticed the start script is looking for this which didn’t exist: /var/packages/CrashPlan/target/lib/com.backup42.desktop.jar
    From /var/packages/CrashPlan/target/upgrade.cpi, I extracted the missing lib and lang directories.
    With those in place, start now does more:

    ash-4.3# /var/packages/Java7/target/j2sdk-image/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx1024m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Djava.io.tmpdir=/volume1/@tmp -Djava.net.preferIPv4Stack=true -classpath /var/packages/CrashPlan/target/lib/com.backup42.desktop.jar:/var/packages/CrashPlan/target/lang com.backup42.service.CPService

    [07.17.16 21:55:34.331 INFO main com.backup42.service.CPService] *************************************************************
    [07.17.16 21:55:34.333 INFO main com.backup42.service.CPService] *************************************************************
    [07.17.16 21:55:34.333 INFO main com.backup42.service.CPService] STARTED CrashPlanService
    [07.17.16 21:55:34.337 INFO main com.backup42.service.CPService] CPVERSION = 4.7.0 – 1435813200470 (2015-07-02T05:00:00:470+0000) – Build: 344
    [07.17.16 21:55:34.346 INFO main com.backup42.service.CPService] LOCALE = English (United States)
    [07.17.16 21:55:34.347 INFO main com.backup42.service.CPService] ARGS = []
    [07.17.16 21:55:34.347 INFO main com.backup42.service.CPService] *************************************************************
    [07.17.16 21:55:35.524 INFO main com.backup42.service.CPService] Adding shutdown hook.
    [07.17.16 21:55:35.617 INFO main com.backup42.service.CPService] loadConfig, BEGIN Loading Configuration
    [07.17.16 21:55:35.713 INFO main com.backup42.service.CpsFolders] CpsFolders chmod successful. confPath=conf/
    [07.17.16 21:55:35.713 INFO main com.backup42.service.CPService] BEGIN Copy Custom
    [07.17.16 21:55:35.713 INFO main com.backup42.service.CPService] Directories: [.Custom, custom, /repository/.Custom, /repository/custom]
    [07.17.16 21:55:35.714 INFO main com.backup42.service.CPService] NOT waiting for custom skin to appear
    [07.17.16 21:55:35.714 INFO main com.backup42.service.CPService] NO customizations found.
    [07.17.16 21:55:35.714 INFO main com.backup42.service.CPService] END Copy Custom
    [07.17.16 21:55:35.719 INFO main backup42.common.config.AppConfig] Loading from default: , /volume1/@appstore/CrashPlan/conf/default.service.xml
    [07.17.16 21:55:36.292 INFO main backup42.common.config.AppConfig] Loading from my xml file:, conf/my.service.xml
    [07.17.16 21:55:36.559 INFO main up42.common.config.ServiceConfig] ServiceConfig:: Loading ServiceConfig, newInstall=false, configVersion=8, configDateMs=1462478384822, installVersion=1435726800452, currentVersion=1435813200470
    [07.17.16 21:55:36.561 INFO main up42.common.config.ServiceConfig] ServiceConfig:: OS = Linux
    [07.17.16 21:55:36.899 INFO main com.backup42.service.CPService] AuthorityLocation@986939266[ location=central.crashplan.com:443, hideAddress=false, isLocked=false ]
    [07.17.16 21:55:36.901 INFO main com.backup42.service.CPService] Checking Java memory heap max.
    [07.17.16 21:55:36.904 INFO main com.backup42.service.CPService] Previous Java memory max heap size was 1024
    [07.17.16 21:55:36.908 INFO main com.backup42.service.CPService] END Loading Configuration

    But then it silently fails.

    BTW: This is what I was working with before giving up.
    > sudo su
    > cd /var/packages/CrashPlan/target
    > mkdir tmp
    > cd tmp
    > cat ../upgrade.cpi | gzip -d -c – | ../bin/cpio -iv
    > mv lib ..
    > mv lang ..
    > cd ..
    > chown root.root lib lang

    Reply
    1. aadhoc78

      BTW, with the jar file in place, I found the error in target/log/service.log.0:

      [07.18.16 09:58:28.173 ERROR main com.backup42.service.CPService] Error starting up, java.lang.UnsatisfiedLinkError: no jtux64 in java.library.path
      STACKTRACE:: java.lang.UnsatisfiedLinkError: no jtux64 in java.library.path
      at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)

      I found the lib/*.so files, but couldn’t figure out where they went. Also saw the libjtux.jar file.

      Reply
  16. Luca

    I definitely moved to CrashPlan on RasberryPI.
    I am sorry because I donated Patters work several times, but I cannot wait weeks each time CrashPlan decides to upgrade its a product.
    Thanks for your work, but on Raspberry it is much, much simpler.

    Reply
    1. semperfidelis

      Luca,

      What guid are you using for installation on RasberryPi? Does it pick up an existing backup? I don’t want to have to start completely over.

      Reply
      1. Luca

        Some pages ago I explained everything to work with Raspberry and CrashPlan. I adopted the Nas so I did not have to upload 300 Gb again

      2. semperfidelis

        Thanks, I’ll go search for it. Part of the difficulty of this stuff is keeping up with a thread with so many comments.

      3. semperfidelis

        No. I think I’ve clicked on “Find Older Posts” a few times and searched for Luca on the page but can’t find a post where you talk about moving to RasberryPi. If you refer to an external link can you simply post the link here so I don’t have to keep searching for it?

  17. Scott Potter

    Google failed me. Can someone share the default syno_package.vars file?

    Background: Like mgittelman I had to edit /var/packages/CrashPlan/INFO to an older version, and afterwards the syno_package.vars file was missing or very short, but everything worked once I added back the USR_MAX_HEAP. Right now the file is just:
    MANIFEST_PATH_SET=Tru
    USR_MAX_HEAP=3100M
    MANIFEST_PATH_SET=True

    I’d like to edit the original comments back in just so I have them for reference. Thanks.

    Reply
  18. Wayne

    Hi All…

    Just another oddity to toss into the mix.

    I have noticed that the backup directory is now located at:

    “/var/packages/CrashPlan/target/backupArchives/”

    Not the usual crash plan share mount point.

    Cheers..!!

    Reply
  19. Jason

    I appreciate the work that patters and the rest of you have done, but I’m tired of continually having to go fix Crashplan every time an update comes out. I’m switching to B2 cloud sync. Hope it works better. Good luck to you all.

    Reply
  20. Ian H

    I think my last comment got lost … anyway … just to add .. these instructions worked for me ..
    Things to look for … I needed to re-start about 3 times before new _ui.info file appeared after un-installing then removing the directories and re-installing …

    https://crashplan.setepontos.com/crashplan-4-7-0-installation-fix-for-synology-1435813200470_344-july-2016/

    Needed to adopt the existing the backup which took a while – but all good now for 4 days ..

    Reply
  21. patters Post author

    Hi everyone,

    I have had some time to investigate why my NAS has been failing to backup and it was because Code 42 pushed an update around the 14th July. This is a new subrevision of version 4.7.0 (build 344). It looks like it failed to auto-upgrade because cpio isn’t in the path for scripts launched from the CrashPlan Java process. I thought I had fixed that in version 0040 but obviously not. As some of you noticed, Code 42 freshened their installer so this condition was fixable simply by removing and re-installing the 0040 package.

    I have just created a new version 0041 which aims to amend the cpio path in the auto-upgrade scripts which should hopefully solve similar future issues, but this version also contains a significant new enhancement – now Synology users can elect to have CrashPlan use its own dedicated Java 7 JRE, regardless of the system Java package version. This is useful when you may have conflicting requirements for other Synology packages, like Serviio which needs Java 8.

    The other big bonus here is that I’m adding support for the 64bit full (not Embedded) Java SE 7 runtime on systems that support it (most Intel systems post-DSM 6.0). This will mean that users of well equipped NAS units can allocate more than 4GB of RAM to CrashPlan. The mechanism is identical to my Java Embedded packages – you need to provide the Java binary download in the ‘public’ shared folder. To determine the exact requirement, start the installer and it will throw an error which will tell you which file you need to download from Oracle, and it will provide a tinyurl web link.

    Since this is quite a substantial change, rather than releasing it directly on the repository I’d like a few people to try it and report back here first, in particular the 64bit JRE (I don’t have a 64bit system). Files available here:

    http://packages.pcloadletter.co.uk/downloads/crashplan4.7.0-merged-0041.spk
    http://packages.pcloadletter.co.uk/downloads/crashplanpro4.7.0-merged-0041.spk
    http://packages.pcloadletter.co.uk/downloads/crashplanproe4.7.0-merged-0041.spk

    Thanks for testing!

    Reply
    1. B. Good

      I have a stock DS412+ and I don’t believe I have any other packages that need Java. Will I be able to remove the “Patters Java” and let CrashPlan use its own Java? Or is there a version built into DSM 6?

      What sequence of steps would be needed to remove Patters Java and switch to another version? My goal is to keep things simple so that CrashPlan breaks less often.

      Thanks again, Patters, for *all* your hard work over the years!!

      To those who have never donated, please consider clicking the small yellow “PayPal” donation link in the right-hand column of this page. I’m sure even a few Pounds, Dollars, or Sheqels tossed Patters’ direction would be appreciated!

      Reply
      1. patters Post author

        Yes you can remove the standalone Java package if you have no need of it. No there isn’t on included in DSM, but Synology did later offer their own equivalent of my package (with the same licence issue requiring a separate download from Oracle). I think it was only for Intel systems though, and it’s the full Java SE, not Java SE Embedded.

      2. B. Good

        Well, it sounds like using the CrashPlan java takes the same level of effort on my part and gets me the bloated full version I don’t need. So I will stick with your Patters Java.

        I do wonder about a poster earlier today who warned that Java 8 was missing a LOT of his files during the backup that switching to Java 7 corrected. Patters, have you seen that behavior?

        Thanks again!

      3. patters Post author

        I haven’t had that to my knowledge (I searched my log for that issue) but that’s kind of what motivated me to make that change. I use Serviio which must use Java 8, so it makes sense for me to be able to allow CrashPlan to use Java 7 if that’s what Code 42 bundles with the official install. I hadn’t realised that Code 42 were not making an effort to move to a recent and securely maintained JRE.

      4. B. Good

        My install in running once again. This time, however, CP seems to have dumped the bulk of my data set on two of my remote locations. I have to say I’m very leery how quickly and without warning CP dumps and wants to start nearly from scratch. It’s going to take over a week to get back to where I was. Maybe this isn’t a reliable enough approach.

      1. Tom K.

        Yes. Just updated on the second server (DS1815+) as well. Both are using the packaged JRE w/ latest binary download (jre-7u80-linux-x64.tar.gz).

        I did notice that the logs are defaulting to GMT timestamps now though…

      2. patters Post author

        Thanks, I’ve squashed that bug. I had typed {$SYNO_TZ} instead of ${SYNO_TZ}. I’ve updated the files, please manually re-install over the top of the existing version.

      3. Tom K.

        Confirmed squashed.

        Tough to catch those little Greenwich bugs from within the UK. Thanks!!

    2. semperfidelis

      Manual upgrade worked. Thanks for releasing this. I’m running on a DS713+ and willing to try the 64 bit Java but I’m not sure how to install it.

      Reply
      1. semperfidelis

        I figured it out. It’s installed using a dedicated Java 7 x64 now and running fine.

    3. CSim

      I’ve just installed it now and CP is running for the first time in several days. Thanks for all your efforts.

      Reply
  22. jmcturnan

    Thanks! Your timing was perfect, I was fighting with v0040. Installed and its now synchronizing happily. Thus far its looking good. You really should consider taking donations from folks!

    Reply
    1. patters Post author

      There is already a donate button on the right margin of the page, under “Most popular” and “Recent Articles” and the tag cloud widget :)

      Reply
      1. Jon Etkins

        My CP was still working, but I always like to run the untweaked Patters package whenever possible, so I upgraded this evening. Happy to report that all went fine, but a couple of observations:

        1) All messages in history.log.0 now have the correct timestamps. Previously, most (but not all) messages were one hour off, as if they weren’t being adjusted for DST, for example:
        I 07/22/16 02:20AM Stopping CrashPlan
        I 07/22/16 01:20AM Not ready for backup from JON-PC. Reason: The destination is not available
        I 07/22/16 01:20AM Not ready for backup from JAYLEN-PC. Reason: The destination is not available
        I 07/22/16 02:21AM Synology Package Center updated CrashPlan to version 4.7.0-0041

        2) After creating a public share to hold the java7 package, I decided to add it to my CP backups, and when CP rescanned the NAS after I saved the updated selection list, it found a bunch of extra files that it then proceeded to back up, just as someone else reported earlier. I too had been using Synology’s Java8 previously, so maybe there IS some sort of problem with Java8 and CP.

      2. patters Post author

        Hi thanks for the feedback

        1) which Java package had you used prior to this? Looks like the Synology Java package isn’t setting the timezone correctly. My packages do correctly set the timezone.
        2) several people have corroborated this finding now, and Code42 has also started to bundle a JRE7 with the product now which is what influenced me to do the same.

  23. adam

    I’ve just downloaded and installed it – had to redownload the java binary download and from there it was straight through

    great news, it looks like its working!! Currently its re-synchronizing with crashplan online and compacting versions for an inbound backup.

    prior to installing the packages above, i had not deleted the previous version or made any changes. I just installed the package above over the top

    thank you heaps patters!!

    i’ll update again tomorrow once its finished synchronizing

    Reply
  24. Phil

    DS1511+ here, I uninstalled the separate Java 8 runtime which I didn’t need, grabbed correct java 7 package from oracle per crash plan install instructions, and installed your updated crashplan package, updated java heap size in /var/packages/CrashPlan/target/syno_package.vars, all is well! Thank you!

    Reply
  25. Greg

    Hi, I updated to the latest version (7/20) but CP still doesn’t start? Is there something particular to do?

    Reply
      1. Greg

        it’s a DS716+… about the dedicated java runtime, I don’t change anything ? I’m sorry if you’ve already answered it, but how can I switch to the dedicated one ? Thanks again

      2. patters Post author

        To use the dedicated Java runtime is a choice in the package installation menu. However for licensing reasons you will need to fetch the Java download yourself from Oracle. Use my earlier link in the comments to the package files, and use the manual install option in Package Center to re-install over the top of your current installation. The pre-requesites part of the install will fail and tell you exactly which Java file you need to fetch for your system. You need to drop it in a shared folder called ‘public’ which you will need to create in DSM’s Shared Folder Control Panel if it does not already exist. Then install the package again and it will use that Java instead.

      3. Greg

        Thanks Patters, I will give a try to this. I’m going to uninstall crashplan and do a new install. I’m just afraid about losing everything and having to upload my data again (1.5 tb). Is it safe to uninstall crashplan from my nas, installing it again ? (sorry for being a such noob)

      4. Greg

        So I downloaded the package from your link, put the correct java package in public. Crashplan has been installed, and is actually correctly running. BUT, I just don’t figure out how to make it link to crashplan app on OSX (and on my online crashplan account, the NAS’s size is now 0MB and Complete at 0%)… How to link everything back as before ?

      5. Greg

        sorry for the triple post…. I think I got it, I forgot to add the NAS’s IP into ui_info.
        It’s syncing now… Big thank you

  26. Domingo

    Hi, first of all I’d like to thank patters for keeping the crashplan package updated and running.

    I’m having a littel problem with the new package. I’ve just installed it and, although it’s running, it’s seeing my nas as a whole new pc with 0 files. Until the last update I’ve been backing up from the same nas and have 1.4 TB of backed up data, but now, when I log in to Crashplan via their web page or their pc aplication, I can see two different computers with the same name but different GUID numbers.

    Anyone have a clue as what may be the cause?

    Thanks!!

    Reply
    1. patters Post author

      Not sure what’s happened there but you need to adopt the old backup. I think I explained how to do that manually the text on this page (replying from my phone).

      Reply
  27. alan

    thanks patters ! My CP stopped working around 60 days ago. Never did spend a whole lot of time fudging with this. This package and a upgrade to my Java seems to do the trick. We’ll see how it goes but so far, it’s scanning and ~pruning~ data

    Reply
  28. Bob Collins

    I have the latest version of CrashPlan running now with Java8, so if I update to the latest package, can I keep things they way they are, or is either option (use default Java, or embedded) going to break things on me and require me to foll with it to get it working again?

    It broke recently when CP pushed out their update to 4.7.0, but I got it running again and don’t want to break it with this update.

    Please advise!

    Reply
  29. Bob Collins

    Never mind, I went ahead and applied this update along with using your dedicated JAVA, and it is working fine, even kept my HEAP SIZE statement.

    Reply
  30. markhaller

    Hi there

    I’m struggling here. Installed the recommended Java package and your app and I’m told it’s running. I stopped the service, and started again – I can see it’s Running.

    I’ve installed the client on my laptop. I then SSH’d (I needed to sudo -i to elevate to root) and carried out the cat command, copied the contents and pasted

    conf/ui_mark_.properties file has:
    #Sun Jul 24 09:38:10 BST 2016
    window=400,130,800,610
    servicePort=4243
    serviceHost=192.168.1.190

    .ui_info has:
    4243,NUMBERHERETAKENOUT,192.168.1.190

    I’ve disabled the CrashPlan service on the laptop and then stopped it.

    I run the app and after a long wait, I’m told it can’t connect and do I want to retry.

    I can see from the log:

    [07.24.16 21:20:46.586 INFO connect ackup42.service.ui.UIInfoUtility] Loaded address=192.168.1.190, port=4243, and token from location=C:/ProgramData/CrashPlan/.ui_info
    [07.24.16 21:20:46.587 INFO connect com.backup42.desktop.CPDesktop] Connecting to service at 192.168.1.190:4243
    [07.24.16 21:20:48.338 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #1, retrying in 4000ms
    [07.24.16 21:20:53.346 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #2, retrying in 4000ms
    [07.24.16 21:20:58.355 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #3, retrying in 4000ms
    [07.24.16 21:21:03.362 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #4, retrying in 4000ms
    [07.24.16 21:21:08.367 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #5, retrying in 4000ms
    [07.24.16 21:21:13.372 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #6, retrying in 4000ms
    [07.24.16 21:21:18.472 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #7, retrying in 4000ms
    [07.24.16 21:21:23.627 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #8, retrying in 4000ms
    [07.24.16 21:21:28.632 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #9, retrying in 4000ms
    [07.24.16 21:21:33.691 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #10, retrying in 4000ms
    [07.24.16 21:21:39.177 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #11, retrying in 4000ms
    [07.24.16 21:21:44.256 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #12, retrying in 4000ms
    [07.24.16 21:21:49.376 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #13, retrying in 4000ms
    [07.24.16 21:21:54.382 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #14, retrying in 4000ms
    [07.24.16 21:21:59.390 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #15, retrying in 4000ms
    [07.24.16 21:22:04.426 INFO connect com.backup42.desktop.CPDesktop] FAILED on attempt #16, done
    [07.24.16 21:22:09.457 WARN main om.backup42.desktop.SplashWindow] EXIT – unable to connect to CPService
    [07.24.16 21:22:09.473 INFO Thread-4 com.backup42.desktop.CPDesktop] EXITING… Normally

    I’ve actually uninstalled the app from the NAS and reinstalled and followed instructions again … after re-reading and checking your instructions so many times :-)

    What am I missing?

    Thanks!

    Reply
  31. markhaller

    Oh one more … you ever thought about implementing some free forum here, or even Disqus, instead of this super-long comments list :-) Your solution is superb!

    Reply
  32. Troy

    Patters,

    I’ve been a long time user of your port and track your mailing list constantly. The latest 4.7.0 package installs fine, and once installs it synchronizes but when it gets to the point of actually backing up files it keeps crashing and restarting. I have tried reinstalling from scratch multiple times – using the dedicated Java build you included vs. using the system level java (the old way) and the same result keeps happening. In the /Volume1/@appstore/Crashplan/bin directory there are a few dozen restart logs and when you cat them the following information is there. There clearly is something going on here.

    restart.2016-07-25_07.56.54.log
    Mon Jul 25 07:56:54 CDT 2016 : /volume1/@appstore/CrashPlan/bin/restart.sh
    Mon Jul 25 07:56:54 CDT 2016 : APP_BASENAME=CrashPlan
    Mon Jul 25 07:56:54 CDT 2016 : DIR_BASENAME=crashplan
    Mon Jul 25 07:56:54 CDT 2016 : Stopping using /var/packages/CrashPlan/scripts/start-stop-status…
    Stopping CrashPlan …
    Mon Jul 25 07:57:02 CDT 2016 : Sleeping 10 seconds…
    Mon Jul 25 07:57:12 CDT 2016 : Starting using /var/packages/CrashPlan/scripts/start-stop-status…
    Starting CrashPlan …
    Mon Jul 25 07:57:14 CDT 2016 : New Service Process below:
    Mon Jul 25 07:57:14 CDT 2016 : Exiting restart script

    Reply
    1. Jon Etkins

      Have you checked the size of your Java heap? Whenever I see that sort of behavior, it’s because my heap setting got clobbered somehow.

      Reply
  33. Greg

    Hi,
    Since I reinstall crashplan on my syno, my ui_info file on my mac reset each time I reboot, so then I have to reenter token and ip, any chance you know why this happens ? thx

    Reply
    1. Troy

      On your mac side after you re-enter the token and IP you need to make sure you are root and type the following command.

      chflags schg .ui_info

      Now what this means is that it will never be written over, but if you ever need to modify your .ui_info file because you reinstall the package on the NAS side you will need to type

      chflags noschg .ui_info

      before you edit the file so it can be saved. After you edit and update you then do the first command to lock it from being written over.

      Reply
  34. Richard

    I couldn’t figure out why Crashplan was backing up the backup set again. Looks like it actually moved the folder locally on the NAS under Crashplan instead of where it had been pointing on the external USB drive. I’ve selected the old location and it seems to have accepted that an is doing a block check and sync. Hopefully that fixes that.

    Reply
  35. Thor Egil Leirtrø

    Upgraded to latest version. It reset the heap size and regenerated the UI guid. After that was fixed it spent two days resyncing for some unknown reason. Now it’s smooth sailing again uploading >50GB worth of pictures from last weeks jazz festival.

    DS412+ / 2GB RAM / DSM 6.0.1-7393 Update 2

    Reply
  36. Troy

    I’m trying to come up with the optimal Java settings for CrashPlan. I’m running a DS1513+ and it has 2GB of memory. Right now my run.conf has the following settings – where I modified the -Xms256m and -Xmx1536m. I didn’t touch the GUI_JAVA_OPTS from the defaults.

    Does the 1536m use 1.5GB of my physical memory for java or does it use swap for that? I didn’t want to go much higher for fear if it was using physical memory I needed 500m for other packages that are running on the NAS. Does anyone have any baseline of what is the optimum settings to use to get maximum performance out of CrashPlan?

    SRV_JAVA_OPTS=”-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms256m -Xmx1536m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Djava.io.tmpdir=/volume1/@tmp -Djava.net.preferIPv4Stack=true”

    GUI_JAVA_OPTS=”-Dfile.encoding=UTF-8 -Dapp=CrashPlanDesktop -DappBaseName=CrashPlan -Xms20m -Xmx512m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false”

    Reply
    1. curby.net

      The rule of thumb is 1GB ram per 1 TB of backup data or 1 million files, whichever’s higher. E.g. 1 TB over 2 million files would be 2GB of ram, or 4 TB over 5k files would be 4 GB of ram. However, I only ever changed one memory setting, not two, and never set it the way you do. Perhaps you’re following a tutorial or advice that I haven’t come across yet? I’d be interested in hearing more.

      Reply
      1. Troy

        Thanks for the response except the bigger question is if I only have 2GB of physical RAM and have more than 2TB of disk, does setting the Java heap use swap memory or does it actually require physical RAM? What I mean is I don’t want to set the memory over 2GB and that’s greater than my physical RAM unless someone assures me it will swap and use disk to cover the cache size.

        As far as setting the Java heap, yes there have been numerous posts over the years that is the way to permanently set the memory but I am also questioning best practices here because nobody has ever specifically address all 4 of the options – meaning the SRV_JAVA_OPTS vs. GUI_JAVA_OPTS as well as the Xms and Xmx settings.

        If anyone knows the answer/guideline here I’d appreciate it.

    2. curby.net

      Replying to your OP so we don’t endlessly nest. The idea behind increasing Java heap size (according to Crashplan) is that it might crash if you don’t allocate enough memory for it. If you’re not crashing and are successfully backing up more than 1 TB per GB ram, I’d say you’re fine.

      If you ever configured Java to be able to use more than physical memory, and it actually tried to consume more than physical memory, it would have to swap, and at that point performance would tank even if the service doesn’t crash. You seem to indicate that this would be a satisfactory outcome, but I worry that putting such a load on your system’s memory would lead to poor performance.

      In your OP you mention optimum settings for maximum performance. IMO that means having at least 1 GB ram allocated per 1 TB data, and then having more than that amount of physical ram on the NAS to support other processes. Since your 1513+ supports RAM expansion, that should be doable, and would be the safest bet. If you’re interested in max performance, you will want to minimize swapping to disk.

      However, I’m not sure you’re actually talking about the best-case scenario here. If you’re instead concentrating on your existing constrained environment, then I’d recommend setting Java to less than physical so long as it doesn’t crash, and trying to minimize swapping.

      Of course, these are just rules of thumb. As for the specific settings under constrained memory deployments, I have no idea. Hope this is helpful regardless! :)

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s