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


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

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

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

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


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


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

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

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

  exit 0
}


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

  exit 0
}


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

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

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

 exit 0
}


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

  exit 0
}


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

start-stop-status.sh

#!/bin/sh

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

  restart)
    stop_daemon
    start_daemon
    exit $?
  ;;

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

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

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

esac
 

install_uifile & upgrade_uifile

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

Changelog:

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

6,051 thoughts on “CrashPlan packages for Synology NAS

  1. Stig

    It seems the upgrade breaks because /var/packages/CrashPlanPROe/target/upgrade/1388728800370.1419325211508/upgrade.sh attempts to restart the Crashplan engine:
    Tue Dec 23 09:21:16 Asia 2014 : Starting using ../../bin/CrashPlanEngine…
    /var/packages/CrashPlanPROe/scripts/start-stop-status: upgrade.sh: line 10: ../../bin/CrashPlanEngine: not found

    This fails because there is no bash available. Editing the script to use /bin/sh instead seems to work, but now I get this error in upgrade.log:

    Could not find JAR file ../../bin/../lib/com.backup42.desktop.jar

    Reply
    1. Bob Collins

      CrashPlan stopped on my DS1812+ just yesterday. It fetched an upgrade of CrashPlan and then stopped.

      Everything is latest version and it was running until mid morning, then it stopped.

      Any word on an update coming to your package or a fix for this?

      Reply
      1. Kalda

        If you want to upgrade to 3.7.0 – update path in: /var/packages/CrashPlan/target/upgrade/[numbers]/upgrade.sh like Stig wrote – but there’s other bug (just in desktop, so I hope it’s not big deal at Synology).

        If you want cancel the upgrade and stay at 3.6.4 and wait for upgrade from PCLoadLetter – just delete everything in folder /var/packages/CrashPlan/target/upgrade/ and start CrasPlan.

      2. fluffy

        yeah, same thing happened here too. Looks like the package’s automatic-fix thing is no longer able to do so. If I manually start the service I just get a bunch of error output regarding ‘ps’ syntax being wrong.

        I tried uninstalling and reinstalling the package but that seems to just get 3.7.0 outright instead of letting me stay on 3.6.4 and preventing the upgrade. Bleh. Hopefully the package will get fixed soon.

      3. Chris Jones

        I uninstalled and attempted to reinstall via Package Center. I now cannot even install it – Package Center simply throws a “Failed to Install: Crashplan” error.

      4. Chris Jones

        I resolved all of my problems with the following posts:

        FLUFFY
        Ah, the fix was really simple – you just go to the package manager settings and allow packages from anyone. And 0028 seems to be working just fine for me now.

        Thanks for setting this up! Trying to manually patch everything was painful and seemed like a lost cause. :)

        HARV
        It is working for me, but it took a couple of extra steps beyond those of Casper’s recommendations.

        Here are the full instructions based on my post above. https://pcloadletter.co.uk/2012/01/30/crashplan-syno-package/comment-page-22/#comment-104735

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

        mv /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh.old

        Note that for the second set of commands, the second part of the 1388728800370 file name will be randomized each time.

        Thanks to Casper for figuring out the initial steps.

        – Harv

      5. Matthew

        Same here. The current package will install and run fine. However, after starting it download the new 3.7.0 crash plan update and then will refuse to run.

  2. Stig

    OK. 3.7.0 is up and running now. My dirty fix, roughly:

    (all as root using ssh)
    Go to the upgrade directory /var/packages/CrashPlanPROe/target/upgrade/1388728800370.1419325211508/

    Make upgrade.sh executable with chmod +x upgrade.sh
    Modify upgrade.sh, and remove or comment these two lines:
    echo `date` : Removing old jar files… >> $logFile
    $RM ../../lib/com*42*.jar >> $logFile 2>&1

    (If com.backup42.desktop.jar is already deleted from ../lib, then put it back there)

    Modify ../../bin/CrashPlanEngine so it´s using /bin/sh instead of /bin/bash

    Run upgrade.sh. It will not work completely, but loop trying to start Crashplan. ctrl-c to stop it.

    Delete 1388728800370.* from /var/packages/CrashPlanPROe/target/upgrade/

    Start Crashplan service as normal in DSM Package Center. Package center will still show the old version, but the log will show that 3.7.0 is running.

    Have a great Christmas with all your files backed up!

    Reply
    1. Mane

      Thank you Stig for detailed “tutorial”.
      Same issue here, with DS412+ (4GB RAM) and DS5.1-5021 update 2.
      I did like mentioned above, but running ./upgrade.sh provides this entry in upgrade.log:
      ################
      Thr Jan 8 22:44:22 CET 2015 : Starting using ../../bin/CrashPlanEngine…
      ../../bin/CrashPlanEngine: line 1: syntax error: unexpected redirection
      Thr Jan 8 22:44:22 CET 2015 : Restarting CrashPlan Backup Engine…trying again 7
      Thr Jan 8 22:44:22 CET 2015 : Sourcing ../../install.vars…
      Thr Jan 8 22:44:22 CET 2015 : Stopping using ../../bin/CrashPlanEngine…
      ../../bin/CrashPlanEngine: line 1: syntax error: unexpected redirection
      ###############
      Any ideas , where to search and go on?

      Reply
      1. Mane

        After doing it again and again, now everthing is working fine :-)
        Thank you Stig for his tutorial.
        – my post above is now obsolete and you can delete it.

    2. Martin

      So I’m broken :(

      Tried following the above advice, but couldn’t complete:
      (If com.backup42.desktop.jar is already deleted from ../lib, then put it back there)

      I now have a none working Crashplan. Suggestions to resolve, or do I just wait?

      Reply
      1. Martin

        I was able to restore com.backup42.desktop.jar from my laptop’s Crashplan installation.

        Crashplan now starts on the Syno, but shows as 3.6.4 and I can’t connect the TrayUI to it.

      2. chrisn

        Yeah, I’m having the same issue now. It looks to be running, I’ve upgraded my local crashplan to 3.7.0, but I still can’t connect to the headless crasplan running on synology.

      3. daveS

        +1. I have the same issue. Headless now works after doing Casper’s recommendation but client not working. I’m using mac 3.6.3 version. It did work initially after I made Casper’s changes but once I closed it it won’t open again.

      4. joek

        Same issue. I have played around with the firewall rules on my ds412+ but still nothing. I can’t even telnet on those ports though the syno does show listening on 4242 and 4243 when I do a netstat

      5. joek

        I got the headless client working! Had nothing to do with the Synology side.

        I was wrong about the telnet not working. Putty didn’t like it but windows telnet connected and saw garbled text. So that was not the issue.

        What I did was fully uninstall the old version (3.6.3) on my PC (Win 8.1×64). I downloaded the latest release from crashplan’s website and re-installed. After messing with my local PC backups going to my syno and ensuring it completed a backup, I then made the proper changes to the ui.properties file located in C:\Program Files\CrashPlan\conf . For those who have for gotten, remove the # sign from the front of these two lines below and changed put the Synology IP and Port 4243 in the correct place.

        serviceHost=192.168.1.x (Put in Synology IP Here)
        servicePort=4243 (Ensure port 4243 is here)

        After getting the Syno side worked out, you MUST upgrade your client side and make sure you change the properties.ui as the upgrade/re-install will wipe the changes.

        Hope this helps.

      6. Rick

        I can confirm this works (Win 7 64-bit).

        Don’t forget to stop/disable the Windows service also, if you don’t need it on your Windows machine.

  3. Brutus (@brennokbob)

    I just expanded my memory on my 2nd 1812+ so I figured I would install Crashplan finally. I already have it installed on the first Synology. I installed Java 7 which is updated and running. I get Crashplan failed to install everytime I try to install the package. I don’t know if I am missing something or if one of the later Synology Updates broke the install.

    Reply
    1. lucianf

      Experiencing the same problem. I tried installing the soft float Java to no avail. But I think I might have a better lead now. I found this in /var/log/messages:

      >Dec 30 20:09:30 DiskStation codesign.php: Signature file not found in archive.

      It appears that starting with DSM 5.1 Synology requires all packages to be signed (as per the Developer Guide: http://ukdl.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf).

      Is there any chance the current packages on pcloadletter could be updated to conform to this requirement?

      (for what it’s worth I’m using a DS214+).

      Thanks!

      Reply
      1. fluffy

        Ah, the fix was really simple – you just go to the package manager settings and allow packages from anyone. And 0028 seems to be working just fine for me now.

        Thanks for setting this up! Trying to manually patch everything was painful and seemed like a lost cause. :)

  4. joey westcott

    I had installed this a while back but never used it and at some point i removed the package. Now i just get the failed to install mesage right after the download during the install process, i dont know enough on where to go from here. can i get access to an install log file?

    screenshot from above seems to be missing so this is what i see -> http://imgur.com/qCfsR2U

    Reply
  5. iqadry

    Greetings All!

    I have a DS413 currently running DSM 5.1-5021, and have great reasonable success with CrashPlan installed for the last 1.5 years or so. When I updated to DSM 5.1-5021 as well as the 3.6.4 package everything because extremely unstable and and now when I try to start the CrashPlan package it won’t stay running for more than a few seconds until I get a message stating that “Crashplan has disconnected from the engine”.

    I decided to re-install 3.6.3 however still no change in the error. I’ve also tried connecting from 2 different machines to ensure it wasn’t the desktop version that was causing the issue.

    A new issue that I’ve encountered is that I cannot see the Crashplan community package from the PC Loadletter repository.

    Any thoughts? I’m tempted to do a factory reset of my synology settings and start from scratch.

    Cheers
    IQ

    Reply
  6. Ross

    Feeling kinda dumb – but I add your address to the source repo and I don’t see a crashplan option for ds2015xs – is this because it’s not supported?

    Reply
  7. lucianf0

    Experiencing the same problem. I tried installing the soft float Java to no avail. But I think I might have a better lead now. I found this in /var/log/messages:

    >Dec 30 20:09:30 DiskStation codesign.php: Signature file not found in archive.

    It appears that starting with DSM 5.1 Synology requires all packages to be signed (as per the Developer Guide: http://ukdl.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf).

    Is there any chance the current packages on pcloadletter could be updated to conform to this requirement?

    (for what it’s worth I’m using a DS214+).

    Thanks!

    Reply
  8. lucianf0

    Update: in DSM’s Installer settings, I changed the trust level to “any publisher” and everything went fine. So this is a workaround for now.

    Reply
    1. Peter

      THIS Helped me tremendously much!!!

      Just bought a new DS415play and upgraded to DSM5.1 during setup, then continued to get CrashPlan working. It just kept failing with no clear message. Tried the soft link thingies and created a public share as well, but this is what made the installation complete at least!

      Reply
  9. Alex

    Was running Crashplan 3.6.4-0028 on Synology DS 1512+
    Then it updated last night, and crashplan will not start anymore.
    I see a short status: Starting when trying to start the Crashplan, nothing in the Log file.
    Not even a starting or something.
    5.1-5021 Update 2

    Any ideas what to do?

    Reply
  10. kevin williams

    i updated to DSM 5.1 and had to reinstall crashplan 3.6.4-0028 (manually) as well as java 8. I got my desktop client talking to it and it’s confused. It shows the synology crashplan as a new computer with no license and the ‘old’ synology crash plan as existing. If I “deactivate” the, I get a warning that it will delete all files. I remember doing this transition in the past but I don’t see how, now. Please advise.

    Reply
  11. Nigel Harniman

    I am getting this error in engine_error.log:

    Exception in thread “W1797563540_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
    at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:21)
    at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:393)
    at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(BackupSetsManager.java:331)
    at com.code42.backup.path.BackupSetsManager.access$1600(BackupSetsManager.java:66)
    at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(BackupSetsManager.java:1073)
    at com.code42.utils.AWorker.run(AWorker.java:158)
    at java.lang.Thread.run(Thread.java:745)

    Backups are stuck on “Connecting to backup destination”

    I have tried changing the tmp dir location ensuring it has read and execute permission. Still no luck.

    I am running a Synology DS415+ with DSM 5.1-5021 Update 2.

    Reply
      1. goslow2gofast

        Issue resolved. I knew I was supposed to be using crashplan3.6.3-merged-0027,spk but accidentally used crashplan3.6.4-merged-0028.spk which causes the problem. Dropped back to 0027 and all is good again.

        Hoping patters can get this sorted out, but I understand there are many demands…

      2. fluffy

        How do you go about using alternate versions? This is the first community package I’ve ever tried installing on my DSM and it isn’t obvious to me.

      3. Funky

        I am still using crashplan3.6.3-merged-0027.spk but Crashplan not working since weeks. Crashplan is restarting scan every view minutes and at this moment I loose connection from the desktop app. I know there are issues with Power PC and I am wondering how you get Crashplan working on DS413?

      1. Funky

        I did exactly the steps you provided but still Crashplan on the NAS restarts scanning every view minutes :( and I am loose connection from the Desktop client.

      2. Funky

        Hi, I installed 3.7.0-0029 and Java 7 1.7.0_75-0030 on my DS413 and was now able to finish scan. But after analyzing a few files the Desktop client stops without any error message. Protocol shows that the service stopped. Error log shows log4j:ERROR Attempted to append to closed appender named [null]. I increased heap size to 1280M but still the same issue :( Any hints?

  12. Owen

    Hi,

    I’m trying to set this up and I have a Mac. Do you know where the mac version of conf/ui.properties file resides and if I have to modify it in a different way.

    Thanks

    Reply
    1. patters Post author

      /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties

      Easiest way to edit it is to run this from a command prompt:
      sudo nano /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties

      Ctrl-X to exit once you’ve made the changes, you’ll be prompted to save.

      Reply
    2. fluffy

      You can also edit the one in Library/Application Support/CrashPlan/ui.properties and just add the ‘servicePort=’ line to it. That might also make it easier to swap remote vs. local versions in and out without having to deal with permissions issues.

      Reply
  13. Cyrill

    If you are having issues with the CrashPlan service not starting, try the following:

    1. SSH into your NAS

    2. Navigate to the CrashPlan package directory:
    cd /var/packages/CrashPlanPROe/target/log

    3. Look at the engine_output.log:
    tail engine_output.log

    4. Look for the following message log file:
    JVM temp directory /var/@tmp does not exist!

    The update must have removed some paths/symbolic links that are required for java/crashplan to work properly.

    5. Navigate to the var directory
    cd /var

    6. Create a symbolic link to the existing /var/tmp folder
    ln -s tmp @tmp

    Note your particular NAS might have the tmp folder in a slightly different location. You can find the correct path in your engine_output.log

    Hope this helps

    Reply
    1. Jeff

      FYI, a more lasting fix for this would be to use the one that I posted a month ago;

      I’ve always had problems with crashplan not starting after rebooting. I’ve got a DS415+, and it looks like /tmp/@tmp is missing after a reboot.

      I edited /var/packages/CrashPlan/scripts/start-stop-status.sh and added a line near the top before the definition of TEMP_FOLDER that reads:

      test ! -d “/tmp/@tmp” && mkdir /tmp/@tmp

      Reply
      1. Jeff

        Wouldn’t an even better solution be to add:

        test ! -L /var/@tmp && ln -s /tmp /var/@tmp

      2. Jeff

        [quote]
        Wouldn’t an even better solution be to add:

        test ! -L /var/@tmp && ln -s /tmp /var/@tmp
        [/quote]

        Absolutely not!

        That would put the files in /tmp/ potentially impacting other files there, vs putting them into a unique directory for the jvm top manage.

        -Jeff

  14. Tim Larson

    I also had my DSM 1815+ auto-update the DSM software and now the Crashplan isn’t running. When I manually start it, the service “thinks” for 1-2 seconds, but it never starts running. It is almost as if something in the latest DMS “broke” the Crashplan install. I dunno how to get it running again. Re-install Crashplan?

    Help Please. Thanks.

    Reply
  15. Jeff

    I was having a lot of trouble with the current version so I tried uninstalling with the intent to reinstall, now I’m just getting ‘Failed to install “CrashPlan”.’

    I can’t seem to find any log on the system which gives more information about the failed install. Please help! I’m worried about my whole backup being deleted from the crashplan servers if I can’t get it back up and running soon.

    Reply
  16. Manny

    Configure Synology to backup to Crashplan Central. All was fine. Now I rebooted the Synology and the CrashPlan process Starts and the immediately Stops, although I never actually see it ‘running’ but the log only says started and stopped. Any idea.

    Reply
  17. wes

    my system cannot find crashplan, I setup the repo and this is on a ds214 system is there something I have to do to find your packages once I have added the repo?

    Reply
  18. patrick putteman

    Been using your package for almost 2 years now, works like a charm. However, since the last update, I can’t use the ‘start-stop-status.sh’ script anymore from the command line (or cron) as it returns the folowing error:

    grep: ./target/bin/run.conf: No such file or directory
    ./start-stop-status: source: line 20: can’t open ‘./target/install.vars’

    Any insights?

    P.

    Reply
  19. Niels Esge Rasmussen

    I’ve been using this package on my DS1812+ for a couple of years now. I have had problems in the past due to the size of my backup set, but finally seemed to have ironed all the kinks out. And then over Christmas I ran into a problem, that I simply have been unable to resolve.

    I’m running out of memory.

    There’s 3GB RAM in my machine and I have set the USR_MAX_HEAP to 1536M. That last value is the recommended maximum value from the Code42 support page on handling memory issues. I originally had the value set at 2048M, but I needn’t have bothered. When I look at the Resource Monitor on the Synology, I see the Java process slowly allocating more and more memory until somewhere around 1.5GB where it runs out of memory and crashes.

    This would happen because the embedded Java only supports a 32bit JVM.

    I found this article on how to set up Maven on a Synology (http://forum.synology.com/enu/viewtopic.php?f=27&t=40450) and it specifically instructs to install the 64bit (non-embedded) version of Java, so I would expect it to be a viable solution for the CrashPlan package as well.

    The later DSM versions come with a Java Manager package, and although it balks at installing 64bit JDK’s, it also relies on the non-embedded varieties of Java.

    I tried to install a 64bit Java on my system and then restart the CrashPlan service. Everything starts up fine, but then I get the engine error “Exception in thread “W30145090_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager”. A quick search on this issue suggests that there is something wrong with the tmp folder, but there isn’t. I suspect maybe it has something to do with the one line in the 0028 update log that says: “Intel CPUs no longer need the awkward glibc version-faking shim to enable inotify support (for real-time backup)”, but I do not want to downgrade my Synology package either.

    In general I am not out of options. There are many things I can still try out, including a manual install of Java and CrashPlan both, but I really, really don’t want to go down that path.

    The 1812+ comes with a 64bit Intel Atom D2700 processor, so my question invariably becomes: Why is this package relying on an embedded Java and not a regular Java, say a 64bit Java on the machines that support it?

    Now, I am sure there is a good reason, and I am overlooking something completely obvious here, but I had to ask anyway.

    Thanks in advance.

    Reply
  20. Mark

    Hi

    I am running Crashplan 0028 on my DS214 Play. I can connect the Crashplan client (from a Mac) and see that the backups are set up. I have 3 back up sets. The highest priority one has status of ‘Analysing’ It has been like this for days. Others are waiting for this to complete. The set is about 200GB.

    The client also disconnects/crashes all the time. When I re-open it, then the status is still the same. Looks like I have the start/stop issue that others are facing.

    It’s difficult to follow all of the other similar issues that people are raising. Would it be possible to post step by step instructions to work around this issue please?

    Thanks

    Reply
  21. itdk01

    Any news on Crashplan package support for Synology DS215j? It’s an Armada CPU, but should handle Crashplan.

    Reply
  22. Taha

    Hi – Firstly, thanks for developing this package for the Synology NAS devices.

    I recently migrated from a Windows Home Server (V1) solution that was backing up to CrashPlan. For the first couple of days after install everything seemed to be working fine. Yesterday I noticed the CP package was stopped on my NAS and it refuses to restart. I’ve reinstalled Java, the CP package, the CP client and it still won’t start up.

    The view log from the package manager windows shows each time that is trying to repair an upgrade in ‘/var/packages/CrashPlan/target/upgrade/’. A few lines before, it shows the upgrade was downloaded and installed successfully. The service stops and each attempt to restart it adds a repair line comment to the log.

    I’ve connected via SSH and have attempted to run the ‘start-stop-status.sh’ script and get the following output:

    DiskStation> ./start-stop-status.sh
    find: /lost+found: Permission denied
    find: /root: Permission denied
    grep: ./target/bin/run.conf: No such file or directory
    ./start-stop-status.sh: source: line 20: can’t open ‘./target/install.vars’

    My setup is as follows:

    NAS: Synology DS415play
    CP Package Version: 3.6.4-0028
    Java Version: 1.7.0_51 (7.0.51-0030)
    Client CP Version: Mac – 3.7.0

    Any help would be greatly appreciated!

    Thanks
    Taha

    Reply
  23. Marc

    Recent package update 3.6.4-0028 killed CrashPlan backups on my DS1512+ (DSM 5.1.5021 Update 2). To try to solve this problem, I’ve removed and re-installed both packages (Java 6, 7 and 8, and CrashPlan – in every possible permutation), and reviewed log files, but all I can come up with is this error on update (as shown in /var/packages/CrashPlan/target/upgrade/1388728800370.1420763497512/upgrade.log):

    Thr Jan 8 16:48:02 PST 2015 : Stopping using /volume1/@appstore/CrashPlan/bin/CrashPlanEngine…
    /var/packages/CrashPlan/scripts/start-stop-status: upgrade.sh: line 10: /volume1/@appstore/CrashPlan/bin/CrashPlanEngine: not found

    Keep in mind, this is the third full path I’ve created within the upgrade.sh file, trying to resolve this issue. Here’s what it looks like if I remove and re-install the CrashPlan package:

    Thr Jan 8 16:58:18 PST 2015 : Sourcing ../../install.vars…
    Thr Jan 8 16:58:18 PST 2015 : Stopping using ../../bin/CrashPlanEngine…
    upgrade.sh: line 10: ../../bin/CrashPlanEngine: not found

    In addition to this, I’ve changed settings to allow packages from any developer to run, and literally blown > 6 hours trying to make this thing run.

    Any advice anybody can provide would be greatly appreciated here…I’m completely frustrated at this point and going to step away from the keyboard, before anger levels go any higher.

    Reply
    1. Marc

      Just came back from dinner and decided to give it another try…same result. Here’s a copy of the log file:

      I 01/08/15 07:17PM CrashPlan started, version 3.6.4, GUID 574956158631543214
      I 01/08/15 07:17PM Upgrades available at central.crashplan.com:443
      I 01/08/15 07:17PM Downloading a new version of CrashPlan.
      I 01/08/15 07:17PM Download of upgrade complete – version 1388728800370.
      I 01/08/15 07:17PM Installing upgrade – version 1388728800370
      I 01/08/15 07:17PM Upgrade installed – version 1388728800370
      I 01/08/15 07:17PM CrashPlan stopped, version 3.6.4, GUID 574956158631543214
      I 01/08/15 07:17PM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1388728800370.1420773435117

      …then nothing. Dead. All I can do is restart. Help?

      Reply
      1. aaronspruit

        Having the same issue at this point. I’ve manually installed the current spk over the old and it works. However, then it downloads the new one and the upgrade script is bogus like you point out.

        I’ve tried various things with the upgrade script to no avail. The symlink exists to @appstore, so not sure what’s going on.

    2. aaronspruit

      Having the same issue at this point. I’ve manually installed the current spk over the old and it works. However, then it downloads the new one and the upgrade script is bogus like you point out.

      I’ve tried various things with the upgrade script to no avail. The symlink exists to @appstore, so not sure what’s going on.

      Reply
  24. b5b8d2

    Yup! Got the same thing! Looks like Code42 pushed out an update which broke all of our installs! DAMN THEM!!

    I’m guessing re-installing would be a quick fix, but would probably be broken shortly there after unless we can set something to say ‘don’t update’

    I wonder if we can just what that update dir and it won’t try to update..

    Hmmmm…

    Just when everything was working well!

    Reply
  25. Johnny

    I checked my logs and I am seeing the same thing as Marc following the upgrade. Anybody figured out a solution for this yet?

    Reply
  26. Firehorse

    Yeps. Same here. The crashplan update broke my installation too. Re-installing the package works only until the update has been initiated again. Any suggestions for fixes?

    Reply
  27. r3v1lo

    Same thing here…

    Removing /var/packages/CrashPlan/target/upgrade/ does not fix it, just fails to start again

    Removing entire package and re-installing results in recreating the upgrade folder and same happens again…

    Reply
  28. ahershler

    Reading your comments, I ran to check my own Synology (a RS3411). The CrashPlan client did not connect so I feared the worst. Logging in, Package Center reported CrashPlan as stopped after attempting the upgrade. I clicked Action->Run, and indeed it looked “stuck”. However, I waited for a relatively long time and it then reported “Running”. Looking in the log file I see:

    I 01/08/15 01:28PM – Unable to backup 1 file (next attempt within 24 hours)
    I 01/08/15 05:00PM Upgrades available at central.crashplan.com:443
    I 01/08/15 05:00PM Downloading a new version of CrashPlan.
    I 01/08/15 05:00PM Download of upgrade complete – version 1388728800370.
    I 01/08/15 05:00PM Installing upgrade – version 1388728800370
    I 01/08/15 05:00PM Upgrade installed – version 1388728800370
    I 01/08/15 05:00PM CrashPlan stopped, version 3.6.4, GUID XXXXXXXXXXXXXXXXXX
    I 01/09/15 10:56AM Synology repairing upgrade in /volume1/@appstore/CrashPlan/upgrade/1388728800370.1420729216905
    I 01/09/15 10:56AM CrashPlan started, version 3.7.0, GUID XXXXXXXXXXXXXXXXXX
    I 01/09/15 10:57AM CrashPlan started, version 3.7.0, GUID XXXXXXXXXXXXXXXXXX
    I 01/09/15 10:57AM Backup scheduled to always run
    I 01/09/15 10:58AM CrashPlan started, version 3.7.0, GUID XXXXXXXXXXXXXXXXXX
    I 01/09/15 10:58AM Backup scheduled to always run

    The CrashPlan client (still at 3.6.4) still did not connect so I downloaded a new version of CrashPlan Home for Windows, installed it, stopped and disabled the local CrashPlan service on the PC, edited the ui.properties file in two locations (C:\Program Files\CrashPlan\conf and C:\Program Files (x86)\CrashPlan\conf) to set serviceHost to the correct IP address of my Synology and set servicePort to the port my Synology is listening on, and then ran the CrashPlan client. It connected just fine and is showing my backup sets as before, with the same content. For each backup set it states “Synchronizing block information”.
    So it seems to work for me after this upgrade.

    Reply
    1. gungam

      Hi ahershler,

      can you estimate the time you have waited for the repairing attempt? According to your logfile the repairing attempt started in within the same minute as 3.7 starts his work.

      Reply
      1. ahershler

        Sure. I waited for approx. 5 minutes with the Synology Package Center open and a wait cursor displayed.
        To complete my details: I have a RS3411 running DSM 4.3.3827 Update 8 with Java 1.6.0_38 (yes, I don’t upgrade that often; my server is behind a firewall)

  29. gungam

    Same issue here with 3.7.
    Package tries to repair the update but it stops with:

    /var/packages/CrashPlan/scripts/start-stop-status: upgrade.sh: line 10: ../../bin/CrashPlanEngine: not found
    Fri Jan 9 12:00:30 CET 2015 : New CrashPlan Backup Engine:
    Fri Jan 9 12:00:31 CET 2015 : Exiting upgrade script

    in the upgrade.log

    history.log.0 ends with the following lines:

    I 01/09/15 11:38AM CrashPlan has downloaded an update and will restart momentarily to apply the update.
    I 01/09/15 11:38AM Installing upgrade – version 1388728800370
    I 01/09/15 11:38AM Upgrade installed – version 1388728800370
    I 01/09/15 11:38AM CrashPlan stopped, version 3.6.4, GUID XXXXXXXXXXXXXXXX
    I 01/09/15 11:41AM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1388728800370.1420799934742
    I 01/09/15 11:58AM Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1388728800370.1420799934742

    after this nothing happens any more…

    Reply
    1. Alex

      Hi,

      I had the same problem that crashplan didn’t work anymore, same entries in the log.
      You need to do some steps, but he it’s broken anyway. Not for everyone to understand.
      use at own risk.

      Fixed it using the help supported by Stig:(December 23)
      I made some comments left and right.

      OK. 3.7.0 is up and running now. My dirty fix, roughly:

      I used WinSCP, and mode SCP to the IP of the Synology.
      (all as root using ssh) Please note it is important to use the Root account, not a username admin or something. use the same password for Root as you have with Admin.

      Go to the upgrade directory /var/packages/CrashPlanPROe/target/upgrade/1388728800370.1419325211508/

      Make upgrade.sh executable with chmod +x upgrade.sh (you can change Properties of the file with WinSCP (especially if you don’t have much Command line experience)
      Modify upgrade.sh, and remove or comment these two lines:
      echo `date` : Removing old jar files… >> $logFile
      $RM ../../lib/com*42*.jar >> $logFile 2>&1

      (If com.backup42.desktop.jar is already deleted from ../lib, then put it back there)
      You can extract it from the 1388728800370.jar

      Modify ../../bin/CrashPlanEngine so it´s using /bin/sh instead of /bin/bash

      Run upgrade.sh. It will not work completely, but loop trying to start Crashplan. ctrl-c to stop it.

      Delete 1388728800370.* from /var/packages/CrashPlanPROe/target/upgrade/

      Start Crashplan service as normal in DSM Package Center. Package center will still show the old version, but the log will show that 3.7.0 is running.

      I needed to do an additional NAS restart before it worked.
      Hope this helps someone with the same problem.

      Mine now running 3.7, also upgraded the Windows Client to 3.70
      The upgrade from 3.6.4 to 3.70, on the Windows client force me to make the following change too.
      I can’t place a link here, but you can find it here:
      http://www.hanselman.com/blog/UPDATED2014HowToSetupCrashPlanCloudBackupOnASynologyNASRunningDSM50.aspx

      You need to edit the “C:\Program Files\CrashPlan\conf\ui.properties” text file and put in the IP address of your Synology. My Synology is called “SERVER” so I opened a command prompt and typed “ping server” and was told its address is 192.168.1.18. I needed to run my notepad as administrator to edit this file.

      NOTE: This is a Linefeeds only Linux text file so you’ll want to use Notepad2 or something OTHER than Notepad so you don’t corrupt this file. Make a copy.
      Pointing ServiceHost to the right place

      Reply
      1. gungam

        Hi Alex,

        it seems to work. Even without a NAS restart or a gui upgrade. Thanks for your help! And thanks to Stig who found the work around!

      2. John B.

        Thanks Alex!

        Your steps worked for me as well without NAS restart, but I upgraded the PC as I want the newer version.

      3. eldoudou

        That worked for me too on DS1010+ (DSM 5.1-5021 update2) without a restart (java embedded 1.6.0_38.0029).
        Thanks Alex.

      4. Michael Hardy

        Thank you! This also worked for me. Package center obviously won’t have the right version string, but Crashplan is certain about it being 3.7.0

        Versions:
        DS412+,
        DSM 5.1-5021 Update 2,
        Java(TM) SE Runtime Environment (1.7.0_67-b01, 32-bit)

  30. Martin

    So I’m broken :(

    Tried following the above advice, but couldn’t complete:
    (If com.backup42.desktop.jar is already deleted from ../lib, then put it back there)

    I was able to restore com.backup42.desktop.jar from my laptop’s Crashplan installation. Crashplan then started on the Syno, but shows as 3.6.4 and can’t connect the TrayUI, or to Central.

    I’ve then uninstalled and now can’t reinstall. The package installer fails.

    Syno 1513+ with Java 8

    Reply
  31. gungam

    After a restart of the nas it is broken again complaining about missing /var/@tmp directory.
    after creating it manually over ssh Crashplan runs again until the next system restart.
    But I’m although unable to connect the with the GUI.

    Reply
  32. Bob Collins

    Is there an updated package, or fix for the issue of the latest version of CrashPlan not running on Synology NAS or is one coming soon?

    Reply
  33. Paul Worthy

    Hi all Im still having issues so i hope one of you can help me
    first im going to copy what i did above with a few mods of what i did

    I used WinSCP, and mode SCP to the IP of the Synology.
    (all as root using ssh) Please note it is important to use the Root account, not a username admin or something. use the same password for Root as you have with Admin.

    DONE THIS NO PROBLEM

    Go to the upgrade directory /var/packages/CrashPlanPROe/target/upgrade/1388728800370.1419325211508/

    LITTLE DIFFERENT ON MINE AS I DONT HAVE PRO BUT DID THAT

    Make upgrade.sh executable with chmod +x upgrade.sh (you can change Properties of the file with WinSCP (especially if you don’t have much Command line experience)

    NOT 100% BUT I RIGHT CLICKED AND WENT TO CUSTOMER COMMANDS – CUSTOMIZE
    SAW EXECUTE UNDER DESCRIPTION SO I HIGHLIGHTED THAT AND CLICKED EDIT AND TYPED chmod +x upgrade.sh ON THE CUSTOM COMMAND
    KEPT REMOTE COMMAND SELECTED AND CLICKED OK

    Modify upgrade.sh, and remove or comment these two lines:
    echo `date` : Removing old jar files… >> $logFile
    $RM ../../lib/com*42*.jar >> $logFile 2>&1

    DELETED THIS FINE

    (If com.backup42.desktop.jar is already deleted from ../lib, then put it back there)
    You can extract it from the 1388728800370.jar

    THIS WAS GONE SO I GUESS IT IS SAYING COPY 1388728800370.jar AND RENAME IT AND PUT IT IN THE DIRECTORY

    Modify ../../bin/CrashPlanEngine so it´s using /bin/sh instead of /bin/bash

    SO I GUESS THIS MEANS TO OPEN IT AND EDIT THE TOP PART FROM
    #!/bin/bash
    TO
    #!/bin/sh

    Run upgrade.sh. It will not work completely, but loop trying to start Crashplan. ctrl-c to stop it.

    NOT SURE HOW TO RUN THIS I DID RIGHT CLICK AND CLICKED EXECUTE BUT NOTHING HAPPENED

    Delete 1388728800370.* from /var/packages/CrashPlanPROe/target/upgrade/

    DID THIS AND STILL SAME ISSUE
    I HAVE CRASHPLAN JUST NOT STARTING JUST KEEPS LOADING AND LOADING THEN STOPS AND STILL SAYS NOT RUNNING
    IN THE LOGS IT SAYS
    SYNOLOGY REPAIRING UPGRADE IN /VAR/PACKAGES/CRASHPLAN/TARGET/UPGRADE/1388728800370.1420825021853

    PLEASE HELP

    Reply
      1. Paul Worthy

        fixed it
        i deleted the wrong thing
        Delete 1388728800370.* from /var/packages/CrashPlanPROe/target/upgrade/
        i needed to delete the folder and not the .jar lol

  34. Casper

    There are 2 issues breaking the Crashplan package, after the autoupdate have been performed.

    No.1 for some reason the com.backup42.desktop.jar file is not copied into “../../lib” when the upgrade.sh script is executed. That means it is missing after the upgrade.

    No.2 Patters start-stop-status script is unable to rename upgrade.sh -> upgrade.sh.old, why i don’t understand. But because of this, very time you try to start the package from webinterface, it will run the upgrade script, which will fail after 10×10 seconds, approximately.

    My solution was:
    Connected to my system with a SSH client. Extracted the “com.backup42.desktop.jar” from the 1388728800370.jar, to the “lib” directory. After that I renamed the upgrade.sh script. After that Crashplan works for me, reboot is not required.

    How to do it:

    unzip /var/packages/CrashPlan/target/upgrade/1388728800370.jar com.backup42.desktop.jar /var/packages/CrashPlan/target/lib/

    mv /var/packages/CrashPlan/target/upgrade/1388728800370.1419325211508/upgrade.sh /var/packages/CrashPlan/target/upgrade/1388728800370.1419325211508/upgrade.sh.old

    Start Crashplan from the webinterface.

    Reply
    1. chrisn

      That worked! I ran:

      unzip /var/packages/CrashPlan/target/upgrade/1388728800370.jar com.backup42.desktop.jar -d /var/packages/CrashPlan/target/lib/

      mv /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh.old

      Reply
      1. Mala

        Thank you Casper /all,
        Crashplan is running again thanks to this support thread.
        Nothing worse than spotting Crashplan updated then broke

  35. B. Goodman

    To be clear, the upgrade to 3.7 that’s broken is being installed on your Synology NAS, right? Or is this installing on your Windows client and breaking? The log posted above is clearly from a NAS, but I’m trying to be certain I understand. Do all of you have your NAS devices set to upgrade packages automatically?

    Reply
    1. gungam

      I’m not 100% sure but about 90%.
      The whole thing has nothing to do with the DSM setting if you put the switch for automatic or manual upgrades of the DSM-Apps.
      Crashplan is a Java app and it is originally not written for DSM, so the upgrade routine is hard implemented in the Java code for all machines. Regardless what system you use it will automatically upgrade if there is a newer version on the server available.

      And yes, we are all talking about the crashplan server app on the synology NAS. Due to the circumstances that crashplan needs a GUI to be operated we although use a kind of client software on our PCs (Windows, OS X or Linux – doesn’t matter)

      On the Synology systems you can use Crashplan only in a headless mode. You need to configure it on a local system with the GUI.

      Reply
  36. chrisn

    I’m using the following steps based on the information above, but have been unable to get crashplan running again. It doesn’t appear to start successfully. Any ideas?

    # Install crashplan, wait for it to crash/stop
    cd /var/packages/CrashPlan/target/upgrade
    mkdir /var/packages/CrashPlan/target/upgrade/temp
    unzip 1388728800370.jar -d /var/packages/CrashPlan/target/upgrade/temp
    cp /var/packages/CrashPlan/target/upgrade/temp/c42_protolib.jar /var/packages/CrashPlan/target/lib
    rm -rf /var/packages/CrashPlan/target/upgrade/temp
    chmod +x /var/packages/CrashPlan/target/upgrade/1388728800370.1420845720488/upgrade.sh
    # Note the extension on the 1388728800370 directory will be different each time
    vi /var/packages/CrashPlan/target/upgrade/1388728800370.1420845720488/upgrade.sh
    # comment out:
    # echo `date` : Removing old jar files… >> $logFile
    # $RM ../../lib/com*42*.jar >> $logFile 2>&1
    # save & exit
    vi /var/packages/CrashPlan/target/bin/CrashPlanEngine
    # Change to /bin/sh from /bin/bash
    cd /var/packages/CrashPlan/target/upgrade/1388728800370.1420845720488
    ./upgrade.sh
    # Control-C when loop starts
    cd /var/packages/CrashPlan/target/upgrade/
    rm -rf 1388728800370.*
    # Restart Synology

    Reply
    1. chrisn

      Ignore my steps above – I followed Casper’s recommendation and that seems to work:

      unzip /var/packages/CrashPlan/target/upgrade/1388728800370.jar com.backup42.desktop.jar -d /var/packages/CrashPlan/target/lib/

      mv /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh.old

      Note that for the second command, the second part of the 1388728800370 file name will be randomized each time.

      Reply
      1. Harv

        I have it working. You need to copy the rest of the jar, lang, and conf files from the 1388728800370.jar upgrade package to the appropriate folders.

        c42_protolib.jar, swt.jar, and swt-64.jar go to the Crashplan/target/lib folder
        run.conf goes to CrashPlan/target/bin folder
        the files in the lang/ folder go to the CrashPlan/target/lang/ folder

        Note: I’m not entirely sure if you really need to copy over the run.conf and the lang folder. I just did it for good measure. The jar files in the upgrade package are different sizes than the original files and they need to be replaced.

        I also upgraded my desktop client to 3.7 as well. You may want to check and verify that you ui.properties file didn’t get overwritten. Mine got removed because I inadvertently installed the 32 bit version which completely deleted the conf folder from my original 64 bit installation.

        Regards,
        – Harv

      2. Plumb

        Thanks Casper & chrisn! Worked like a charm. I didn’t try logging in via the GUI client from my desktop machine; so I can’t speak to whether that is working. I’m just happy to have the backup engine running again. :) I’ll try to the GUI client later when I have some time to mess with it more and will report back if I find it isn’ working.

  37. Stephen

    Followed Casper’s instructions to get crashplan running on synology. Just like others have reported, cannot connect from a client to the the engine on synology. Hope that someone can help.

    Reply
  38. Ryan P.

    Hi – CrashPlan no longer shows up to install as a package in Package Centre… I re-added it and the Java, Minecraft, etc. show up but no CrashPlan… Running a DS213+. Was working great until I tried to uninstall/re-install this week. What’s Up???

    Reply
    1. Claude

      I’ve got the exact same problem CarshPlan disappear form package list but other package form pcloadletter still. Is there Anything to do to reinstall on DS213+

      Reply
  39. b5b8d2

    Crap!
    I wiped out the /var/packages/CrashPlan/target/upgrade/1388728800370.1420729328643 folder anyone know how to recover it, or maybe force another download of it? I’d hate to go through the whole re-install process again cause it then block-checks everything which takes WEEKS!

    Thanks!

    Reply
    1. Casper

      You can extract the 1388728800370.jar with this command
      unzip /var/packages/CrashPlan/target/upgrade/1388728800370.jar -d /var/packages/CrashPlan/target/upgrade/1388728800370

      Reply
  40. Harv

    It is working for me, but it took a couple of extra steps beyond those of Casper’s recommendations.

    Here are the full instructions based on my post above. https://pcloadletter.co.uk/2012/01/30/crashplan-syno-package/comment-page-22/#comment-104735

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

    mv /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh /var/packages/CrashPlan/target/upgrade/1388728800370.1420851880338/upgrade.sh.old

    Note that for the second set of commands, the second part of the 1388728800370 file name will be randomized each time.

    Thanks to Casper for figuring out the initial steps.

    – Harv

    Reply
    1. b5b8d2

      I followed the steps above, except the MV part and was able to start up CrashPlan with no issues now! YEAH!!!

      When I look at CrashPlan History it says CrashPlan started, version 3.7.0 so all appears A-OK..

      It’s just par for the course with an unsupported project, fortunately it’s not too hard to fix when it does break here and there..

      Thanks everyone, especially Patters!

      Reply
    2. phomac

      Thanks a lot Harv!!!
      Followed your steps and it now works perfectly, after I manually updated my Crashplan Client on my Mac to 3.7.
      Great to have a community like this!

      Reply
    3. dot45

      Thanks, CrashPlan is working after this. Too bad I had already uninstalled/reinstalled, now I have to wait for the block check to finish.

      Reply
  41. P.

    Will there be a easy way to fix the issue with CrashPlan with the new version.. Mine is also stopped working.. Can’t start it etc… Thanks in advance for the work … Please update us on the situation.

    Thanks

    Reply
  42. chrisn

    I followed Harv’s steps above and my local crashplan is finally connecting to the headless crashplan on Synology. Thank you!

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

    (note .1420917302662 path will be different each time)
    mv /var/packages/CrashPlan/target/upgrade/1388728800370.1420917302662/upgrade.sh /var/packages/CrashPlan/target/upgrade/1388728800370.1420917302
    662/upgrade.sh.old

    Reply
  43. Mads Laumann (@Laumania)

    I also have this problem, but found a solution – at least to the “Failed to install “Crashplan”.” problem.
    You just need to change the publisher trust level to “any publisher” under the package manager settings. Then the Crashplan package installs again.

    Hope this helps someone :)

    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