CrashPlan packages for Synology NAS

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

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

There are now only two product versions:

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

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

CrashPlanPRO-Windows

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

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

 

Synology Package Installation

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

CrashPlan Client Installation

  • Once the CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
  • Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.
  • The Linux CrashPlan PRO client must be downloaded from the Admin Console and placed in the ‘public’ folder on your NAS in order to successfully install the Synology package.
  • By default the client is configured to connect to the CrashPlan engine running on the local computer. Run this command on your NAS from an SSH session:
    echo `cat /var/lib/crashplan/.ui_info`
    Note those are backticks not quotes. This will give you a port number (4243), followed by an authentication token, followed by the IP binding (0.0.0.0 means the server is listening for connections on all interfaces) e.g.:
    4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0
    port,--------------token-----------------,binding

    Copy this token value and use this value to replace the token in the equivalent config file on the computer that you would like to run the CrashPlan client on – located here:
    C:\ProgramData\CrashPlan\.ui_info (Windows)
    “/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for all users)
    “~/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for single user)
    /var/lib/crashplan/.ui_info (Linux)
    You will not be able to connect the client unless the client token matches on the NAS token. On the client you also need to amend the IP address value after the token to match the Synology NAS IP address.
    so using the example above, your computer’s CrashPlan client config file would be edited to:
    4243,9ac9b642-ba26-4578-b705-124c6efc920b,192.168.1.100
    assuming that the Synology NAS has the IP 192.168.1.100
    If it still won’t connect, check that the ServicePort value is set to 4243 in the following files:
    C:\ProgramData\CrashPlan\conf\ui_(username).properties (Windows)
    “/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for all users)
    “~/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for single user)
    /usr/local/crashplan/conf (Linux)
    /var/lib/crashplan/.ui_info (Synology) – this value does change spontaneously if there’s a port conflict e.g. you started two versions of the package concurrently (CrashPlan and CrashPlan PRO)
  • As a result of the nightmarish complexity of recent product changes Code42 has now published a support article with more detail on running headless systems including config file locations on all supported operating systems, and for ‘all users’ versus single user installs etc.
  • You should disable the CrashPlan service on your computer if you intend only to use the client. In Windows, open the Services section in Computer Management and stop the CrashPlan Backup Service. In the service Properties set the Startup Type to Manual. You can also disable the CrashPlan System Tray notification application by removing it from Task Manager > More Details > Start-up Tab (Windows 8/Windows 10) or the All Users Startup Start Menu folder (Windows 7).
    To accomplish the same on Mac OS X, run the following commands one by one:

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

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

 

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

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

Notes

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

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

Package scripts

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

installer.sh

#!/bin/sh

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


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


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

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

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

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


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


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

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

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

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

  exit 0
}


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

  exit 0
}


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

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

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

 exit 0
}


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

  exit 0
}


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

start-stop-status.sh

#!/bin/sh

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

  restart)
    stop_daemon
    start_daemon
    exit $?
  ;;

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

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

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

esac
 

install_uifile & upgrade_uifile

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

Changelog:

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

