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. howheels's avatarhowheels

    Unfortunately none of the work-arounds posted are working on my DS411j. Looks like another thing causing me to face the hard reality that my aging NAS is a bit too obsolete. I’m planning to migrate my CrashPlan archives to a Windows PC until I can convince management, err wifie, to allocate more funds to the IT budget. Hope all is well with you Patters.

    Reply
  2. IceFlame's avatarIceFlame

    I have my DS212j working again. If you hava java 8 installed, add the following to the install.vars file.

    JAVACOMMON=/volume1/@appstore/java8/ejdk1.8.0_77/linux_arm_sflt/jre/bin/java

    Reply
  3. Wouter Overmeer's avatarWouter Overmeer

    Yay, I finally have my DS212+ working again! If you have Java 8 installed, you can use the following in the install.vars file:

    JAVACOMMON=/volume1/@appstore/java8/ejdk1.8.0_77/linux_arm_sflt/jre/bin/java

    Thanks for all the replies above, with some trial and error it’s running again. :)

    Reply
  4. David Meinert's avatarDavid Meinert

    Patters – echoing Marc Weinstock. can you please jump in here even if it’s just one sentence. are you still supporting this package?

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

    Wonder whether Crashplan now have disabled the setting.
    After I changed it to a month ago I got up to 2MB/s upload speed, and a typical photo session of say 3GB worth of files was done in a couple of hours. But now it is back down to max 100 KB/s and the same amount of data again takes days to back up.
    Changing the DeDup value to 0 or 1 doesn’t seem to have any effect whatsoever.

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

      Was hit by a new update from Crashplan yesterday. Now the upload speed seem to be back on track again.
      The real-time file system watch doesn’t seem to be quite up to it though. Well, changed Verify Selection setting back to every day to take care of that.

      Reply
  6. Alex's avatarAlex

    I apologize if this has been discussed already, but I’m using a DS1515+ (Intel), and my CrashPlan has been down for about 25 days now. I’ve gotten 4.6.0 to install just fine, and I just did the JAVACOMMON method, but CrashPlan seems to start scanning, then immediately stop. This happens every 2-3 minutes or so. Anyone know how to fix this? It’s not an installation issue at this point, and Java shouldn’t be the issue anymore either; I wonder if there’s just some setting I have to change somewhere..

    Reply
  7. patters's avatarpatters Post author

    Hi all, sorry for the long absence. I switched client at work a few months back so I didn’t have much time, have been on holiday and have had quite a lot of long weekend breaks, all of which left me with less time to spend on Synology projects. I tried to quickly fix CrashPlan when it broke over Easter but stopped when I realised how broken it now is. It’s frustrating how Code 42 seem to keep wrecking it for its own sake. I am looking into fixing the package now, packaging up the necessary non-Intel JNA files and sticking the logic in there so the older CrashPlanPROe clients can remain working from the same package.

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

      Just to chirp in – smooth sailing on my DS412+ with CrashPlan 4.6.0 latest build and Java 8.91
      Only problem seems to be that the real-time file system watch is somewhat dodgy, so I’m running daily selection verification.

      Reply
  8. Joe's avatarJoe

    I followed the guide, had it working for like 2 minutes then it did a forced update when I logged in first time and it broke Crashplan. Rebooted nas but no beans. Service on NAS won’t start now. Log says “repairing”. Any suggestions?

    Reply
  9. Alexander's avatarAlexander

    Just got an e-mail from CrashPlan:

    Our records indicate that one or more of the devices associated with your CrashPlan account are using an operating system that does not meet the supported operating system version requirements.

    Beginning on May 16, 2016, all devices that connect to the Code42 public cloud will be upgraded to CrashPlan app version 4.7. If you use another computer you own or a friend’s computer as a backup destination, both computers must upgrade to CrashPlan app version 4.7 in order for backups to continue. These computers must be upgraded to a supported operating system so that the CrashPlan app can automatically upgrade to version 4.7 and continue computer-to-computer backups.

    Details on this topic and your options can be found on our support site.

    We take great responsibility in protecting your data and we thank you for your ongoing trust.

    Sincerely,

    The CrashPlan team

    Reply
    1. George Khairallah's avatarGeorge Khairallah

      I was just going to ask about what Alexander posted… Does this mean that Crashplan will no longer work on Synology from May 16 on out? it almost sounds like they’re going to make sure to explicitly block it from running? Anyone have any insight on this?

      Reply
      1. Martin's avatarMartin

        I’m confused by this as I don’t think it affects me (but I got the email). I’ve a DS1513+ running DSM 6. I’ve confirmed the kernel is 3.1.0.77 & glibc is 2.20. All my other installations are Win10 so should be supported.

        Requirements apparently:
        Linux using:
        Kernel version 2.6.32 or later and
        glibc version 2.9 or later

        The following commands in a SSH session will get you kernal & glibc versions:
        uname -r
        /lib/libc.co.6

      2. Wayne's avatarWayne

        Martin…

        All my linux systems and both NAS fail this compatibility test.

        The kernel version is fine for all of them, but none have glibc versions high enough. Even Ubuntu 15.10 is only 2.21.

      3. Martin's avatarMartin

        I fear I’m being stupid here. Isn’t 2.2x > 2.9? As a sanity check Wikipedia lists 2.9 was released 2008 & 2.20 was released 2014.

        I don’t think I’m affected.

      4. patters's avatarpatters Post author

        Ok, so it’s some silly non-decimal numbering. Typical Linux :)
        People have a habit of numbering document revisions in this way at my work – confusing as hell.
        We should be ok then. Maybe they sent the warning because they’re tired of receiving support requests for unsupported systems.

      5. Veni Vidi Vici's avatarVeni Vidi Vici

        My DS213+ running DSM 5.2-5592 Update 4, is NOT compliant with CrashPlan ver. 4.7’s new requirements.

        DS213+ is running:

        Linux ver. 2.6.32.12 (okay)
        glibc ver. 2.8 (NOT okay)

        Will upgrading to DSM 6.0 also upgrade glibc to >= glibc ver. 2.9?

  10. nh_ets's avatarnh_ets

    I got that too…Patters will this cause another workaround. Any details of changes for 4.7? We usually don’t get these types of alerts

    Reply
  11. Chris's avatarChris

    I just received an email from CrashPlan stating that 4.7 will be released on May 16th and that my device is running an unsupported OS so it won’t work.

    I guess I will be moving on to iDrive which I have been testing using the free version for a few weeks and seems to get the job done, albeit not nearly as full featured as CrashPlan.

    Patters, thanks for all your hard work over the years, I know everyone here appreciates it.

    Hopefully CrashPlan/Synology will release a native package one day and I will return.

    Regards,

    From Code42:

    Our records indicate that one or more of the devices associated with your CrashPlan account are using an operating system that does not meet the supported operating system version requirements.

    Beginning on May 16, 2016, all devices that connect to the Code42 public cloud will be upgraded to CrashPlan app version 4.7. If you use another computer you own or a friend’s computer as a backup destination, both computers must upgrade to CrashPlan app version 4.7 in order for backups to continue. These computers must be upgraded to a supported operating system so that the CrashPlan app can automatically upgrade to version 4.7 and continue computer-to-computer backups.

    Details on this topic and your options can be found on our support site.

    Reply
  12. Derek's avatarDerek

    What is needed to make a synology compliant with this requirement? Upgrade to DSM 6? Or is there no way to make it compliant?

    Reply
    1. Clarence's avatarClarence

      Hey patters, thanks for the updates! The only reason I can sleep soundly tonight because I know my data is safely backed up.

      Just a heads up, the recent changelog dates are still 2015. (:

      Reply
    2. Charles's avatarCharles

      Wow, that was pretty damn fast, thanks as always.

      Fingers crossed that the impending 4.7 update many of us are receiving strongly worded emails about doesn’t unravel everything.

      Crashplan are increasingly blunt to home users it seems these past few months. They should consider that many of us are also enterprise users in their day job and the rising levels of concern are certainly being noticed.

      Reply
      1. hal's avatarhal

        Patters,

        I updated to your new package (although i had already manually updated to 4.6 403).

        then I took the plunge for dsm 6. I can happily say that crashplan is working on my ds213+.

        thanks and worth the wait. :-)

        Hal

  13. kamie's avatarkamie

    Thanks Patters, I just got a notice from Crashplan about the pending update to 4.7 in May 16,2016. The notice informed me that one of my OS’s would not be supported and I suspect it is the NAS. Looks like 4.7 will require Kernel version 2.6.32 or later and
    glibc version 2.9 or later. Anyone else get the message?

    Reply
    1. Louie's avatarLouie

      I’ve gotten the email too, and I’ve heard from others receiving it as well. Anyone know what the kernel and glibc versions are for the latest DSM 5.x?

      Reply
  14. Robert Cheng's avatarRobert Cheng

    My local Win7-64 Crashplan client will not connect to the headless client (4.6.0-0038) running on my 1511+ DSM 6. I’ve confirmed that my ui.properties file located at c:\program files\crashplan\conf contains the proper local IP address and service port (4243). I’ve confirmed that my .ui_info file located at c:\ProgramData\CrashPlan contains the proper GUID found at /var/lib/crashplan/.ui_info and IP address is 0.0.0.0. I’ve stopped and restarted Crashplan from within Synology multiple times. Java is 1.8.0_91-0039.

    Anything else I can try?

    Reply
      1. Robert Cheng's avatarRobert Cheng

        Awesome this worked. Did this requirement change along the way? I seem to remember only .ui_properties needed the NAS IP address while .ui_info needed to be 0.0.0.0?

  15. nh_ets's avatarnh_ets

    Installed the 4.6 Patters update (after deleting prior version) It runs, but then stops about 30 seconds later. What did I do wrong? Have been using the solution for at least a year but this is a new one for me….

    Reply
    1. Jay's avatarJay

      After installing the latest package version from the repo, it ran fine for a few hours, but now is constantly starting/stopping every few minutes. I’ve upgraded/fixed CP per the instructions here, but this is a new one. Anyone have any idea what to do?

      Reply
    2. jamesdeanreeves's avatarjamesdeanreeves

      I also installed the latest update from the repo. CP ran fine for a few hours, but now is constantly stopping/starting in a loop about every minute or two. Logs only says:
      4/28/16 11:16AM Crashplan started, version blah-blah
      4/28/16 11:16AM Backup scheduled to always run
      4/28/16 11:16AM [Phtotos] Starting backup to Crashplan Central: 2,660 files (blah-blah)
      4/28/16 11:17AM Stopping Crashplan
      4/28/16 11:18AM Crashplan started, version blah-blah

      And it does this ad-nauseum.

      I’ve fixed the crashplan upgrades many times over the years per instructions from here, so I know my settings are correct. I uninstalled the repo package first, then installed the new one. Nothing has changed on my client.

      Anyone have any ideas?

      Reply
      1. patters's avatarpatters Post author

        That’s usually caused by the backup set being larger than you can accommodate with the amount of RAM allocated. Try increasing the RAM allocation in /var/packages/CrashPlan/target/syno_package.vars or splitting the backup into multiple sets.

      2. jamesdeanreeves's avatarjamesdeanreeves

        Thanks, Patters.
        I saw you had mentioned that in the NOTES section – duh. I had forgot all about having that issue when I was using the smaller DS213 – hence the reason I upgraded to one with a replaceable DIMM. Looking at my current totals, it does look like I’m crossing that 2TB threshold you mention.

  16. Mike's avatarMike

    Hi Patters, thanks for the update. Please could you review the maximum open file count you set in the startup script? DSM 6 on my DS716+ has a higher default so the startup script is actually lowering it to 65536.

    cat /proc/sys/fs/file-max
    799360

    Perhaps you could check the current setting and only change it if lower?

    Reply
    1. patters's avatarpatters Post author

      If I reboot my NAS (DS214play) I get a value of 71146. Probably varies with model then. I’ll fix that in the next release.

      Reply
    1. patters's avatarpatters Post author

      Which model of NAS please? I have an ARMv5 and it is working so this is odd. Also the version of JNA that you are putting in there is newer than the actual one bundled with CrashPlan which isn’t ideal. CrashPlan uses JNA 4.1.0.

      Reply
      1. ianmdouglass's avatarianmdouglass

        Same here patters – i had to go back in and switch out the JNA to 4.2.2 to get it to work again. I’m using the 213J ARM version. Thanks so much for the development and hard work!

    2. Tom's avatarTom

      Thank you very much, this solves the issue with “Backup to Crashplan Central will take priority until complete (up to 24 hours)”.

      Reply
  17. Ian H's avatarIan H

    :-( Not working for me … DS215J
    Engine_Error.log:
    Exception in thread “W6683974_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
    at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:22)

    Reply
    1. Ian H's avatarIan H

      Yes – it’s working … followed these additional steps…
      Note – after starting … it seems to takea while to show it’s responding and allow client connections.

      10. Download: https://maven.java.net/content/repositories/releases/net/java/dev/jna/jna/4.2.2/jna-4.2.2.jar
      11. go to /var/packages/CrashPlan/target/bin and make a backup from jna.jar ( mv jna.jar jna.backup )
      12. rename the downloaded jna-4.2.2.jar to jna.jar
      13 copy the jna.jar you downloaded to the /var/packages/CrashPlan/target/bin directory
      14 start Crashplan
      15. check /var/packages/crashplan/.ui_info for a new guid when you can’t connect.

      Reply
    2. patters's avatarpatters Post author

      This could be a DSM 6.0 change for the models that use the ARMADA 375 SoC. These were always a bit weird because the SoC specs say they have NEON but on DSM 5.x their OS was always compiled without NEON support. So that I can fix the package, please can you run:
      uname -a
      cat /proc/cpuinfo

      Reply
      1. Luca Merega's avatarLuca

        Hi, uname -a
        Linux DEVNAS01 3.2.40 #7321 SMP Wed Mar 23 11:47:17 CST 2016 armv7l GNU/Linux synology_armada375_ds215j

        cat /proc/cpuinfo
        Processor : ARMv7 Processor rev 1 (v7l)
        processor : 0
        BogoMIPS : 1594.16

        processor : 1
        BogoMIPS : 1594.16

        Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
        CPU implementer : 0x41
        CPU architecture: 7
        CPU variant : 0x4
        CPU part : 0xc09
        CPU revision : 1

        Hardware : Marvell Armada-375 Board
        Revision : 0000
        Serial : 0000000000000000

        HTH

      2. bagu's avatarbagupremier

        Same problem and solution (jna update) so, here are my infos :
        Linux Nas 3.2.40 #7321 SMP Wed Mar 23 11:46:12 CST 2016 armv7l GNU/Linux synology_armadaxp_ds414

        Processor : Marvell PJ4Bv7 Processor rev 2 (v7l)
        processor : 0
        BogoMIPS : 1332.01

        processor : 1
        BogoMIPS : 1332.01

        Features : swp half thumb fastmult vfp edsp vfpv3 tls
        CPU implementer : 0x56
        CPU architecture: 7
        CPU variant : 0x2
        CPU part : 0x584
        CPU revision : 2

        Hardware : Marvell Armada XP Development Board
        Revision : 0000
        Serial : 0000000000000000

      3. Ian H's avatarIan H

        Here you go Patters …
        Linux NAS 3.2.40 #7321 SMP Wed Mar 23 11:47:17 CST 2016 armv7l GNU/Linux synology_armada375_ds215j

        Processor : ARMv7 Processor rev 1 (v7l)
        processor : 0
        BogoMIPS : 1594.16

        processor : 1
        BogoMIPS : 1594.16

        Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
        CPU implementer : 0x41
        CPU architecture: 7
        CPU variant : 0x4
        CPU part : 0xc09
        CPU revision : 1

        Hardware : Marvell Armada-375 Board
        Revision : 0000
        Serial : 0000000000000000

      4. Radek's avatarRadek

        Hi, I have identical problem with DS114 and latest DSM 6.0 update 3.
        uname -a
        armv7l GNU/Linux synology_armada370_114

        cat /proc/cpuinfo
        Processor : Marvell PJ4Bv7 Processor rev 1 (v7l)
        BogoMIPS : 1196.85
        Features : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16 tls
        CPU implementer : 0x56
        CPU architecture: 7
        CPU variant : 0x1
        CPU part : 0x581
        CPU revision : 1

        Hardware : Marvell Armada-370
        Revision : 0000
        Serial : 0000000000000000

        Many thanks for fixing this.

      5. Chrousto's avatarChrousto

        Hello patters, same here :

        admin@*******:~$ uname -a
        Linux *******3.2.40 #7321 SMP Mon Apr 18 19:27:41 CST 2016 armv7l GNU/Linux synology_armadaxp_ds414
        admin@******:~$ cat /proc/cpuinfo
        Processor : Marvell PJ4Bv7 Processor rev 2 (v7l)
        processor : 0
        BogoMIPS : 1332.01

        processor : 1
        BogoMIPS : 1332.01

        Features : swp half thumb fastmult vfp edsp vfpv3 tls
        CPU implementer : 0x56
        CPU architecture: 7
        CPU variant : 0x2
        CPU part : 0x584
        CPU revision : 2

        Hardware : Marvell Armada XP Development Board
        Revision : 0000
        Serial : 0000000000000000

  18. BGood's avatarBGood

    I have a DS412+ currently running DSM 5.2. I have Patters’ latest Java, but I haven’t yet installed his latest CrashPlan. Instead, I did the upgrade manually to get CrashPlan 4.6 working.

    I’m now considering upgrading to DSM 6, but only it it seems to be a low-risk proposition for Intel-based Synology units. So I have questions:

    *Is going to DSM 6 on Intel Synology devices fairly low risk in terms of keeping CrashPlan operational?
    *Should I run Patters’ CrashPlan upgrade first, and then upgrade to DSM 6 or upgrade to DSM 6 and then run Patters’ CrashPlan upgrade? (Does order even matter?)

    Reply
    1. BGood's avatarBGood

      FWIW, I “upgraded” my 4.6 (previously manually upgraded last week) to Patters 4.6 and confirmed CP was working. Then I upgraded to DSM 6. So far, everything appears to be running normally.

      Reply
  19. hal's avatarhal

    Question: I have upgraded my ds2123+ to dsm 6 update 3 and running lastest patters package. If i open the crashplan desktop (windows 10 desktop client 4.6.0) and kickoff a back, it finds files to back up but doesn’t upload them to crashplan unless I click the little “play” button (link to screen shot https://goo.gl/photos/ysXWpQxUvSGgVAp67).

    Anyone seen this? Solution?

    Thanks.

    Hal

    Reply
    1. hal's avatarhal

      update:
      1) I uninstalled java 7 and crashplan,
      2) rebooted,
      3) reinstalled java 7 and crashplan
      4) rebooted.

      same thing: scans but doesn’t update unless I push the play button on the desktop client (See picture link in original post above)

      Any insights would be appreciated.

      hal

      Reply
    2. hal's avatarhal

      It seems when the back up is kicked off by the crashplan process on my ds213+ it backs up the files (I’ve checked the history log and looked at what’s actually on the Crashplan site) . So it’s just some quirky behave between the desktop app and the process on the ds213+.

      The most important thing is that files are being backed up to the crashplan during automated runs.

      sorry for wasting space. ;-)

      hal

      Reply
  20. nh_ets's avatarnh_ets

    I am trying to get started, and went to update Java to 8. I downloaded the file off tinyurl as usual, and had to rename to match (it put april 2016 in the file name). In DSM it says it successfully installed, but when I click run, it still indicates stop. Not running. Tried a re-boot and repeated the process with a fresh oracle file. Any ideas?

    Reply
    1. patters's avatarpatters Post author

      If you rename the file it won’t work, as the contents are different. Please use the actual Java binary that the package asks for.

      Reply
      1. nh_ets's avatarnh_ets

        But then it gives me a message saying, “I was expecting……..”. So I change the name to what it was expecting. The download always adds the date to the file, and does not come in as a .gz but just a .zip

  21. Keith Weinheimer's avatarKeith Weinheimer

    been running DSM6 for a few weeks now, just updated to the new crashplan package and it now shows as running however logs show this messages from all clients

    Not ready for backup from . Reason: The destination is not available

    anyone else run into this?

    Reply
  22. Stephan's avatarStephan

    Thank you very much! With the lates update (0038 27/Apr/16) CrashPlan is working again on my Synology DS 216 play with DSM 6. Wunderfull!

    Reply
  23. stephanthierry's avatarstephanthierry

    I’m using a Syonlogy DS214SE, running Java 7 (ejre-7u75-fcs-b13-linux-arm-vfp-sflt-client_headless-18_dec_2014.tar) the CrashPlan engine starts (and keeps running now) and the client connect fine after changing GUIs. (The engine will not start when Jave 8 is installed)

    BUT after indexing 665GB files it gets stuck on:
    Waiting for backup
    Completed: 0MB
    Last backup: Initial backup not completed.
    The log files shows: “05/01/16 11:55AM [Default] Backup to CrashPlan Central will take priority until complete (up to 24 hours)” – this log entry is repeated with changing intervals.

    Who do you get it to snap-out-of-it and get started with the actual backup?

    Reply
    1. Jon's avatarJon

      Sounds almost identical to my problem. I also couldn’t get the server to start with Java 8.

      Reply
    2. stephanthierry's avatarstephanthierry

      Yes! Luca is right – his post:

      CrashPlan packages for Synology NAS


      Is the answer to this problem. I tried this method on the last release (4.5) and it had no effect, but on the 4.6 version it did the trick.

      I would recommend installing Midlight Commander – connection via Putty (or similar) starting midnight commander with the command “sudo mc” that will make the operation fairly painless.

      Reply
  24. Jon's avatarJon

    I am still having problems with the latest package on my DSM6.0 DS214+.

    I can get the server running on my NAS and connect to it from my desktop client, but it remains perpetually stuck on “Waiting for backup”.

    Any suggestions welcome!

    Reply
      1. Jon's avatarJon

        Yes, followed Luca’s instructions (actually as written by Chris Hines below) and I seem to be off and running again. Thanks for the help!

  25. aurelialabert's avataraurelialabert

    I have a more basic problem: There is no such file as /var/lib/crashplan/.ui_info in my installation. There is only one file, called .identity in that directory. Moreover, the Crashplan package stops after one minute or so after starting. This is my enviroment:

    Synology DS115j
    CPU: MARVELL Armada 370 88F6707
    RAM 256 MB
    OS: DSM 6.0-7321 Update 3
    Java SE Embedded 8 version 1.8.0_91-0039

    I tried to uninstall and reinstall the package, but the situation is the same. I am not able to find any information that could help me. Does anyone have an idea?

    Reply
  26. Chris Hinds's avatarChris Hinds

    I’ve been battling getting my DS214 with DSM 6.0 (automatically upgraded!) working again with CrashPlan. Up until now I’ve been using Patters’ Java 8 and Patters’ CrashPlan Package to make everything work but for some reason (love, money, whatever) I could not get CrashPlan to stay running. In the end I did the following, which I’m copying here in case it saves someone else a few days of frustration.

    1. Removed CrashPlan totally
    2. Removed Java8 totally
    3. Installed Java 8 from the Synology package under “Development Tools”
    4. Updated Java 8 using the latest package from Oracle (interestingly it’s not the same package as – full not embedded Java and also HardFP not SoftFP)
    5. Install CrashPlan Package
    6. Stop CrashPlan
    7. Download – https://maven.java.net/content/repositories/releases/net/java/dev/jna/jna/4.2.2/jna-4.2.2.jar (from the tips earlier)
    8. Copy downloaded file to \public
    9. SSH – cd /var/packages/CrashPlan/target/bin
    10. SSH – sudo mv jna.jar jna.backup
    11. SSH – sudo cp /volume1/public/jna-4.2.2.jar /var/packages/CrashPlan/target/bin/jna.jar
    12. Start CrashPlan
    13. SSH – cat /var/lib/crashplan/.ui_info ; echo

    After signing back in to my CrashPlan account and synchronising my backup is working again!

    Reply
  27. epilatow's avatarepilatow

    i have a DS213j and i was running crashplan successfully until the DSM 6.x update. since then i haven’t been able to get crashpan working.

    recently (past two weeks) i’ve tried with patter’s version of java (7 and 8) and the synology versions of java (7 and 8). I’ve also tried luca’s workaround from April 28, 2016 at 19:33 (replacing jna.jar) to no avail.

    Currently (with patter’s java ejdk-8u91-linux-arm-sflt and crashplan v4.6.0-0038), crashplan stops itself shortly after starting.

    I’m not having an upgrade problem (i’ve solved those in the past and i’ve tried uninstalling and re-installing the crashplan service). i’m also not having a gui/guid authentication problem (i’ve dealt with those issues in the past). I haven’t tried increasing up USR_MAX_HEAP since i’ve only got 320Gb of data on the unit.

    Looking in /var/packages/CrashPlan/target/log, the last log file to have been updated is engine_error.log and it contains:

    —8<—
    Exception in thread "Thread-1" com.code42.exception.DebugRuntimeException: Unable to persist ServiceModel, modelFilename=conf/service.model
    at com.backup42.service.model.ServiceModel.save(ServiceModel.java:337)
    at com.backup42.service.CPService.cleanup(CPService.java:2043)
    at com.backup42.service.CPService$1.run(CPService.java:427)
    Caused by: java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.JceSecurity
    at javax.crypto.Cipher.getInstance(Cipher.java:515)
    at com.code42.crypto.CipherPair.initCipher(CipherPair.java:77)
    at com.code42.crypto.Blowfish128Crypto.(Blowfish128Crypto.java:73)
    at com.code42.crypto.Blowfish128CryptoUtility$BlowfishCache.getInstance(Blowfish128CryptoUtility.java:147)
    at com.code42.crypto.Blowfish128CryptoUtility.encrypt(Blowfish128CryptoUtility.java:89)
    at com.code42.crypto.Blowfish128CryptoUtility.encryptObject(Blowfish128CryptoUtility.java:54)
    at com.backup42.service.model.ServiceModel.save(ServiceModel.java:334)
    … 2 more
    —8<—

    service.log.0 also contains a ton of stack traces, but the first one is:

    —8<—
    [05.01.16 19:55:17.097 WARN main kup42.service.model.ServiceModel] Unable to load ServiceModel, an old incompatible service model was found. Cleared the model and starting over., java.lang.ExceptionInInitializerError
    STACKTRACE:: java.lang.ExceptionInInitializerError
    at javax.crypto.Cipher.getInstance(Cipher.java:515)
    at com.code42.crypto.CipherPair.initCipher(CipherPair.java:77)
    at com.code42.crypto.Blowfish128Crypto.(Blowfish128Crypto.java:73)
    at com.code42.crypto.Blowfish128CryptoUtility$BlowfishCache.getInstance(Blowfish128CryptoUtility.java:147)
    at com.code42.crypto.Blowfish128CryptoUtility.decrypt(Blowfish128CryptoUtility.java:67)
    at com.code42.crypto.Blowfish128CryptoUtility.decryptObject(Blowfish128CryptoUtility.java:39)
    at com.backup42.service.model.ServiceModel.load(ServiceModel.java:405)
    at com.backup42.service.CPService.loadModel(CPService.java:1909)
    at com.backup42.service.CPService.start(CPService.java:554)
    at com.backup42.service.CPService.main(CPService.java:2260)
    Caused by: java.lang.SecurityException: Can not initialize cryptographic mechanism
    at javax.crypto.JceSecurity.(JceSecurity.java:89)
    … 10 more
    —8<—

    anyone have any ideas? My crashplan account is configured to use encryption, and given that these messages seem crypto related i'm wondering if that functionality is just broken in this software combo? (DSM 6.x, java 8, and crashplan 4.6)

    any advice would be greatly appreciated. cheers.

    Reply
      1. epilatow's avatarepilatow

        Woot! I don’t know what’s changed, but it does seem to be working now with patter’s latest java 7 package. And so ends 45.2 days without any backups. Whew…

      2. Scooper's avatarScooper

        Thanks for the tip.

        I also ran in the problem of Crashplan starting and without any notification stopping in the next few seconds. I use a Synology DS115j with Armada chip.

        My problem was solved by only following the next steps:
        1. Updated to 0038.
        2. Removed Java SE 8.
        3. Installed Java SE 7.

        It worked immediately! So no manual manipulation of files we’re required.

  28. hyperion's avatarhyperion

    I just think it’s great that Patters is keeping this alive. Thanks a bunch for your work! -hyp

    Reply
  29. Richard's avatarRichard

    Has anyone got Crashplan running on DSM 6 with an ARM5 processor? I’ve got a DS213.

    Reply
      1. Richard's avatarRichard

        Thanks Marc, I took the plunge and got mine working too.

        Awesome work Patters!

  30. BC's avatarBC

    Anybody seen this error in service.log before? I’ve already tried completely uninstall CP and Java8 and reinstalled them but still getting the same error.

    [05.02.16 14:32:42.546 INFO main com.backup42.service.CPService] **** END: SYSTEM PROPERTIES ****
    [05.02.16 14:32:42.547 INFO main com.code42.xml.XmlTool] XmlTool.factory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl@137ee0c
    [05.02.16 14:32:42.554 INFO main com.backup42.service.CPService] **** LOAD MODEL ****
    [05.02.16 14:32:42.771 INFO main com.backup42.service.CPService] Model valid for GUID 740667249879801109
    [05.02.16 14:32:43.312 ERROR main com.backup42.service.CPService] Error starting up, com.code42.exception.DebugRuntimeException: Unable to persist ServiceModel, modelFilename=conf/service.model
    STACKTRACE:: com.code42.exception.DebugRuntimeException: Unable to persist ServiceModel, modelFilename=conf/service.model
    at com.backup42.service.model.ServiceModel.save(ServiceModel.java:337)
    at com.backup42.service.CPService.loadModel(CPService.java:1970)
    at com.backup42.service.CPService.start(CPService.java:554)
    at com.backup42.service.CPService.main(CPService.java:2260)
    Caused by: java.lang.ExceptionInInitializerError
    at javax.crypto.Cipher.getInstance(Cipher.java:515)
    at com.code42.crypto.CipherPair.initCipher(CipherPair.java:77)
    at com.code42.crypto.Blowfish128Crypto.(Blowfish128Crypto.java:73)
    at com.code42.crypto.Blowfish128CryptoUtility$BlowfishCache.getInstance(Blowfish128CryptoUtility.java:147)
    at com.code42.crypto.Blowfish128CryptoUtility.encrypt(Blowfish128CryptoUtility.java:89)
    at com.code42.crypto.Blowfish128CryptoUtility.encryptObject(Blowfish128CryptoUtility.java:54)
    at com.backup42.service.model.ServiceModel.save(ServiceModel.java:334)
    … 3 more
    Caused by: java.lang.SecurityException: Can not initialize cryptographic mechanism
    at javax.crypto.JceSecurity.(JceSecurity.java:89)
    … 10 more
    Caused by: java.lang.SecurityException: Invalid signature file digest for Manifest main attributes
    at sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:284)
    at sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:238)
    at java.util.jar.JarVerifier.processEntry(JarVerifier.java:316)
    at java.util.jar.JarVerifier.update(JarVerifier.java:228)
    at java.util.jar.JarFile.initializeVerifier(JarFile.java:383)
    at java.util.jar.JarFile.getInputStream(JarFile.java:450)
    at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:301)
    at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:263)
    at javax.crypto.JceSecurity.access$000(JceSecurity.java:48)
    at javax.crypto.JceSecurity$1.run(JceSecurity.java:81)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.crypto.JceSecurity.(JceSecurity.java:78)
    … 10 more

    Reply
  31. Wouter van Straalen's avatarWouter van Straalen

    Perhaps I missed a step of the well written tutorial.
    Everything is working as expected, but in the client, the only files that I am able to backup are the files that are locally stored on my NAS. I cannot see the files on my client, the PC.

    Any help would be appreciated and if everything works as expected a donation will certainly follow!

    Reply
  32. wout's avatarwvanstraalen

    Followed the well-written tutorial step-by-step and everything seems to work.
    However, on the client side I can only see the local files on my NAS and not the files from my PC. Any thoughts on this?
    If it works out in the end I’ll make sure to donate

    Reply
  33. Chris's avatarChris

    Wondering if the update on May 16th is the native clients (non-Java) CrashPlan has been promising for so many years? In a recent meeting with their sales and engineering team they said that releasing a non-Java based native client was their #1 priority as many customers refuse to use a Java based client.

    Also, I just received an email “Update to Code42 CrashPlan End User License and Subscription Agreement” which states that they are changing their pro-rated refund policy. Possibly to stave off refunds for folks like myself that have 4 yr licenses and cancel after the client update?

    • Your refund rights, should you elect to cancel your subscription early, will change on May 15, 2016; however, existing customers will have the right to cancel and request a pro-rated refund through June 15, 2016. After June 15, 2016, your right to a pro-rated refund upon cancellation will be limited to specific circumstances. Should you elect to cancel your subscription before its expiration date, and unless you choose otherwise, your data will be available to you through expiration of your subscription term.

    Reply
    1. curby.net's avatarcurby.net

      Getting rid of Java would be SO AWESOME as long as they can support our platforms. Those of us on x86 Synologies should be fine, but I wonder if/how code42 will prioritize other architectures. I hate Java, but at least it allowed for better cross-architecture support.

      Reply
  34. Richard's avatarRichard

    Mine started giving the following error “Cancelling connection attempt due to ti
    meout – pending connection=PendingConnection” and nothing was getting upload. From the client it also looked like it wasn’t noticing new files being created in the folders it should have been watching. Stop and restart the service didn’t help.

    I dropped into the command line on the client and ran “backup.scan”. That kicked off a check and it noticed the new file and backed it up. Created two new files in another directory and it saw them right away.

    Reply
  35. AAron's avatarAAron

    I asked CrashPlan support about our questions around the upcoming “unsupported OS”. It appears to be an upgrade, and a client that auto-upgraded to CrashPlan v4.7 can’t backup to a NAS running the old CrashPlan v4.6. Looks like they are not trying to subvert/prevent the work of our life-long buddy Mr. Patters. We’ll probably lose our “v4.6 NAS to CrashPlan” support on May 16th and then until Patters (thanks!!) gets some time to work on it again.

    Support wrote:

    “We are always happy to see people with such passion for our product that they take it and use it in ways we didn’t intend, but we’ve always tried to be up-front about how doing so will move you outside the scope of our support. We do not have anything built-in to CrashPlan to specifically stop you from using it on a NAS, or a Raspberry Pi, or anything like that, but we also do not test for those scenarios and we are not responsible for whether or not an update will break an unsupported configuration.

    “Our 4.7 will break peer-to-peer in a specific way when it is rolled out on May 16th. Only supported devices should be automatically updated, but once a device is on 4.7, it cannot use a computer with CrashPlan 4.6 or below as a destination for a backup. You will still be able to use 4.6 and below to back up to a client running 4.7, but you can’t backup “downhill” so to speak. The reason this is the case is that we are introducing new security protocols in 4.7 to help keep your data even more secure.

    “As always, running CrashPlan on an unsupported configuration could put your backups at risk, but I’m sure you’re aware.

    “I’m glad you’re so passionate about CrashPlan. I hope I’ve adequately answered your questions.”

    Reply
  36. aadhoc78's avataraadhoc78

    Here’s an unofficial update from my CrashPlan support questions:

    “Version 4.3 and above should be able to connect to the cloud for the foreseeable future[…]”
    “While we are still working on a native client, we don’t have an ETA for when it will be released. Any 4.X release should still use Java.”
    “[…] the primary change for 4.7 is upgrading the peer-to-peer protocols to a new version […]”

    Reply
  37. dejan markovic's avatardejan markovic

    Hi,

    Today new upgrade (1435813200470_370.jar) on a fresh install.
    It looks like it delete from target folder lib and lang folders.

    Regards

    Reply
  38. beber75's avatarbeber75

    Hi,

    today a new update (1435813200470_370.jar) and it looks like it telete the lib and lang folder from target directory.

    Regards

    Reply

Leave a reply to Clarence Cancel reply