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. Heinrich's avatarHeinrich

    Good day! I’ve got a DS410 running DSM 4.2-3202. I’ve entered http://packages.pcloadletter.co.uk in the package sources tab but the Crashplan module does not appear. I’ve done a refresh to no avail. The only packages that are being displayed are: CraftBukkit, OpenRemote, and Minecraft.

    Reply
    1. patters's avatarpatters Post author

      Your NAS’s CPU is not supported. Someone has made a package for those older PowerPC processors – I linked to it in the main article I think.

      Reply
      1. Heinrich's avatarHeinrich

        You’re correct! I apologize – I misread the list and referenced the DS-410j which is just above the DS-410 in your list. My CPU is indeed a PowerPC.

        Have a wonderful day!

  2. Sam's avatarSam

    Hi

    First of all thanks a lot for your work, so far I’m really happy with CrashPlan on my Synology after trying thins like Amazon S3 and Glacier which are both no working great or even fail completely. I have one questions though: Since Synology now officially has support for Java with their own package, wouldn’t it be possible to use this instead so that DSM upgrades would also not cause any issues? Or is there other things which are not taken care of in their distribution (like UTF-8 etc.)?

    Thanks again for your work!
    Sam

    Reply
    1. patters's avatarpatters Post author

      Hi – good question, but I don’t have an Intel NAS so I can’t really test. I had purchased an RS2212RP+ at work, but I have changed job now, so I no longer have access to it.

      Reply
      1. Sven C. Merckens's avatarSven C. Merckens

        Hi,
        I can confirm, the Java Manager of the Synology is working with the CP-packages of patters.
        Tested that on 6 machines.. no problems. Stop the CP-Package, uninstall the Java-package (from patters) before and then install the Java-Manager. Start the CP-package. Done.

      2. oecherwolke.de's avataroecherwolke.de

        Hi patters,
        just an addition. I had a problem with UTF-8 on a DS with DSM 4.2 if Your package was used. Quite interesting. The files could be recovered from the CrashPlanServer, but the extented characters were replaced. After uninstalling your Java-Package, enabling the Java Manager, installing Java with the Java Manager, this error was gone…

      3. patters's avatarpatters Post author

        Had you reinstalled my Java package after upgrading DSM though? You do need to do that because DSM upgrades always break the UTF-8 support.

      4. Robert's avatarRobert

        Does crashplan on synology upgrade itself automatically? Is there a way we can be notified of this so we know to update the java part right afterwards. It would be horrible to have crashplan update itself, mess up all the utf-8 required backups, and we are none the wiser thinking everything is fine.

      5. patters's avatarpatters Post author

        You only need to update Java after a Synology DSM version update, not after a CrashPlan update. CrashPlan do push version updates, and my scripts will apply them but you will need to manually restart the package (it stops during upgrade). Many of you have complained that this could be missed, but remember that you will get the backup status email within a few days that will notify you of failing backups.

      6. oecherwolke.de's avataroecherwolke.de

        Hi patters,
        I think the java wasn’t reinstalled. It happened on a client machine, so I can’t be sure. I think the client only updated the DSM.

      7. patters's avatarpatters Post author

        That is what I would expect then. You need to reinstall the Java package every time you update DSM unfortunately, or UTF-8 support breaks.

  3. yggdrasil42's avataryggdrasil42

    Thanks a lot for your Crashplan and Java packages, Patters! They were definitely one of the selling points for getting a Synology. Managed to get everything working on my DS213+ today. I’ll be donating to your PayPal account.

    Reply
  4. hal sandick's avatarhal sandick

    my hp homemedia server is in it’s death throes. It look like I’ll be going to a synology solution.So, i back up around 60 gigs (<50 gigs on carbonoite right now). Reading your aritcle notes, it looks like I should go with a 213 or 213+. Is the ds212j out of the question? When i install this I will contribure to your paypal account.

    Thanks.

    Hal Sandick

    Reply
      1. hal sandick's avatarhal sandick

        Thanks for the quick reply.

        sounds like you’re saying it’s the 213 or 213+. Will one work better than another?

        is it possible to add ram to either of these units?

        hal

  5. Jon's avatarJon

    I was able to get CrashPlan 3.5.2 to work – the issue seems to be with the busybox tar:
    + tar xzf /volume1/@tmp/CrashPlan_3.5.2_Linux.tgz
    tar: corrupted octal value in tar header

    Installing gnutar using ipkg allows me to install it. You might want to include a copy of this in your native archive alongisde bash, cpio etc.

    Thanks

    jon

    Reply
      1. Jon's avatarJon

        Hi Patters,

        I have a DS411+ so it’s an Intel CPU.

        Thanks

        Jon

        PS. Thanks for the great package!

    1. En Tao Ko's avatarEn Tao Ko

      Would love to see this out soon as well! :) I just updated my Synology 412+ to 2GB, and started my trial for CrashPlan Pro, now just got to start seeding!

      Reply
  6. Jeff Youngren's avatarJeff Youngren

    How do you actually edit the /volume1/@appstore/CrashPlan/syno_package.vars file to adjust up the amount of RAM? Sorry for the NEWB question, I’m at my wits end trying to figure it out. How do I navigate to that file?

    Reply
    1. patters's avatarpatters Post author

      Use an SSH session, and look up how to use the unix text editor called vi. Or you could install the app Config File Editor (which is explained in the section about automating with cron).

      Reply
  7. pitchdown's avatarpitchdown

    Hello,
    i am using CrashPlan on my synology as package. This is working very wel.

    I am looking for a solution so that the backup.log are written to a directory on my volume1 of my synology instead of the CrashPlan-directory.

    Anybody who knows if and where this can be changed?

    Thx

    Reply
  8. Koka's avatarKoka

    Hello:

    I am using DS1512+. Everything was working great until I upgraded to DSM 4.2-3202 and my clients stopped connecting to CrashPlan on 1512. Has anyone faced this issue?

    Reply
  9. plonk's avatarplonk

    I have an issue with the syno_package.vars file’s settings for USR_MAX_HEAP being ignored. This in turn is causing CrashPlanPro to fail due to running out of memory.

    I completely uninstalled CrashPlanPro and re-installed and changed the USR_MAX_HEAP in the above file to 1024M (after I upgraded my DS412+ to 2GB).

    The first time it ran it showed in the engine_output.log that it was using the value I specified. It ran great for about 2 days, then it stopped running. I restarted the service but it keeps failing after a short period of time (5 to 10 minutes).

    I checked the engine_output.log again and I find this line:
    Config already has a value for Java memory heap max; mx=512m

    But the syno_package.vars file states USR_MAX_HEAP=1024M

    I manually ran ‘source /volume1/@appstore/CrashPlanPRO/syno_package.vars’ and then echo’d $USR_MAX_HEAP and piped it through sed to remove the trailing M (for megabyte). That does come out right. (I.e. the Windows guy didn’t screw up the .vars file when using vi ;)

    The SRV_JAVA_OPTS in /volume1/@appstore/CrashPlanPRO/bin/run.conf does correctly show -Xmx1280m.

    So where is this overridden?

    This package used to work great up to about 4 weeks ago when I started to have nothing but trouble. I now have to log in and run it manually, continually restarting the service until it finishes the backup. I’d love to not have to worry about this.

    Anyone have an idea?

    Reply
    1. plonk's avatarplonk

      Just to clarify, I also tried raising the max heap size to 1280, that’s why the SRV_JAVA_OPTS state 1280 for the max.

      Reply
      1. Mike's avatarMike

        See my post in an earlier comment. I had the same issue and had to edit an XML file…

  10. Tim B's avatarTim B

    Trying to install the CP package on a DS413J, which has a Marvell Kirkwood CPU. The package is not showing up in the Package Center, despite having added the custom package source above. Is the DS413J ARM cpu not supported, or am I being particularly obtuse today?

    Reply
      1. Tim B's avatarTim B

        Yeah. Any idea why? Could there be something about how the CPU identifies to the install script?

  11. pitchdown's avatarpitchdown

    Hello,
    i am using CrashPlan on my synology as package. This is working very wel.

    I am looking for a solution so that the backup.log are written to a directory on my volume1 of my synology instead of the CrashPlan-directory.

    Anybody who knows if and where this can be changed?

    Thx

    Reply
  12. pitchdown's avatarpitchdown

    Still no option found to get the backup.log from a windows-machine (without telnet/ssh).
    Maybe there is an option to “share” the @appstore-folder on the synology.

    Anybody for a howto?

    Thx

    Reply
    1. John B's avatarJohn B

      I could never get symlinks to work properly with Windows (not even by changing the samba configuration by adding -follow or something, can’t remember the details).
      I could however get mount to work.

      First create a Shared Folder from DSM Control Panel.
      In my example I’ve called it “backup” and the actual logs will be available in a “CrashPlan.logs” subfolder.

      SSH to your NAS and run the following three commands:
      mkdir /volume1/backup/CrashPlan.logs
      chown root:root /volume1/backup/CrashPlan.logs
      mount –bind /volume1/@appstore/CrashPlan/log /volume1/backup/CrashPlan.logs

      Then copy & paste the same mount command into your /etc/rc.local file.
      That will make it available after restarting your NAS.

      I am a Linux n00b, so perhaps someone has a better way, but this worked for me :-)

      Reply
      1. John B's avatarJohn B

        Fix: the mount command needs two dashes just before bind:
        mount –bind /volume1/@appstore/CrashPlan/log /volume1/backup/CrashPlan.logs

      2. John B's avatarJohn B

        Seems I can’t post two dashes, so make sure to add one manually :-)
        In any case, you will notice immediately if you forgot, as it won’t run without them.

      3. John B's avatarJohn B

        btw, I used this to get my iTunes music to appear in the standard “Music” shared folder.

        I created a hidden shared folder called “iTunes”.
        Moved my entire (!) iTunes library from my PC to this folder
        Lastly I mount the iTunes/Music folder to appear in the “Music” shared folder (remember two dashes): mount –bind /volume1/iTunes/Music /volume1/music/iTunes

      4. pitchdown's avatarpitchdown

        Great. thx for your input.
        I created a share from smb.conf from the @appstore folder and used i symlink to the log-folder of crashplan. This procedure is also working from my windows-cliënt!

  13. Matthew H's avatarMatthew H

    It seems to me that every time CrashPlan is upgraded, a new user account is created, and this package chowns all of the destinations that are currently mounted. However, I have two external drives, one of which is always offsite, and when I swap the two external drives, I always have to manually ‘chown -R crashplan’ the destination on that drive. That’s annoying and error-prone. Is it possible for the existing user account to be reused so chowning becomes unnecessary?

    Reply
  14. Maarthok's avatarMaarthok

    Version 3.5.3 is out.
    Upgrade was automatic, but had to start the package manually. Seems to work.

    Reply
  15. Leon's avatarLeon

    Anything that needs for the 3.5.3 Update?
    My nas does not update, i was too fast to start the package.

    I readed here later that i should have waited those 10 times it tried to install, but in my logs i started the package after the 3’d time, now it dosen’t download the update at all it seems, what can i do to fix it?

    Reply
  16. Mauro's avatarMauro

    Hi Patters,
    something strange happened to me. After few weeks of working fine the backup stops. The log say “Reason for stopping backup: The backup destination was disconnected”.
    After few attempt to fix the problem (stop and restart crashplan engine, check the network, etc.) I asked the Crashplan support. Here the answer:

    “Hi Mauro,

    Thank you for contacting CrashPlan support!

    I’d like you to restart your CrashPlan engine. Please do the following:

    – Open CrashPlan
    – Double click the logo in the upper right corner
    – Type: ra, restart
    – Press enter

    If you continue to have connection issues after the restart can you please reinstall CrashPlan with the newest version of our software from http://www.crashplan.com/consumer/download.html?
    http://support.crashplan.com/doku.php/recipe/reinstall

    I reinstalled the engine but now the client can’t reach the engine. If I change the ui.properties putting a # before the line “serviceHost” it works.
    The NAS works normally, I have access to files and to the console.
    Any idea on what I can do to make it working again?
    Thanks for your answer.
    Mauro

    Reply
    1. Flavio Endo's avatarFlavio Endo

      Mauro, have you managed to make it run again? I have the same issue, and support from Crashplan have no clues on how to solve it.

      Reply
  17. Davy's avatarDavy

    After the update was installed I get: Synology repairing upgrade in /volume1/…

    What should I do to fix it, Crashplan doesn’t start anymore. A reboot didn’t help.

    Reply
    1. Dabok's avatarDabok

      Excactly the same problem over here. Problem started at April 18. New upgrade of the Crashplan software seems to be a problem

      Reply
      1. Dabok's avatarDabok

        I’ve fixed it by upgrading Java and a reinstall of Crashplan. Not sure if a reinstall is necessary, but it’s working now.

      2. Marc-Andre's avatarMarc-Andre

        How did you upgrade your java? When I try to update the Java Package it always tries to install the older version 6 and not the most latest Oracle Java SE Embedded version 7 Update 21.

  18. paul's avatarpaul

    What have I done to my install? I am running a DS1512+ with DSM 4.2-3202. I upgraded the Crashplan install to 3.5.2-0021 and now its all gone to pot. I have installed Java Manager with the JDK 6u37 Linux i586.bin.
    Crashplans appears to be running from what I can see if the log file, but I cannot connect a client to it. I get the mad Unable to connect to the Backup Engine.
    Any comments would be welcomed. Thanks

    Reply
  19. Dan's avatarDan

    Thank you for this great guide. Can you discuss the idea of running crashplan as a different account, like root? I had a few hundred files that wouldn’t backup and it turns out it was because they were owned by a different user. Once I set RW for Others it all worked perfectly.

    Reply
    1. Patrick's avatarPatrick

      Hi Dan

      I’ve got the same problem. Did you already found a solution to run crasplan as a different user ?

      Reply
  20. Firemaneric's avatarFiremaneric

    I am having the same issue after the upgrade. I am unable to connect. I uninstall crashplan, reinstall and it works until it then does the upgrade. After the upgrade it dies.

    CrashPlan has downloaded update and will restart momentarily to install the update
    Installing upgrade – version 1364274000353
    Upgrade installed – version 1364274000353
    CrashPlan stopped
    Scanning for files stopped

    After that log I am no longer able to connect.

    Reply
  21. Firemaneric's avatarFiremaneric

    I have been working on this all day. Uninstalling, reinstalling, changing configs, etc….
    Literally 5 minutes after I type here about it not working it finally works.

    Its playing with my head

    Reply
    1. Flavio Endo's avatarFlavio Endo

      Firemaneric,

      Any idea of what have solved your connection issue? I’m facing the same here with only one client.. all others are fine… weird.

      Thanks

      Reply
  22. Josh's avatarJosh

    My CrashPlan updated itself to v3.5.3 on 4/18. Since then, it only backs up nightly. It doesn’t seem to be detecting changed files throughout the day. Any ideas?

    Reply
    1. Emayarse's avatarEmayarse

      My experience as well – file change monitor process seems to have died and restart/reinstall does not fix. Synology DS 1512+ and CrashPlan v3.5.3

      Reply
      1. patters's avatarpatters Post author

        Looks like the automatic update to 3.5.3 pushed by Code42 has broken CrashPlan on Intel systems. Another user has reported that it’s because CrashPlan now requires Java 7, which at the last check didn’t work on Intel Synology systems. Can you try removing Java 6 and manually installing Java 7 using this spk (and report back with the results):
        http://packages.pcloadletter.co.uk/downloads/java1.7.0_21-merged-0015.spk

        Once this is installed, try running “java -version” from an SSH session on your NAS. Does it work?

      2. emayarse's avataremayarse

        Patters – here’s a step-by-step log of my fail:

        Synology DS1512+ DSM 4.2-3202

        1. Stop CrashPlan

        2. Uninstall patters package
        3. Uninstall Java SE for Embedded 6 (1.6.0_38-0014)
        4. Follow instructions for reinstall here: https://pcloadletter.co.uk/2012/01/30/crashplan-syno-package/

        1. First, install Java per https://pcloadletter.co.uk/2011/08/23/java-package-for-synology/
        2. Go to Oracle (http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html) and download x86 Linux Small Footprint – Headless (http://download.oracle.com/otn/java/ejre/7u21-b11/ejre-7u21-fcs-b11-linux-i586-headless-04_apr_2013.tar.gz) – 32.9 MB (note: Safari automatically uncompresses the package – I needed Firefox to get proper behavior)
        3. Put it in the public directory on the Synology
        4. DSM Package Center – Manual install of Java SE for Embedded 7 1.7.0_21-0015 (java1.7.0_21-merged-0015.spk)

        1. Install Message: NOTE – This package does *not* start and stop like other packages. Java is correctly installed if you can see the runtime and HotSpot version numbers, and local information in the package Log tab. (I can)

        5. Check to enable package repository in Package Center (under settings -> package sources): http://packages.pcloadletter.co.uk/ (good)
        6. Go to Community packages in DSM Package Center and install CrashPlan 3.5.2-0021

        1. Downloaded
        2. Accept the terms
        3. Install Message: Wait a few seconds, then stop and restart the package to allow desktop client connections.
        4. Status shows stopped. When I select action -> run, the install message (#3 above) reappears and CrashPlan does not appear to start.

        5. ssh-ing onto the Synology shows this:

        1. synology> java -version
        Error: dl failure on line 864
        Error: failed /volume1/@appstore/java7/jre/lib/i386/client/libjvm.so, because /volume1/@appstore/java7/jre/lib/i386/client/libjvm.so: cannot handle TLS data

      3. patters's avatarpatters Post author

        Thanks, that’s very helpful of you. That’s the same error message we had with Java 7 on Intel from the beginning (“libjvm.so: cannot handle TLS data”). I no longer have access to an Intel syno – can you tell me whether DSM 4.2’s new Java Manager package will let you install Java 7? Or is it Java 6 only?

      4. emayarse's avataremayarse

        Try #2

        Hey – sorry for the delay, but my neighbor came by and we had to go out and drink a few pints – yes, I’m safe to type.

        * Uninstall CrashPlan
        * Uninstall Java
        * Select Java Manager to install
        * Click on Java Manager – then “Install Java”
        *
        * the pop-up window sends you to “Java SE Downloads” (http://www.oracle.com/technetwork/java/javase/downloads/index.html)
        * The other messages say: “Click JDK’s Download button next to Java SE 6 upgrade 37 (DSM currently supports Java 6. The minor version may be larger than 37).
        * I picked Java SE Development Kit 6 Update 45 (jdk-6u45-linux-i586.bin)
        * Browse to it in the Install window and select OK
        * Message: You have installed Java successfully.
        * Java Manager reports Installation status as Installed, Java version is 1.6.0_45, and CLASSPATH as .:/var/packages/JavaManager/target/Java/jre/lib
        * ssh-ing to the Synology shows this:
        *
        * synology> java -version
        java version “1.6.0_45”
        Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
        Java HotSpot(TM) Server VM (build 20.45-b01, mixed mode)

        * Go to Community packages in DSM Package Center and install CrashPlan 3.5.2-0021
        *
        * Downloaded
        * Accept the terms
        * Install Message: Wait a few seconds, then stop and restart the package to allow desktop client connections.
        * Status shows running! Selected stop and gave it a few minutes to stop
        * Selected run. Again, the status shows Running in green!!!
        * CrashPlan client on Mac (10.8.3) connected and signed in with existing login to CrashPlan. Please Wait was on the screen for about 2 minutes
        * Adopt previous Synology backup, Again, Please Wait (existing backup was 15.4 GB, so not very big, but I don’t know how long to wait – about 5 minutes)
        *
        * Was entering archive key, when CrashPlan stopped responding and upgraded me to 3.5.3 – darn
        * Client could not auto connect to CrashPlan backup engine, so quit and manually started process in the Package Center.
        *
        * Still shows 3.5.2-0021
        * Despite status showing running, ps command shows no crashplan processes running
        * Client still could not connect to CrashPlan backup engine, so I stopped and restarted it again.
        *
        * ps command shows lots of CrashPlan processes running
        * Client connected!!!
        * Entered archive key
        * Now synchronizing file information with CrashPlan central

        The final question is whether or not real-time file monitoring is now enabled… I’ll wait and see.

      5. emayarse's avataremayarse

        BTW – ps shows 68 separate crashplan processes running! Here’s a sample of one:

        617 crashpla 700m R N /var/packages/JavaManager/target/Java/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false

        still 35 minutes left to go on my current backup. Then I can see if real time file monitoring is working or not.

      6. ds1511+'s avatards1511+

        anyone have any update or success with the intels?

        on a non-intel (ds411), i was able to use patters’ java 7 and restart and everything is working well again (including realtime)…on a intel ds1511+ real time no longer works – i can connect to the client and backup manually (with a rescan)

      7. tcw's avatartcw

        I have a working CrashPlan+ installation on a DS710+ (Intel Atom) with CrashPlan+ v. 3.5.3 and DSM 4.2-3211. I’m not sure how my installation would be different than others so I’m not sure how much help I could be troubleshooting. I am using patters’s Java 6 package. Real time backups are working. I was a holdout and waited a long time to upgrade to DSM 4.2, but I finally did about a month ago. The only thing I notice is that CPU usage seems slightly higher than it did in 4.1. I have approximately 750 GB in my backup set (about 50k files).

      8. ds1511+'s avatards1511+

        not sure why, but my ds1511+ suddenly starting working again, including real-time…nothing different except a few reboots and manual syncs, but everything is working just fine now…using the synology java manager with 1.6.0_41 and 3.5.2-0021 (auto-upgraded to 3.5.3)

  23. Leon's avatarLeon

    How can i clear the log file? Also where do i see what version i have, it seems i only see what client version i have (your package version) but if it update on its own, where can i see that version? I think my crashplan have updated, but im not 100% sure it have, since your client says its the old version, but at the same time i think it has updated in the background *confused*

    Reply
  24. Andreyy's avatarAndreyy

    I found the root of the problem after upgrading to 1364274000353 (windows client can’t connect to synology). The updated version opens port only to localhost connections (netstat shows the following info: localhost:4243). So external connection (even from your computer) to CrashPlan engine are not allowed.

    I found a workaround. I made a port tunnel using SSH client PuTTY. So that windows:4243 is mapped to synology:4243 and then connect windows client to windows:4243 and it works!

    Reply
    1. Flavio Endo's avatarFlavio Endo

      Andrey,

      Could you please explain in details how to config the Putty to make it happen?

      Thanks and regards

      Reply
      1. Fred's avatarFred

        Hi! I would also like to know how!
        In putty, in Tunnels I put 4243 redirected to my server’s IP address, 4243, but it doesn’t change anything.
        In netstat, the connection doesn’t seem to be active:
        tcp 0 0 localhost:4243 0.0.0.0:* LISTEN

        Or is there a way to modify the config file so that the port is opened to external connection?
        Thanks in advance for your help!

      2. Andreyy's avatarAndreyy

        First of all, I must say that for now Crashplan engine allows direct connection to it. Maybe it updated somehow.

        Regarding using workaround:.
        1. You have to connect to Synology using PuTTY.
        2. Then check if Crashplan engine accepts all connections or localhost-only connection.
        put this line:
        netstat -a | grep 4243
        if it gives you output like this, then it allows all connetions, and you don’t need any tunnels.
        tcp 0 0 0.0.0.0:4243 0.0.0.0:* LISTEN
        if it gives you something like that:
        tcp 0 localhost:4243 0.0.0.0:* LISTEN
        then you need a tunnel.
        3. In Putty Configuration, go to Connection -> SSH -> Tunnels. Then create a tunnel
        from L4244 to :4243.
        4. Change config ui.properties (on Windows client side). Set the following values:
        serviceHost=127.0.0.1
        servicePort=4244

        That must work.

  25. Jay Pete's avatarJay Pete

    Hi…

    How do you check for java on the Synology Nas. I could not get your Java Package installed on my Synology DS413. So I used another package by MissileHugger, which installed easily. I have Java working on the machine now.

    I have set a JAVA_HOME variable to point to the java installation, and also added it to the path.

    When I try to install the CrashPlan package it says that Java isn’t installed. So I was wondering how that check is made, since java is very clearly installed.

    If I try to install your java package, then it detects the installed Java fine.

    Is there a setting that I need to set in order to install CrashPlan?

    Thanks!

    Reply
    1. patters's avatarpatters Post author

      My packages check for JAVA_HOME, and also for the existence of the java binary at $JAVA_HOME/bin/java. You would need to be sure this variable is added to the root user’s ~/.profile. Also, be aware that JAVA_HOME should not point to the folder containing the java binary, but it should be one level up. So you should be able to run:
      $JAVA_HOME/bin/java -version

      Reply
      1. Jay Pete's avatarJay Pete

        That was it exactly. I pointed JAVA_HOME to the binary. Fixed and now it recognises java, but the version it looks for is 3.5.2, and the latest version available is 3.5.3. I tried downloading the binary and then renaming it. It installs but won’t run :-)

      2. Jay Pete's avatarJay Pete

        Managed to download the correct version of CrashPlan and place it in /public, but it still doesn’t run after install. The java version is 1.7.0_21.

      3. Jay Pete's avatarJay Pete

        Where is CrashPlan installed? I can’t find it in /opt/crashplan or /usr/local/crashplan.

        How can I verify that it actually installed?

  26. Micke's avatarMicke

    Hello!
    I have used your installation a few months now and everything has worked well but recent times I get error a message in the CrashPlan client a few minutes after I start it:

    “CrashPlan has disconnected backup engine”

    I use a Mac with the latest CrashPlan installation. I have uninstalled the client and installed it again with no success.

    Do you have any idea why it is like this?

    Reply
  27. Flavio Endo's avatarFlavio Endo

    Hi Patters and community,

    How are you? I’m need to know if you guys have any idea of what could be happening with my Crashplan.
    First let me introduce to my configuration and hardware:
    I have under the same router (Asus RT-N56U), one Desktop (Dell), two notebooks (Dell), the Synology NAS 411+ (DSM 4.2, Crashplan package from Patters, Java 6 all updated). I have this working for over 1,5 years.

    Desktop and notebooks all backup to NAS and to Crashplan Central.
    Nas also backup to Crashplan Central.

    Now the story, after the update to 3.5.3 done in all machines automatically, I have everything fine, except for one connection btw my Desktop and NAS.

    It connects for 2 or 3 seconds and disconnects, simple like that.

    I have made a lot of things already, follow a couple of things I have done:

    – Completely uninstalled Desktop and NAS Crashplan, installed again and adopted the corresponding machines.
    * Note, after the adoption, the Desktop connects to NAS, and stays connected until the last minute of the synchronization process, after that it goes intermittent again.

    – Gave the command “guid new” on both machines (suggestion from Crashplan support, that by the way do not have a clue of what is happening, although they were very responsive, no complain)

    – Reset router configuration, although I don’t see how the router could be an issue since all other machines are working under the same router, and it was working normally before the 3.5.3.

    – Have unplugged all machines except Desktop and NAS from the router to check any interference from other machines (notebooks) (also suggestion from support)

    Well, this summarizes I couple of days of work, and I might have tried other things that I did not captured here.

    If anyone has any idea of what could be done to re-establish my connection, please let me know.

    Thanks!

    Reply
    1. Flavio Endo's avatarFlavio Endo

      Additional information:

      I have Avira in my machines, nothing changed since them, but just as a matter of record, I have disabled fully the firewall and all Avira, and nothing helped.

      Thanks,
      Flavio Endo

      Reply
    2. Flavio Endo's avatarFlavio Endo

      Well… something very.. very weird just happend.
      After all these days of hard work, and no solution, my Desktop’s Crashplan simply deleted all my backup destination (Crashplan Central and NAS).
      I did nothing.. I did not requested that.
      I looked at the NAS and my files are not there anymore.. so I lost 1,5 years of backup!

      Note, I did not lose any of my backup settings, only the destination, as if I have requested to remove the destination. I would never do that.
      Anyway Crashplan did.

      Now I had to add again the destinations to all my backup sets. And it is doing all the initial backup again.
      So far the connection issue is not present anymore.

      It seems something corrupted along these days. Although until this morning everything was OK, except for the connection intermittent.

      Anyway, I’ll keep information here updated.

      Tks!

      Reply
  28. Anders Holm's avatarAnders Holm

    Hi Patters!

    Thank you so much for this package. I was after a month almost done with the backup, however, now the package seems like it’s not working anymore.
    It seems as if the package is stopping and then starting again every 10 minutes or so, without ever backing anything up.
    I’ve uninstalled the package and reinstalled it, then adopting the old backup and trying to get it working, however it’s still acting up.

    I’m on a DS412 with DSM 4.2-3211 running your package version 3.5.2-0021.
    I’m looking very much forwards to your answer.

    Thank you in advance

    Reply
    1. John B's avatarJohn B

      Investigate the logs in /volume1/@appstore/CrashPlan/log
      They may give you more info.

      Reply
  29. Marten's avatarMarten

    Crashplan _seems_ to be fine, however for some when backupping it seems to be in some type of state where it is *slowly* analyzing each file. So slowly in fact it feels like it’s almost backing the file up in its entirety.

    What gives? Suggestions?

    Reply
    1. Marcus's avatarMarcus

      I’m observing this since I’m running CrashPlan on my Diskstation. Very often backup is extremely slow and even the “analyzing” part is very slow. The only thing you can do in my experience is stop and start Crashplan again or reboot your Diskstation. I have no idea what is causing this. A couple of months ago I have asked here about this behaviour but got no replies.

      Reply
  30. Mike's avatarMike

    Hi Patters,

    Can yo you please walk through the process of using file config editor to update the heap size? I am at a loss at how to even find the file that I need to update.

    Thanks

    Reply
    1. Grant's avatarGrant

      Mike,

      Edit the syno_package.vars. I used ssh via Mac OS Terminal and a text editor (nano) on the NAS to edit it. I’m not sure how you use “file config editor”. There’s a key called USR_MAX_HEAP. Just change it to your desired value.

      The file is located at /volume1/@appstore/CrashPlan/ (or CrashPlanPRO)

      Reply
    2. Micke's avatarMicke

      Hi Mike
      In Config File Editor choose “Config File Editor” from the drop-down menu.
      Create a new line and paste this into it:
      /volume1/@appstore/CrashPlan/syno_package.vars, CrashPlan
      Save and close the editor and start it again. Now you can choose “CrashPlan” from the drop-down menu. Remember to hit Save when you are done editing.

      Reply
  31. Haravikk's avatarHaravikk

    Thanks for making these packages available! I just wanted to note in case anyone’s interested that I found a way to get CrashPlan to backup through symbolic links (in my case I have historical backups with a symlink pointing to the latest, which I want CrashPlan to work from).

    Anyway, doing it is fairly simple; just point the CrashPlan client to your symbolic link as a backup source like you would for any other folder. It will appear as one file, that’s fine, close the client and stop the CrashPlan package on your NAS. Now SSH onto the NAS (probably need to be as root) and go to /volume1/@appstore/CrashPlan/conf and open my.service.xml in a text editor (on Synology NASes it seems to only have vi available). Once opened, scroll down till you find your backup set with the path to your symbolic link. Simply add /./ to the end of the path (that’s a slash, a period and a slash) and save. Once you restart the service CrashPlan will now backup using the contents of whatever folder your link points to, though the client will unhelpfully list it as being named “.”.

    Reply
  32. Tom's avatarTom

    Hello
    I have the package installed on my DS211.
    Over the last couple of days I have experienced a lot of the “CrashPlan has been disconnected from the backup engine”.
    At first I thought this was due to insufficient RAM however it seems a lot of users are experiencing this problem the last couple of days. Do you know if there have been patches installed that makes the connection extremely unstable?

    Before I buy a new NAS I would like to try and allocate a fixed heap size but I can’t seem to locate the “/volume1/@appstore/CrashPlan/syno_package.vars”. Should I locate that file on my mac or within the DSM file station?

    If you had to choose between a DS412+ (Intel) or a DS413 (Freescale) which would you pick? Both have 1Gb of ram but the 12+ has a higher cpu.

    Reply
  33. Ametz's avatarAmetz

    What is the latest version?
    My synology says i having: 3.5.2-0021
    It updated before to: 1364274000353

    Why dosen’t it update if 3.5.3-???? is the latest?

    Reply
  34. Christopher's avatarChristopher

    I set this to backup 566GB on my NAS. Says it will take 4 months as it is only moving at 448Kbps. Yet my connection can do 1.8MB/s.

    Reply
    1. ds1511+'s avatards1511+

      Crashplan throttles your connection…make sure you’re maxed out in the Settings/Network tab, and you can try to minimize versioning and de-duplication in Settings/Account, but it will still throttle after a few GBs…my connection is 35M up and I was capped at 1.5-2M for months so a 2TB set took 3.5 mths

      after a while it will uncap for the first X GB of data (not sure what X is), but cap again on large syncs

      Reply
      1. Christopher's avatarChristopher

        Waiting 4+ months for a backup just isn’t going to work for me.
        I had backed up 500GB with Mozy a long time ago and it only took about 1-2 weeks.
        Been using local disks which I swap out for a long time now, will stick with that, I thought about using Crashplan on Synology just to backup to a disk and swap it, but it seemed to take a lot of resources on the NAS (java was eating 20-40% cpu even when not backing up).

  35. jenf's avatarjenf

    Hello,

    Great Product!
    I have however a problem. I have a 211+ and everything went fine, until yesterday. The package is stopped and I can’t restart it. When I restart, nothing happens, not even an error message is displayed.
    Does anyone know where I can look for a clue?

    Thanks in advance!

    Reply
  36. Mauro's avatarMauro

    Hello,
    apparently CrashPlan on my NAS slow down dramatically. I sent the logs to CrashPlan support and they told me that it is a memory issue, CrashPlan backup engine is running out of memory and ask me to increase the value of the this parameter ‘-Xmx384m’ in the run.conf file.
    They recommend at least 1GB of RAM per each 1TB of data being backed up, so i have to set the virtual memory to 896 or 1024.
    I found the run.conf file in the directory /volume1/@appstore/CrashPlan/bin and I changed it to 896, but after Crashplan engine restart it’s set again to the old value (384).
    There is another config file that must be changed?
    Crashplan doesn’t support the Synology headless configuration, so I can’t get any help from that side. Someone here can help me?
    Thanks a lot
    mp

    Reply
    1. ds1511+'s avatards1511+

      @Mauro

      I believe you need to follow these instructions:
      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 very large backup sets by editing /volume1/@appstore/CrashPlan/syno_package.vars

      For my 2TB+ set I am using 1.5GB of Ram

      Reply
      1. Mauro's avatarMauro

        Thanks a lot for your answer.
        So the only way to fix the problem is to increase the physical RAM. No way to allocate more virtual memory?

  37. Alan Jackson's avatarAlan Jackson

    Patters,

    Thanks so much for the work you have done. I got everything up and running on a DS1010+ running 4.2-3202. The problem I am having though is my 50GB folder is being read by the client GUI as only being 3.1GB. It is calculating the wrong size and doesn’t appear to be backing up the entire folder because of this. Any suggestions?

    Alan

    Reply
  38. Mauro's avatarMauro

    Hi Patters,
    sorry for my last message, I was tired ;-)
    I did what you suggest and it seems to work fine
    Thanks a lot for the help and for the work you do.
    Mauro

    Reply
  39. jason's avatarjason

    I have been running crashplan with my 1512+ for a couple of months without any problems. Up until 3 days ago, crashplan failed to back up my diskstation. I noticed that it could not see my diskstation anymore. I tried reinstalling both crash plan and the packages for the diskstation but nothing worked. Anyone could offer some advice,
    please?

    Reply
  40. Richard's avatarRichard

    Any reasons why restores would be incredible slow? 6hrs for 2.4MB. Crashplan pointed out the following in the logs I uploaded before saying Headless wasn’t supported and I’m on my own

    [05.11.13 20:57:38.312 WARN MQ-Peer-2 com.code42.os.posix.PosixFileCommands ] Exception in lchown() for file=/volume1/@appstore/CrashPlan/conf/2013LifeSummery.pdf, Operation not permitted (EPERM)
    [05.11.13 20:57:38.416 WARN MQ-Peer-0 com.code42.os.posix.PosixFileCommands ] Exception in lchown() for file=/volume1/@appstore/CrashPlan/conf/2013Summery.pdf, Operation not permitted (EPERM)

    Thanks

    Reply
  41. Mike T's avatarMike T

    I am considering installing the CrashPlan package, but wonder: How often does CrashPlan change their software such that one has to “rebuild” the Synology set-up?
    If that happens several times a year, that could be a pain… Or does your package semi-auto-update? (That is, do you note that CrashPlan has updated their software and then you update your package in such a way that the Synology NAS notes that an update is available and allow one to select that for updating in a similar way to the Photo Station package?)

    Better yet: Has anyone heard anything about if and when Synology might officially support CrashPlan?

    -Mike

    Reply
    1. John B's avatarJohn B

      I can see above that other people have a lot of problems with CrashPlan, but I have personally never had it fail on me.

      I have just one cosmetic issue:
      DSM shows version 3.5.2-0021 installed and the “app.log” shows CPVERSION = 3.5.3 – 1364274000353.
      So it has auto-updated correctly without me doing any “rebuilding” but DSM does not reflect that.

      The only time I am aware of that we are supposed to do anything special is when you upgrade DSM, and that is to reinstall Patters Java package.
      The reason for this being that the DSM upgrade removes the UTF-8 support that Patters added to Java embedded.

      I have since switched to Oracle’s Java Manager, which installed the full Linux x86 JDK.
      Still version 6 though, which they have deprecated.

      Reply
      1. patters's avatarpatters Post author

        The fact that the only niggle I can do anything about is cosmetic is the main reason that I haven’t re-issued the package for 3.5.3. It’s entirely possible that the people who have experienced failures are trying to backup too much with too little RAM.

      2. Mike T.'s avatarMike T.

        Well, that sounds great to me! Maybe I can find some time this upcoming weekend to install the package. Thanks John, and Patters!
        -Mike T.

    2. John B's avatarJohn B

      Also, I have ordered 2GB ram for my DS411+II, as I run both CrashPlan and SABnzbd, among other packages, and they sure love their memory :-)

      Reply
  42. eff_cee's avatareff_cee

    Hi Patters – I have a DS213J with Marvell Kirkwood arm370 ARM processor and the crashplan package is not showing in your source ?

    Is the 213J supported ?

    Reply
    1. patters's avatarpatters Post author

      No that’s a new type of CPU. I’ll try and get a Java package done imminently, and Serviio next, but I think CrashPlan could be difficult.

      Reply
      1. eff_cee's avatareff_cee

        Thanks Patters – one of the reasons for me choosing which DS to buy was whether CP will run on it. Should have checked this before purchase of DS :-) If you think you won’t be able to build a version for this CPU, I might swap it for a DS213+ (which has the Freescale QorIQ P1022 PPC processor)

  43. Matt's avatarMatt

    Hi ; I’m thinking about purchasing a DS213. I’m also looking to use the AES256 encrypted folder feature. Is anyone leveraging crashplan with a DS213, and syncing the raw encrypted files themselves? I want to sync the encrypted files, and NOT the realtime-decrypted unencrypted variants.

    Reply
  44. pitchdown's avatarpitchdown

    Hello,
    are there also possibilities to Backup iscsi-drives on the synology using CrashPlan?
    In which folder can i find the iscsi-folders?

    Thx

    Reply
    1. Joerg W.'s avatarJoerg W.

      Assuming you have only one volume created: /volume1/@iSCSITrg
      If you check this folder via SSH, you’ll see files – unfortunatly CrashPlan does not show these and keeps showing me a zero for the folder.
      -rw-rw-rw- 1 root root 1099511627776 May 24 00:18 iSCSI_1_LUN-1_000
      -rw-rw-rw- 1 root root 1099511627776 Apr 8 14:34 iSCSI_1_LUN-1_001
      -rw-rw-rw- 1 root root 1022202216448 Apr 8 14:34 iSCSI_1_LUN-1_002

      Joerg

      Reply
      1. Joerg W.'s avatarJoerg W.

        Simple Solution: Let CrashPlan run on the machine that uses those iSCSI-Volumes.

    2. John B's avatarJohn B

      As Joerg W. mentions – the very best option is to install CrashPlan on the client(s) that use the iSCSI volumes. That way you only backup what is really necessary and only when it’s necessary.

      A bad option would be to use DSM to schedule a backup of your iSCSI volumes and then have CrashPlan perform a backup of this backup:
      – Make sure you have a shared folder for this purpose (you will specify a destination subdirectory, so it need not be for this exclusive purpose).
      – Then go to the DSM Menu / Backup and Restore and create your LUN backup task.
      – Lastly configure CrashPlan to perform a backup of your backup
      but you really should consider getting an unlimited-user CrashPlan license and install it on the end-clients.

      Reply
      1. Joerg W.'s avatarJoerg W.

        I would’t call that even a bad option! You are trying to backup a mounted Volume with an anknown filesystem without making sure it is not mounted. That will fail for sure. You can’t be sure that the structure is beeing kept consistent during backup. Any data written in the meantime will render your backup efforts useless… don’t try it this way!

      2. John B's avatarJohn B

        It /is/ possible (Synology will make a snapshot and perform the backup of that), and I did use it this way for a short period for a couple of Hyper-V VMs, but:
        a) you do need to be aware of the consequences of doing it this way
        b) you do need to be sure your OS / apps can handle restores
        c) you do need to perform at least one test-restore to make sure your process works

        I ended up just installing CrashPlan in the VMs, massively reducing the backup task both in size and complexity.

        Watch this video for an example (alternatively start it from the beginning):

        As he says, a restore will be seen as a power failure and we know they are a gamble.

Leave a comment