6,692 thoughts on “CrashPlan packages for Synology NAS

  1. BigBen's avatarBigBen

    [English Message]
    Hello,

    on a Synology DS 213+ no longer does the current version of CrashPlan. The old version 3.7 has the Workarround the website http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/ still flawless works.

    On the Synology system no Java Manager available. On the Java SE Embedded System 7 has been installed.

    Can anyone make the old version 3.7 from Synology Package CrashPlan available?

    [German Message]
    Hallo,

    auf einem Synology DS 213+ funktioniert die aktuelle Version von CrashPlan leider nicht mehr. Die alte Version 3.7 hat mit dem Workarround der Webseite http://chrisnelson.ca/2015/05/12/fixing-crashplan-4-2-0-on-synology-after-dsm-5-2-update/ noch fehlerfrei funktioniert.

    Auf dem Synology System ist leider kein Java Manager vorhanden. Auf dem System ist Java SE Embedded 7 installiert worden.

    Kann mir jemand die alte Version 3.7 vom Synology-Paket CrashPlan zur Verfügung stellen?

    Reply
    1. BigBen's avatarBigBen

      [English message]
      When starting CrashPlan is stopped again immediately.

      [german message]
      Beim Starten wird CrashPlan unmittelbar wieder gestoppt.

      Reply
  2. Chris's avatarChris

    Has anyone had success with using this package with the Ceejay UK/EU Cloud? Is it a case of installing this package in the same way and then configuring it using the ceejay build downloaded from their website? see http://www.ceejay.net/ for more. Thanks

    Reply
    1. patters's avatarpatters Post author

      I don’t think there’s anything special about the CeeJay build. The installers they distribute just have some different logo branding and they have the server URL baked in – but you should be able to get those details from CeeJay and input them yourself. Use a regular build of the client. You would need to find out which client version they’re supporting (they might be lagging behind the current release version). When you install the Synology PROe package you get to select the version from the dropdown.
      When I first discovered CrashPlan I tried to use the CeeJay service for something at work and found it very unreliable. The entire backup archive would frequently be offline for a whole week while the server was performing maintenance on it. CeeJay couldn’t really help because it was a CrashPlan issue and all they could do it suggest that we re-seed (a several terabyte backup set!). After that happened twice I cancelled the service. That was with CP PROe 3.6.1.4 though so clearly the product has evolved considerably since then.
      Client builds for version 4.x are here:
      http://support.code42.com/Administrator/4/Planning_And_Installing/Code42_Platform_Installers
      Client builds for version 3.x are here:
      http://support.code42.com/Administrator/3/Planning_And_Installing/Code42_Platform_Installers

      Reply
  3. Chris Brandhorst's avatarChris Brandhorst

    Hi, I’m trying to install CrashPlan on my brand new Synology. It fails with the following error in synopkg.log:

    Begin: /bin/tar xf /volume1/@tmp/@synopkg/@download/CrashPlan/@SYNOPKG_DOWNLOAD_CrashPlan -C /volume1/@tmp/558AC2F17A2B25FF/ conf –no-same-owner
    /bin/tar: conf: Not found in archive
    /bin/tar: Exiting with failure status due to previous errors

    Upon inspecting the downloaded package in the @download folder, indeed the file “conf” is not present. Anything I’m doing wrong here?

    Reply
    1. Chris Brandhorst's avatarChris Brandhorst

      Just found that setting the Trust Level to “Any publisher” migitates this issue.

      So it’s now running on the new DS715!

      Reply
  4. salid's avatarsalid

    Since the latest Synology Update the package does not backup during the night automatically. My cronjob starts the package, but there is no backup happening.
    I need to start the GUI and press the Settings -> Backup -> Verify Selection “Now” Button, to start the backup.
    Does anyone else have the same problem?

    Reply
  5. Wade's avatarWade

    Ever since the last update, I’ve been getting emails from Crashplan that my client has not connected in X days, even though it appears to be connecting fine whenever I manually run it. When I looked at the logs this morning the times are wrong, and appear to be listed in the wrong order, so I’m not sure what’s going on. I have it set on a task schedule to start the service at 12:00AM and stop at 4:00AM, but the log says it’s starting at 7:00AM and stopping at 4:00AM. It also shows the 4:00AM entry AFTER the 7:00AM entry, which doesn’t make any sense. I decide to test the schedule by manually running the task this morning at 8:00AM and the log entry said it was 3:00PM. I logged into the Crashplan site and it says it was recently connected and 100% backed up, so everything appears to be connecting fine. I verified the date/time is correct in the DSM settings, so I’m not sure where to go next.

    Reply
    1. patters's avatarpatters Post author

      Yes I was also receiving those emails even though everything was fine on the NAS. Strange. There is a Java package issue relating the timezones though. They changed a file in DSM 5.2 which my script uses to do the timezone modern name to legacy name conversion. I still need to fix that.

      Reply
      1. Wade's avatarWade

        I installed the new Java package you posted and it’s closer, but it’s still off by an hour.

      2. patters's avatarpatters Post author

        Some of the entries in the CrashPlan log are made by my scripts and these are using the correct time from DSM. It seems that the CrashPlan entries are somehow not inheriting the correct time, and using UTC instead. What happens for people who are more than one hour away from UTC?

      3. Marc Wilson's avatarMarc Wilson

        @patters

        You asked about people who were more than a hour away from GMT, I’m in GMT-8 (in California, which is currently in DST), and the times being posted are minus one hour from what they should be, like it wasn’t taking the DST into account.

      4. patters's avatarpatters Post author

        I guess I’ll test when I get home and see what happens to Serviio’s log entries (also a Java app). I have a feeling it’s a CrashPlan issue.

      5. patters's avatarpatters Post author

        I updated the JRE’s timezone data (which holds the DST dates) using http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html#system
        but this didn’t make any difference. Could the developers of both CrashPlan and Serviio have perhaps used time functions that don’t take DST into account?
        DS214Play> java -jar tzupdater.jar -V
        tzupdater version 2.0.0-b03
        JRE tzdata version: tzdata2014j
        tzupdater tool would update with tzdata version: tzdata2015a
        DS214Play> java -jar tzupdater.jar -u
        DS214Play> java -jar tzupdater.jar -V
        tzupdater version 2.0.0-b03
        JRE tzdata version: tzdata2015a
        tzupdater tool would update with tzdata version: tzdata2015a
        DS214Play>

        The logs are still out by one hour even with this change.

  6. Bagu's avatarBagu

    I had a problem with crashplan on my ds414.
    Crashplan start and stop in a loop without sending anything.
    Here is the solution :
    -changed the file /volume1/@appstore/CrashPlan/syno_package.vars
    -remove the # in front of the command: #USR_MAX_HEAP=XXXX
    -change it by USR_MAX_HEAP=768M
    -restart Crashplan

    Now, it work like a charm

    Reply
    1. ethuesen's avatarethuesen

      This worked for me as well.
      Though, first time I tried it did not work. I had to adjust the fille permission settings first.

      Reply
  7. graabein's avatargraabein

    Hi! Any chance the “ANNAPURNALABS Alpine AL212” CPU in the new DS215+ will be supported?

    Thanks,
    Gunnar

    Reply
      1. Anil's avatarAnil

        Hi Patters,

        1. Any chance yo could point me to where I could download Crashplan package for DS209 DSM 4.X? I Uninstaller and now it does not show up on community..

        2. Also, the latest 4.3.x version would work on DS415+?

        THANKS!
        Anil

      2. Anil's avatarAnil

        Sorry Patters, I don’t understand how to run that command and how that would reinstall crashplan.

      3. patters's avatarpatters Post author

        I’m trying to work out how difficult it would be to get the current package to work on DSM 4.3. The 0027 package has a dependency on a binary bundle which is no longer on my hosting environment.

      4. Anil's avatarAnil

        So, do I login as root using puty and type renice? And, then what?. Do I need to give you remote access to you? If yes, what type of access do you need and should I create a user for you? Please let me know.

  8. clarkey's avatarclarkey

    Anyone else having trouble with the time zones?
    My backup schedules are using US time and not the local time the NAS is set to (Australia)

    Reply
      1. Anil's avatarAnil

        Hi Patters, I have DS209 which is still limited to 4.x DSM. So, I don’t have DSM 5.x. I see that 0028 is for DSM 5.x. I have CrashPlan 3.6.3.0027 on my DS209 and the log file under packages shows that the CrashPlan was updated to 4.3.0 on June 30th. Now, CrashPlan client hangs on my PC. Does this mean I am stuck with CrashPlan not working or is there a way to go back to 4.2.0 when everything was working fine?

        Thanks in advance for your help!
        Anil

  9. Edouard's avatarEdouard

    Hi,
    Sorry I’m a little newbie but I couldn’t install CrashPlan on my DS415+ (DSM 5.2-5565 Update 2), I installed the the latest Java SE 7 (jdk-7u80-linux-i586) but when I want to install Crashplan (4.2.0-0031) I have only a message error “Failed to install ‘CrashPlan” any idea what’s wrong?

    Reply
  10. frankyon's avatarfrankyon

    Is there a fix available for crashplan 4.3..? the service is running von the nas but i can’t connect by client.. it’s loading and nothing happened..

    Reply
  11. catnip's avatarcatnip

    auto upgrade to version 4.3.0 has broke my installed, tried one the fixes online from chris nelson dot ca that got it running on the NAS again, but I am unable to connect to it via the app to configure it

    Reply
  12. Kevin's avatarKevin

    It seems there is a new update being pushed 4.3.0. Th update on the NAS failed so I updated manually. However, for some reason, crash plan on the PC won’t connect to the NAS. Curious if anyone is having any issues.

    Reply
    1. Troy's avatarTroy

      Kevin,

      I’m seeing the exact same issue. I used the manual instructions that were posted previously to update the server side which seems to be running fine, but as Kevin says the client will no longer connect to the server. It doesn’t error out saying “can’t connect to backup engine retry” it literally just hangs there. I even went to CrashPlan website and thought maybe they upgraded the client so I reinstalled to make sure it matched the server but it still does not want to connect to the server now.

      Reply
      1. Kevin's avatarKevin

        Troy they did update the client to version 4.3.0 also. Just like you I updated the client and it just hangs. Crashplan on the NAS doesn’t show any errors. Very strange.

      2. ScottieP's avatarScottieP

        I’m getting the same issue, I’ve tried re-installed about 6 times now- once the desktop client kicks out and then requires you to log back in it say “Upgrading Crashplan” which then kills the service on my Syno- This can be fixed, but then I’m in the same boat- I try to open the desktop app and it just hangs at the splash screen- I noticed you can update the paths to backup on the website when you click into it- but I don’t know if I trust it… I might be giving up my subscription this year…. Especially since they removed network share support a few versions back. Everything is a hack now. Carbonite at least will allow for file shares… better than nothing.

  13. YuryG's avatarYuryG

    01/07/15 Crashplan rekeased an update to 4.2 designated as 4.2.1
    It downloads and installs automaticalty. I found no way of stopping it form downloaing and installing.
    Anyway, after instalation the service is listed as STOPPED and i have nor found a way to make it start again.

    Reply
  14. Eric's avatarEric

    I believe I’ve figured out the Client hangs that some people have seen with the update to 0031 and the 4.3.0 client. I had this problem as well, and had a perfectly working installation until the update. Here’s what I found.

    In the /var/packages/CrashPlan/target/log/service.log.0 on the DSM I found the following happen while my client was trying to connect.


    UserActionRequest: StatusQueryMessage[696203082971748058] CPD|874a53dc-20a5-56a1-cb4f-12adf2252455|eric|/Users/eric|
    Loaded port=4243 and token from location=/var/lib/crashplan/.ui_info
    Received status request message with invalid token.

    At that point it would disconnect and the remote client would hang. Bad stuff, but very telling.

    I took a look at the .ui_info file referenced above and what do you know, it has a GUID formatted exactly like the first like above from the log, after CPD|, but it’s different. The .ui_info file is formatted by port, a comma, then the GUID (4243,).

    The one in the log is what my client sends, the one in the .ui_info file is what the DSM is expecting. Doesn’t get it so things fail. Let’s try and experiment.

    To fix it I made a backup of the /var/lib/crashplan/.ui_info file, then I used vi to replace the GUID the DSM had to match the one my client sent, take from the log entry. Make sure you only paste in over the old GUID, and not the port as well. In the end it should be 4243,. Save and restart CrashPlan on the DSM.

    Bingo, client now connects. Something went whacky here. Likely the 4.3.0 client installation (I’m on a Mac) generated a new GUID during the client install.

    Note: I modified the GUID in the above log snippit, so it’s not really mine, but the same format. Don’t use what’s above, find your own and replace it.

    Reply
    1. Stanthewizzard's avatarStanthewizzard

      Eric … you are a Genius
      This is working. I logged to crashplan. Entered my login pass and everything is fine …again

      Thanks thanks thanks

      Reply
    2. slidermike's avatarslidermike

      Eric,
      very nice and good work to sleuth that down. However in my case it does not quite match up. I do not do the client to NAS backup but rather the paid subscription for 1 pc (NAS) to crashplan central. When I see the output it shows differently than yours. I don’t get the CPD followed by the hash and then port 4243.
      I guess I have to wait for Patters or another persistent party to make the NAS to crashplan central (headend to NAS) portion work again.
      I am beginning to wish I had not pre-purchased the 3 year subscription. I would at this point probably migrate over to the Amazon/Glacier solution since its built in and really the charges are on the restore anyway.

      Reply
      1. Eric's avatarEric

        Hi slidermike,

        Interesting, because I do the same thing you do. I have a PC subscription that lives on my NAS. I only connect via the client on my Mac to manage the NAS installation. I do not push backups from my client, only the NAS. In fact I’d be willing to bet that’s what most do.

        Don’t give up yet, it’ll work. If your CP headless is up and running on the Syno then that’s half the battle. See what’s in the service log I mentioned in the post above. If you’re getting invalid token errors then the symptoms match. See patters updated release notes from there. If it’s not an invalid token error then you’re looking at something different.

    3. Kevin's avatarKevin

      Thanks a lot Eric !! That worked for me also. I would have never figured that out. Thanks again.

      Reply
    4. marselaar's avatarmarselaar

      Thanks Eric, this works! I am getting a bit annoyed by all the hassle everytime something changes, but I am really happy that I can always find a solution here.

      Reply
    5. Troy's avatarTroy

      UserActionRequest: StatusQueryMessage[696203082971748058] CPD|874a53dc-20a5-56a1-cb4f-12adf2252455|eric|/Users/eric|
      Loaded port=4243 and token from location=/var/lib/crashplan/.ui_info
      Received status request message with invalid token.

      At that point it would disconnect and the remote client would hang. Bad stuff, but very telling.
      I took a look at the .ui_info file referenced above and what do you know, it has a GUID formatted exactly like the first like above from the log, after CPD|, but it’s different. The .ui_info file is formatted by port, a comma, then the GUID (4243,).

      Eric — Brilliant. That fix worked! I wonder why the GUID’s got out of sync like that. That’s never happened before. I hope that is something Patters can fix/check in the next update of the package because I’m sure the average person on this list will have a hell of a time combing through their logs to find their proper GUID and doing the steps you outlined.

      Reply
      1. patters's avatarpatters Post author

        It’s better to use the GUID from your NAS and apply that to the client’s .ui_info file and not the other way around. Then you can manage your NAS from multiple PCs. I verified that this works.

      2. Eric's avatarEric

        Patters is right here, it’s better to apply the NAS GUID to the client, if your client is on Windows. My client is on a Mac and I couldn’t for the life of me find the same file on my install, so I went the only way I had available. Follow Patters here, I just gave the nudge, he’s the expert.

    6. cbamber72's avatarcbamber72

      Perfect, well found. I double checked this and the file (/var/liv/crashplan/.ui_info)on the DM should match the one on your desktop if you sign in with the same account (i have upto 10 pc account) you can find it here:

      C:\ProgramData\CrashPlan\.ui_info

      Reply
      1. Brian Mackenzie's avatarBrian Mackenzie

        Fantastic work Eric – a very quick resolution given the obscure nature of the problem! I suspect Code42 have spotted the bug in the original v4.3 update as it seems another update was pushed today – 1427864410430.* as opposed to the original 1427864400430.* (9th digit differs). Seems exceptionally quick that – I can only imaging they’d goosed the orignal.

        Thanks again Eric – it’s good to be back in business.

    7. Marcel's avatarMarcel

      Did you have to change the logging detail in service.log.properties ? I didn’t see that message until I set all parameters to DEBUG. Now it’s working again. Thanks!

      Reply
      1. Eric's avatarEric

        That’s interesting. No, I didn’t change the log level on mine to see the message. I’ve been on INFO for my log level the entire time. That’s a good tip though for any that might not be seeing the message, but are having the same symptoms.

        For those that might stumble on this Marcel is talking about the /var/packages/CrashPlan/target/conf/service.log.properties file. In it is the log levels for various events. INFO|WARN|DEBUG etc. I have no idea which one (root?) would be the one to turn up if needed.

        Just remember, if you turn them up to debug, turn them back down when done. Don’t need a NAS full of DEBUG logs. :)

  15. Adam's avatarAdam

    There is an error in one of the log files on the server moaning about an invalid token id, any ideas patters?

    Reply
    1. slidermike's avatarslidermike

      My DS1512+ wont start the service now after it auto updated yesterday. The logs shows “Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1427864400430

      Any idea how to fix this?

      Reply
      1. Kevin's avatarKevin

        You have to update manually using the directions posted in this thread. However, don’t bother at this point, because the client can’t connect to the NAS after being updated for some reason.

      2. slidermike's avatarslidermike

        Kevin, thank you for the response. Since I don’t need the client connection at this point I do want to get the service running so the backups continue on the NAS to Crashplan central. Which manual directions are you referring to? Are they the ones by Bagu about changing the heap size or some other ones I am missing?

      3. slidermike's avatarslidermike

        Kevin, thank you very much for your help. Those directions were spot on. I don’t need to attach the client at the moment as the directories I backup to Crashplan central are pretty static.

      4. Kevin's avatarKevin

        Mike do you mind telling me how you’re doing it without the client ? I would be very interested in trying it myself. Thanks.

      5. slidermike's avatarslidermike

        Kevin,
        It is my understanding that all the “work” is done on the Syno as a headless service. I use the pc/client to configure the folders & schedule the backups to run from x:xx – x:xx.
        Once you configure the Syno service to run like that, it is my understanding the client or head/gui isn’t needed for the operations to function on the NAS. So if I understand it correctly my syno should go back to the regular schedule I put it on.
        I don’t use the syno as the backup destination rather, I backup 3 NAS folders to crashplan under the 1 pc paid rate for unlimited storage on their servers.
        Unless I do not actually understand how it works in which case the service is running on the syno but in reality it wont be backing any data up to crashplan central.

      6. ties's avatarties

        Mike,

        That is how I understand it as working as well. I’ll know tonight after everything scheduled runs or doesn’t… :)

    2. Eric's avatarEric

      I figured out the client hang issues, posted them last night, but they are in moderation still. Essentially the 4.3.0 client seems to be changing the GUID client side, and during the initial handshake between the client and the DSM the GUID is passed and compared. My previous comment has the process to update the GUID.

      Reply
      1. patters's avatarpatters Post author

        I have created a new package which installs/upgrades to 4.3 but I get this same issue. The remote client just times out. However, I don’t see the log entry you reported in /var/packages/CrashPlan/target/log/service.log.0. There’s no evidence that the client is connecting at all. On the NAS if I use netstat it looks like CrashPlan has bound preferentially to an IPv6-to-4 tunnel adapter address or something, not IPv4:
        DS214Play> netstat -na | grep LISTEN | grep 42
        tcp 0 0 ::%134877541:4242 ::%134877541:* LISTEN
        tcp 0 0 ::%134877541:4243 ::%134877541:* LISTEN
        DS214Play>

        It’s not even similar to my NAS’s IPv6 address. I tried disabling IPv6 in DSM’s Network settings and rebooting but this didn’t make any difference. Anyone know what this odd binding could be?

      2. slidermike's avatarslidermike

        Patters, I get the same results as you with netstat. It is ONLY listening on ipv6.
        Nas1> netstat -na | grep LISTEN | grep 42
        tcp 0 0 ::%134877389:4242 ::%134877389:* LISTEN
        tcp 0 0 ::%134877389:4243 ::%134877389:* LISTEN
        Nas1>

      3. patters's avatarpatters Post author

        Got it. I need to add “-Djava.net.preferIPv4Stack=true” to the launch parameters in run.conf.
        Client is still not attempting to connect though.

        EDIT – Ok, figured it out. I had an SSH session open with port 4243 tunnelled to my NAS. CrashPlan 4.3 will avoid using 4243 for the console if the port is already in use, and changing the port number in .ui_info doesn’t seem to influence the client. Once I reinstalled the client with port 4243 available I was able to connect.

      4. Marcel's avatarMarcel

        IPv6 here as well. I upgraded the client manually to 4.3.0, but no connection is made.

        I created an SSH tunnel. This tunnel forwards connection on a random port on my local machine to ‘localhost’ on my DS413. When I telnet to localhost from my local client to that port, I see entries in the logfile on my NAS :

        [07.02.15 18:38:58.361 INFO Sel-UI-A com.backup42.service.ui.UIController ] UISession Created – 696446962803714373
        [07.02.15 18:39:12.770 INFO Factory$Notifier-UI0 com.backup42.service.ui.UIController ] UISession Ended after less than a minute – 696446962803714373
        [07.02.15 18:39:12.771 INFO Factory$Notifier-UI0 backup42.service.backup.BackupController] UI:: AUTO IDLE… lowBandwidth=25600 B/s, activeThrottleRate=20
        [07.02.15 18:39:12.771 INFO Factory$Notifier-UI0 com.backup42.common.command.CliExecutor ] RUN COMMAND: auto.idle > CommandResult@19014278[ auto.idle, success=true, result=null ]

        When I configure the Crashplan client to connect to localhost on the tunnel port, nothing appears in the log. It looks like the client is not even trying to connect. Strange.

  16. cbamber72's avatarcbamber72

    the package auto-updates from 4.2 to 4.3 very quickly now, and then gets stuck, as others have said the fix that has been posted before (terminal commands to upzip folders) gets the service running on the NAS box, but the client app just hangs and never gets to the timeout.

    the client UI log ends as follows,but the client app still looks like it it loading:

    07.01.15 09:42:21.096 INFO main com.backup42.desktop.SplashWindow ] SHOW SplashWindow
    [07.01.15 09:42:21.157 INFO main com.code42.messaging.nio.MessageProvider] MessageProvider(): options=MessageProviderOptions[name = UI, numWorkers = 2, socketSendBufferSize = -1, socketReceiveBufferSize = -1, securityEnabled = false, securityProviderPK = true, numSecurityProviderWorkers = 1, symmetricAlgorithm = AES, siteLocalTrafficClass = 0, trafficClass = 0, tcpNoDelay = false, watchNetworkInterfaces = false, discardMessages = false, inboundMessageBufferSize = 0, outboundMessageBufferSize = 0, siteLocalInboundMessageBufferSize = 0, siteLocalOutboundMessageBufferSize = 0, outboundMessageBufferPriorityOverflow = 0, maxMessageSize = 20971520, useProxy = false, localPACFile = null]
    [07.01.15 09:42:21.411 INFO main com.backup42.desktop.CPDesktop ] Loaded permissions in 214ms
    [07.01.15 09:42:21.411 INFO main com.backup42.desktop.CPDesktop ] Adding shutdown hook.
    [07.01.15 09:42:21.412 INFO connect com.backup42.desktop.CPDesktop ] Connecting to service at 192.168.1.XXX:4243
    [07.01.15 09:42:22.489 INFO MQ-UI-0 com.backup42.desktop.CPDesktop ] Connected to service
    [07.01.15 09:42:22.489 INFO MQ-UI-0 com.backup42.service.ui.UIInfoUtility ] Loaded port=4243 and token from location=C:/ProgramData/CrashPlan/.ui_info
    [07.01.15 09:42:22.489 INFO MQ-UI-0 backup42.service.ui.client.ServiceClient] Getting initial application state for CPD, username=XX, userHome=C:\Users\XX, desktopFolder=C:\Users\XX\Desktop
    [07.01.15 09:42:22.490 INFO connect com.backup42.desktop.CPDesktop ] SUCCESS on attempt #1
    [07.01.15 09:42:22.528 INFO Factory$Notifier-UI0 com.backup42.desktop.Services ] DISCONNECTED!

    Reply
  17. Bibliophile's avatarBibliophile

    I would like to be able to block CrashPlan from updating its software – every time this automatically happens, it breaks functionality. I would like to be able to wait until the bugs are sorted out, before upgrading. Anybody know how to disable this automatic function and stay with the previous version?

    Reply
  18. Brian Mackenzie's avatarBrian Mackenzie

    Hi guys
    Same issue here since v4.3 was pushed out to me – initially the CrashPlan service on my Synology died with the usual ‘Repairing…’ message – I fixed that as per the instructions and the service came back up – and indeed my backups resumed (I backup to both CrashPlan Central and another Synology NAS running CrashPlan – could see the disk lights on both source and target flashing away and JAVA consuming CPU ticks on the source NAS).
    Anyway, I tried connecting to the service using the CrashPlan client (running on Windows 7 64-bit for what it’s worth) but no joy – just hangs there. Unfortunately after spending most of the day dicking around with this I think I’ve managed to screw the backup set that was backing up nicely (even though I couldn’t connect to check up on it). Now I’ve got no backups running and I’m still unable to connect.
    Would appreciate any pointers once someone has a handle on this issue.
    Thanks
    Brian

    Reply
    1. Kevin's avatarKevin

      I am in a similar situation. After the recent updates (2 days in a row), I was able to follow the instructions to get the CrashPlan working on my NAS DS1513+. Log view on the NAS showed the backup were still working properly. I couldn’t get my remote Mac client to connect to manage it though. After spending the better part of today working on it, I am now able to launch the CrashPlan client on my Mac, but I cannot configure my NAS folders to backup. Also, in all the messing around today, I deleted all my previous backups. Any help with getting my client so I can reconfigure my backup sets would be great!!!

      Reply
  19. Ole Overgaard's avatarOle Overgaard

    Help, please.
    After updating my Synology DS415+ to DSM 5.2-5592, crashplan stopped, and I could not start it again.
    I have uninstalled it, uninstalled Java, and reinstalled java, reinstalled Crashplan, stopped it and started it again.
    But the Crashplan keeps stopping when I start it.
    The logfile says:
    “Synology repairing upgrade in /var/packages/CrashPlan/target/upgrade/1427864400430.1435785676268”

    Anyone having a clue on what I can do?

    Reply
  20. Richard's avatarRichard

    I’m seeing the same behaviour. Restarting Crashplan on the Synology starts it up just fine with 4.3.0.

    Updated the client software and changed the ServiceHost, but can’t connect. When I tail engine_output.log I get the following

    [07.01.15 18:27:22.372 INFO main com.code42.net.ConnectivityTester ] Connectivity testing localhost, port=4243, connectionTimeout(ms)=100, retryDuration(ms)=100
    [07.01.15 18:27:22.481 INFO main com.code42.net.ConnectivityTester ] Failed to connect after duration=108, retryDuration=100, address=localhost, connectTimeout=100, e=Connection refused
    [07.01.15 18:27:22.504 ERROR main com.backup42.service.ui.UIInfoUtility ] Unable to find a file to read the token and port out of due to IO, check that the file is readable?, java.io.IOException: Unable to create parent folders for .ui_info file. folder=/var/lib/crashplan
    java.io.IOException: Unable to create parent folders for .ui_info file. folder=/var/lib/crashplan
    at com.backup42.service.ui.UIInfoUtility.setUIConnectionDetails(UIInfoUtility.java:86)
    at com.backup42.service.CPService.initServicePorts(CPService.java:1078)
    at com.backup42.service.CPService.start(CPService.java:341)
    at com.backup42.service.CPService.main(CPService.java:1922)

    Anyone have any ideas?

    Reply
  21. Richard's avatarRichard

    Logged into Crashplan, it confirms that the engine on the Synology is running and connecting correctly.

    Reply
  22. lupina001's avatarlupina001

    Ever since I updated to CrashPlan 4.2 (from 3.7) I cannot back up my files anymore. I have just updated to 4.3 and the same problem still happens.

    The worklog says:
    CrashPlan started, version 4.3.0, GUID 6503624866600795236
    Backup scheduled to always run
    [Default] Scanning for files to back up
    [Default] Starting backup to CrashPlan Central: 6 files (….kb) to back up
    Stopping CrashPlan
    [Default] Scanning for files stopped

    And the same exact events will keep repeating over and over in the log.
    Any ideas on what is causing the problem?

    Reply
    1. lupina001's avatarlupina001

      I forgot to mention, the files are not being updated to CrashPlan Central. there are also probably over 1000 files updated since the the CrashPlan 4.2 upgrade but its not detecting it.

      Reply
      1. lupina001's avatarlupina001

        I didn’t change the backup files. I actually removed many directories to be backed up after getting this issue but it still occurs.

        How do I troubleshoot if its a RAM allocation issue? I’m not very tech savy with linux….or accessing my NAS but I can follow directions.

      2. slidermike's avatarslidermike

        patters,
        any idea when you might be able to put the new package together that works again?
        I think the last crashplan update they pushed out broke mine again on the 2nd or so.
        I tried the manual fix again but I must be doing something wrong as I still cannot get the service to run anymore on my ds1215+.

        Thank you for all your efforts & hope everyone had a good holiday weekend.

    2. ethuesen's avatarethuesen

      I’m having this problem as well.
      I also tried modifying the max RAM usage in syno_package.vars, however, it looks like it had no effect on the RAM usage.
      However, I found out there is no CrashPlan user created on my DS. Is there supposed to be an user called “crashplan” when CP is running, or is the user deleted after the package is installed?

      Reply
      1. patters's avatarpatters Post author

        No, the older versions used a dedicated user account but more recently the package runs as root to simplify things and since a backup application needs access to everything.

      2. ethuesen's avatarethuesen

        In that case I don’t know what the problem is.
        Here’s whats happening:
        1. CP is scanning for files after starting the package.
        2. The Java process exceeds about 900 MB of RAM and after that CP restarts (back to step 1, and this way CP keeps restarting every 3rd minute).
        As stated above, I have tried setting the maximum RAM usage in syno_package.vars to 500 MB, however, it did not have any effect – the RAM usage kept going up to 900 MB and CP kept restarting.

        I’m on a DS 412+ upgraded to 2GB of RAM.

  23. slidermike's avatarslidermike

    patters,
    you mentioned having to adjust the config file to enable/default to ipv4.
    Now you said after re-installing the client you got it to work.
    So what do we have to do to get our headless client to connect to the NAS crashplan?
    I am running ds1512+ & CP 4.2.0-0031 but in the log it says ver 4.3.0

    Reply
    1. patters's avatarpatters Post author

      I’m rewriting the main blog post since it’s very outdated now. I hope to have that completed and a new package version published later tonight.

      Reply
  24. Jon's avatarJon

    I’m getting an issue with an upgrade:
    /var/packages/CrashPlan/scripts/start-stop-status: upgrade.sh: line 10: ../../bin/CrashPlanEngine: not found

    Anyone else seeing this?

    Reply
  25. cbamber72's avatarcbamber72

    they just pushed another update 1427864410430, crashplan stopped once more. Manual fix worked again, if you have fixed the ui issue then it stays fixed, or they fixed it for us.

    Reply
    1. slidermike's avatarslidermike

      Yeah the new update broke mine again. Patters said he was releasing a fixed version this evening so I am going to get that from him tonight.

      Reply
      1. davidjpatrick's avatardavidjpatrick

        Hi – I’m having the UI issue where it does not connect even though CrashPlan on the NAS says it’s running. Is there a fix for this?

      2. patters's avatarpatters Post author

        Postponed due to Code42 breaking 4.3.0 with an update for which there is no full installer available (yet).

  26. Richard's avatarRichard

    Tried to run echo `cat /var/lib/crashplan/.ui_info` but I don’t have a crashplan direction under that path.

    Reply
  27. Eric's avatarEric

    Hi Patters,

    Completely agree with you on the GUID from the DSM move to the Client instead of the other way around, but I wanted to let you know why I didn’t write it up that way. I’m on a Mac and couldn’t for the life of me find the GUID file. It’s not a .ui_info file. :D I have looked everywhere. It must be somewhere, but I can’t find it. If someone finds it please post and let me know. Thankfully the other way worked as well.

    Reply
    1. mikemag's avatarmikemag

      Here you go:

      [07.02.15 21:13:40.294 INFO MQ-UI-1 com.backup42.service.ui.UIInfoUtility ] Loaded port=4243 and token from location=/Library/Application Support/CrashPlan/.ui_info

      Reply
      1. Eric's avatarEric

        Um… that’s embarrassing. How in the name of hell did I miss that file. I know I looked there because it’s an obvious location. Regardless, thank you and I find it a little sad I missed that. :)

  28. Adam's avatarAdam

    Eric, i’ve found the location of the .ui_info file on a mac. Its in /Library/Application Support/CrashPlan

    Patters, do you want to update your guide on this.

    Adam.

    Reply
  29. BenT's avatarBenT

    Unfortunately I cannot find a file .ui_info. There is only /var/lib/crashplan/.identity but I do not have permission to open or modify this file. Same on windows, I only have C:\ProgramData\CrashPlan\.identity. This file actually can be opened and modified and contains all the desired information, such as the GUID.

    I reinstalled Crashplan on my Synology but nothing changed. The service is stopped and cannot be started which leads to not being able to start the client on Windows either.

    Any suggestions?

    Reply
    1. patters's avatarpatters Post author

      It’s only there after upgrading to CrashPlan 4.3 which some people are doing manually. I will release a package as soon as Code42 stop pushing this lastest minor update to 4.3 (started yesterday) and offer a full installer.

      Reply
      1. Richard's avatarRichard

        The system upgraded itself with both of the 4.3 releases, still missing anything under /var/lib. All of mine seem to exist under /volume1/@appstore/Crashplan

  30. Stanthewizzard's avatarStanthewizzard

    Hello
    I have 2 client that connect to the syno
    One is ok because I change .ui_info
    but and it is ok the other one doesn’t work

    How do I change the GUID of the client to match the other client ?

    Thanks

    Reply
  31. Ole Overgaard's avatarOle Overgaard

    I did the manual upgrade and took the GUID from the NAS and installed on my PC. And lo and behold – the CP package on the synology starts, and the PC connects to the CP service on the Synology.

    However, since I uninstalled and reinstalled Crashplan on the Synology, I need to provide my credentials in the PC-client. And when I do that, I get the error “unable to connect, check your network”. I have googled that error and the suggestions are to use OpenDNS and/or restart the CP service on the Synology. I have done both and it does not work. Instead, when I stop and starts the CP on the Synology the “Synology reparing upgrade” error returns and I have to make a manual upgrade again. How do I get past the “unable to connect, check your network” error?

    Any suggestions?

    Reply
  32. TechNut's avatarTechNut

    Thanks to all who have worked out the issues with the 4.3.0 upgrade.

    I used the SSH manual update method and have CrashPlan running again on my Synology.
    I was also able to get my unique GUID from Synology …
    However, I am running the CrashPlan 4.2.0 Client on win XP ( i know, i know)
    and I CAN NOT find the “.ui_info” file anywhere on the PC.

    (I know the XP equivalent of the “ProgramData/crashplan” is the “Application Data/crashplan” folder, but the file is not there) I did a search for any file “ui_info” and nothing.

    Anyone have any suggestions???

    Reply
      1. TechNut's avatarTechNut

        Ok, I see.
        I am on “CrashPlanPro” and on the Code42 site the latest client for the PRO is still 4.2.0
        (Home version is 4.3.)
        Any idea if there is somewhere I can download the 4.3. win exe for CrashPlanPRO?
        Or am SOL, and just have to wait for the update to roll out in the coming .. days/weeks?

        Thanks.

    1. TechNut's avatarTechNut

      I was able to find the Windos CrashPlanPRO 4.3 client. But after installing it, still no go.
      Looking at the ui_output.log I see this error:
      com.backup42.service.ui.UIInfoUtility
      Unable to find a file to read the token and port out of, Maybe not yet initialized?, java.io.FileNotFoundException: C:\Documents and Settings\All Users\Application Data\CrashPlan\.ui_info (The system cannot find the file specified)
      java.io.FileNotFoundException: C:\Documents and Settings\All Users\Application Data\CrashPlan\.ui_info (The system cannot find the file specified)

      Reply
      1. Anil's avatarAnil

        My situation is that the backup stopped working after I noticed that Crashplan auto updated on my Synology DS209 which is at DSM4.x and the client on my laptop was 3.7.0. So, first I updated to 4.3.0 on my laptop and still the backup engine 9n synology didn’t work. Long story short, after uninstalling Crashplan on synology, Crashplan package is not even shown listed on synology PC loader community package area.

        Can someone please help as to how to get Crashplan package so I can reinstall it on synology?

        Thanks in advance!

  33. Henrik's avatarHenrik

    I’m using Crashplan home, and upgraded the client i use at my pc to connect to the headless node on my NAS. But, I can’t find the “.ui_info” on my PC. How can I find the missing file?

    Reply
  34. Kevin W.'s avatarKevin W.

    I seem to be stuck here:

    Once the engine is running, you can manage it by installing CrashPlan on another computer, and editing 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

    I cannot seem to find the conf/ui.properties file to modify in a CrashPlan folder on my Mac (Yosemite). The only file I found was /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties.

    If I modify this as stated in the directions, my CP client will not longer load. I get the unable to connect to backup engine message…

    Starting with CrashPlan version 4.3.0 you will also need to run this command on your NAS:
    echo `cat /var/lib/crashplan/.ui_info`
    Note those are backticks not quotes. This will give you a port number followed by a GUID:
    4243,9ac9b642-ba26-4578-b705-124c6efc920b
    Copy this GUID and use this value to replace the GUID in the equivalent file on the computer you want to run the CrashPlan client on:
    /Library/Application Support/CrashPlan/.ui_info (Mac OS X)

    No problems with this step…

    Any ideas?

    Reply
    1. Kevin W.'s avatarKevin W.

      Please disregard. I uninstalled CP from Mac and DS and started from scratch. Everything is working properly once again.

      After the install on DS, I waited for the first auto update to run, patched it and then waited for the next update and patched it…

      Then I installed the Mac client changing the ui.properties to point to my NAS and then updated the GUID in the .ui_info files.

      Thanks for all the support!!!

      Reply
  35. Eduard Epure's avatarEduard Epure

    I had to re-install Crashplan on my Synology NAS and its current version is 4.2.0. How do I get it to manually update ? Starting and stopping the service doesn’t trigger and update.

    Reply
  36. patrick's avatarpatrick

    After 3 days I managed to get my Crashplan client connected again to my nas.
    On the nas I changed the folowing lines:

    0.0.0.0:4242
    and
    localhost
    to
    127.0.0.1:4242
    and
    127.0.0.1

    Restarted the package on the Nas and the client could connect.
    However, when I checked the file while Crashplan was running, it was changed back to the previous values.

    P.

    Reply
    1. patters's avatarpatters Post author

      Something’s wrong with your observation. 0.0.0.0 means that the config is telling CrashPlan engine to respond to connections from any IP. It gets reset like that by design by my package. If you set it back to 127.0.0.1 it would only respond to a CrashPlan client running on your NAS. But Synology DSM isn’t capable of running the client – it’s a headless OS.

      Reply
  37. Marc Wilson's avatarMarc Wilson

    I was going to ask the same thing. Is it that the package has to be reinstalled, or that the client running on the Synology will auto-download it? I get the impression from other posts that it’s an auto-download.

    Reply
  38. mmssantos's avatarmmssantos

    Just installed CrashPlan following your instructions, but if fails to load correctly.
    Analyzing the problem and trying to force run from ssh shell outputs an error regarding ps trying to run with the e option enabled and that doesn’t work with busybox’s version of ps:

    /bin/ps: invalid option — ‘e’
    BusyBox v1.16.1 (2015-05-11 02:57:09 CST) multi-call binary.

    Usage: ps

    Report process status

    Options:
    w Wide output

    Can you point me on the right direction to try and correct the problem?

    Reply
  39. Flavio Endo's avatarFlavio Endo

    I have solved my issue on the NAS using again the Chris’ solution:

    http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/

    Note.. it is updated now for the 4.3.0, althought it is the same solution.

    The only thing is that my PC is still on 4.2.0, and the when I tried to update manually my PC to 4.3.0, Crashplan service stopped working. I had to reverse back to 4.2.0 to have it working again.
    So with NAS on 4.3.0 and my PC on 4.2.0, I cannot access the GUI from NAS. Anyway, it is working the backup.

    Thanks patters for all efforts always.

    Reply
    1. lupina001's avatarlupina001

      The same link you provided worked for me too. The client connects to the server.

      Now I get the same messages in the log again…

      Ever since I updated to CrashPlan 4.2 (from 3.7) I cannot back up my files anymore. I have just updated to 4.3 and the same problem still happens.

      The worklog says:
      CrashPlan started, version 4.3.0, GUID …
      Backup scheduled to always run
      [Default] Scanning for files to back up
      [Default] Starting backup to CrashPlan Central: xx files (….kb/Mb) to back up
      Stopping CrashPlan
      [Default] Scanning for files stopped

      and Crashplan would crash. The same exact events will keep repeating over and over in the log.

      I already ran “java mx 1563, restart”
      in the command-line interface of Crashplan and it still occurs. My files are not being backed up. I have also reduced the number of backup files/sizes significantly from before (and it worked before).

      Reply
      1. lupina001's avatarlupina001

        Hi Flavio, I haven’t raised the RAM limits. I’m not sure how to do it. Can you give a few pointers on how to do this?

      2. Flavio Endo's avatarFlavio Endo

        Hi lupina001, I got this from above the description:

        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 /volume1/@appstore/CrashPlan/syno_package.vars

  40. nataylor999's avatarnataylor999

    I have a Windows computer that I run the CrashPlan service on directly, in addition to running it on my Synology. With 4.2.0 and earlier, I could make a copy of the CrashPlan directory under Program Files (called CrashPlan Remote), and edit the conf\ui.properties under that directory so that I could connect to the CrashPlan service running on the Synology. That way I had CrashPlan running on my local computer, accessible via the tray icon, but could execute the Program Files\CrashPlan Remote\CrashPlanDesktop.exe file to control CrashPlan on the Synology.

    Now, with the GUID stored in .ui_info and the ui_Username.properties stored in the ProgramData directory, it seems I can’t do that anymore. If I edit those files with the GUID and IP of the Synology, then I can’t connect to the local service. If I have those files pointing to the local service, I can’t connect to the Synology.

    Any idea how I can pull this off, so I can monitor my local service and the service on the Synology without having to edit the configuration files each time?

    Reply
  41. Richard's avatarRichard

    I wonder if anybody got the taskbar icon working with the latest version?
    Probably I need to change the GUID in another file wich the taskbar icon uses.

    previously it was hidden in the file in /Applications/CrashPlan.app/Contents/Helpers/CrashPlan\ menu\ bar.app/Contents/info.plist

    But with 4.3 the file does not exist anymore…

    Maybe anybody found a solution??

    Richard

    Reply
    1. Flavio Endo's avatarFlavio Endo

      Is the service working?
      When I updated to 4.3.0 manually in my desktop, everything stopped.. not only the taskbar icon.
      I had to return it to 4.2.0.
      Crashplan did not updated automatically, so I will let the way it is (4.2.0).

      Reply
      1. Richard's avatarRichard

        Yes, the service is running. It runs smooth on the Syno, but the taskbar icon refuses to connect. (same like you)

      2. Richard's avatarRichard

        As i was saying, probably it has to do with the GUID…. but where to put it… thats the question

  42. Per's avatarPer

    Hi,

    If you are like me running the stone age DSM 4.3 with package 3.6.3-0027 you might end up with issues for the /var/lib/ directory. The upgrade to 4.3.0 was constantly removing the directory /var/lib/crashplan until I adjusted the /var/lib/ and the crashplan user permissions. Apparently, Crashplan tries to create some other files in /var/lib/crashplan (apart from the .ui_info) and if it fails. the directory gets removed.

    Reply
    1. Anil's avatarAnil

      Hi Per, I have DS209 with DSM 4.3 or something close, but basically DSM 4.x. Sometime around July 1st or so, apparently crashplan on DS got automatically updated and the engine/backup stopped working. The strange thing with me is that the CrashPlan wasn’t listed in the packages community tab on Synology DS and long story short, I ended up uninstalling CrashPlan from my DS, but now I can’t find the CrashPlan package to re-install. Do you happen to know how I could re-install CrashPlan on my DS? Appreciate any help here.. Thanks in advance!

      Reply
      1. Per's avatarPer

        Hi,

        The reason for the missing package is that you are running DSM 4. Patters probably removed this from the community pages with version 0028 when he did the re-write.

        You have two options
        – Upgrade to DSM 5
        – Find the DSM4.3 package from “somewhere” on the internet and do a manual package install.

        //Per

      2. Anil's avatarAnil

        Thanks Per!

        @Patters, can you please point me to the latest package for DSM4.3 so that I could install it manually?

      3. Anil's avatarAnil

        Thanks Per! Could you please point me to where I could find how to upgrade to DSM5? DS209 is not listed on Synology for DSM5.

  43. Flavio Endo's avatarFlavio Endo

    Hello!
    Anyone had the same issue as me, and have it solved?
    My CrashPlan on the Desktop have updated today :( and now I got a weird issue.
    Backup is running normally (crashplan.exe and backup service are up and running) but the Crashplan Tray is grey and show the information “unable to connect to the backup engine.
    See the print screen I made here:
    https://monosnap.com/file/Y5rBS6ZDKFQvdr2KiJEZ0LNM7djKjf

    Thanks!

    Reply

Leave a reply to Richard Cancel reply