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.

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:

- 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:

- Now browse the Community section in Package Center to install CrashPlan:

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:

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:
- 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:
- 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

Hi Patters,
For your information, the “this affiliate link” does not work.
Kind regards,
Joachim
Yes unfortunately Google dropped the entire Affiliates programme some time last year, and CrashPlan never switched to a different affiliate plan.
Thanks for the package.
I am using the seed drive service from Crashplan, and just recieived my drive. When I open crashplan on my mac and select destinations, I can see the USB volumne mounted by my Synology NAS, but Crashplan reports that “the backup engine does not have access to the given location”.
I have made sure all users have permission to use this drive. What am I missing?
I just worked it out. I wasnt selecting a directory, just the volume. Sorry everyone!
I have this issue even though I’m selecting a folder. It is an archive brought from another Linux machine could it be file permissions?
Hello,
Everything used to work perfectly for few months. But now, the crashplan headless service on my Synology is at status “stopped”. And when I choose the menu “Action -> Run”, it dosen’t start the service (still at status “stopped”). Did you see this behavior before ??
Thanks for your help !
Roms
I am having the same problem on my DS713+. I wonder if it has to do with a DSM update?
+1, I have the same problem.
Try to use Java 7 instead Java 8. For me it worked.
I thought that you couldn’t use Java 7 with an Intel DS but lo and behold it works! Thanks so much.
Yes Synology fixed that issue with Java 7 when DSM 5.0 came out. I wouldn’t show it in the list of available packages on the repo if it didn’t work :)
I think the last DSM update killed it. I uninstalled Java 8, reinstalled Java 7 and it’s working again. Thanks!
Oops. I take that back. It ran for a while, then stopped again. The last update I had done was for the Transmission package. I stopped the Transmission package and Crashplan now stays running. As soon as I start Transmission, Crashplan stops again.
DS213 | DSM 5.0.443
Looks like my last comment got hidden below the fold. Wanted to make sure I got this to you for 414j support. Thanks again!
—–
Looks like the newest update for Java is now showing the version numbers in the log.
Here is the results from cat command:
http://pastebin.com/ifz8pR82
and from uname command:
http://pastebin.com/2tb9ZChL
If you need anything, else I’ll see what I can do. Thanks!
Regarding 414j support, I tried the overly simplistic tactic of downloading the package, executing ‘tar zvxpf ‘, editing INFO to add comcerto2k, ‘tar cvpzf INFO LICENSE package.tgz scripts’ and manually installing. Installation appears to succeed, but when trying to start the service, receiving the following:
DiskStation> ./scripts/start-stop-status.sh start
find: /volume1/@appstore/CrashPlan/upgrade: No such file or directory
./scripts/start-stop-status.sh: line 7: can’t create : nonexistent directory
-sh: /volume1/@appstore/CrashPlan/bin/CrashPlanEngine: not found
But it’s there:
DiskStation> ls -la /volume1/@appstore/CrashPlan/bin/
drwxr-xr-x 2 crashpla root 4096 Aug 17 18:10 .
drwxr-xr-x 3 crashpla root 4096 Aug 17 18:09 ..
-rwxr-xr-x 1 crashpla root 4771 Aug 17 18:10 CrashPlanEngine
-rwxr-xr-x 1 crashpla root 906921 Jun 3 2013 bash
-rwxr-xr-x 1 crashpla root 184958 Jun 3 2013 cpio
-rwxrwxrwx 1 crashpla root 972340 Jun 3 2013 jna-3.2.5.jar
-rwxr-xr-x 1 crashpla root 31756 Jun 3 2013 libffi.so.6
-rwxrwxr-x 1 crashpla root 126646 Jun 3 2013 libjtux.so
-rwxrwxr-x 1 crashpla root 44089 Jun 3 2013 nice
-rw-r–r– 1 crashpla root 620 Aug 17 18:10 run.conf
DiskStation> ls -la /var/packages/CrashPlan
drwxr-xr-x 3 root root 4096 Aug 17 18:09 .
drwxrwxrwx 8 root root 4096 Aug 17 18:09 ..
-rw-r–r– 1 root root 30316 Aug 17 17:51 INFO
–wxr-x— 1 root root 0 Aug 17 18:09 enabled
lrwxrwxrwx 1 root root 32 Aug 17 18:09 etc -> /usr/syno/etc/packages/CrashPlan
drwxrwxrwx 2 admin users 4096 Nov 26 2012 scripts
lrwxrwxrwx 1 root root 28 Aug 17 18:09 target -> /volume1/@appstore/CrashPlan
The current JavaSE packages appear to install properly and java runs on the 414j and its armv7, but the CrashPlan package is not flagged for this architecture yet. Patters, I would be happy to help with any testing that needs to be done on that architecture, as I have a 414j available.
Hello,
On my side, I de-installed the CrashPlan engine (from my Synology 214Play – Intel) + I installed java 7 instead of java 8 + I re-installed the CrashPlan engine + I made an adoption in CrashPlan (if not, CrashPlan was considering my Synology was a new one instead of the same as before de-installation/re-installation).
It worked few days. But now, the service is stopped, and when I click on Run, again it doesn’t launch it. Back to the initial problem…
Other strange issue : the client User interface on my PC (talking with the Synology backup engine), always crashes with a critical error, saying that it was disconnected from the backup engine.
Knowing that everything used to work fine during my first 2 month (I backed ip 400 GB !), I don’t understand which parameter changed to make these troubles happen.
The CrashPlan support doesn’t accept to support when it is a head-less version.
Is it the proper place here for these questions, or is there a specific Synology forum for CrashPlan ? (I found a section “Third-party Packages”, but no CrashPlan sub-section in it)
Thanks !
Just adding a last precision : I used the command line from the PC GUI (by double-clicking on the CrasPlan icon) and I typed the command : deauthorize (=> Deauthorize the computer. This completely disables the backup service and requires login to resume). Then it asked me to log-in (still in the PC GUI). May ba this commad is not compliant with the headless version and making that the backup engine forced to be stopped and can’t be restarted ???
Roms, this sounds like it could be a memmory issue. The bigger your backup set becomes, the greater the need for memory. Have you changed the default of 512mb in the settings? Then again, you should see OutOfMemmoryExceptions in the serverside-log if this does happen. Can’t remember of my head where its located, but it should be in a log-folder close to installed application.
Hello Bjorn, I feel like an idiot, but I can’t find /usr on my Sonology (the crashplan logs on Linux are supposed to be in /usr/local/crashplan/log, but I always navigate my NAS via File Station and this one doesn’t show me any /usr/local…).
Now I have PuTTY and I can navigate my Synology directories !
/usr/local exists, but not /usr/local/crashplan… Would anybody know were are the crashplan logs on Synology ??
Thanks !
I am away and cant check this, but you should be able to run the “find” command to find your file. Type this in the putty prompt, wihtout the outer qoutes: “find / -name “*.log” ”
In another words #find / -name “*.log”
This will find all files that ends with .log on your hard drive.
Thanks !
In case someone else need this information, the logs on Synology are there : /volume1/@appstore/CrashPlan/log
Will this package work on DS214air?
Im planning to upgrade my DS209 – model….
There has been a lot of activity and now the instructions that used to work don’t
My DS1010+ crashed and I had to do a restore and reinstall of DSM…I lost my Crashplan set up and configuration. Frustrating as I had not updated DSM for weeks/months as everythgin was work gin fine with the Crashplan headless application
So once I got the unit restored and set up I went about following the instructions
Added the source and saw the Java installs. Successfully downloaded the Java 8 install and ran and installed
But when I looked for Crashplan all I saw was CrashPlanProe. I tried that but this is setting up my device as a Crashplan server which is not what I want
I want to install the headless Crashplan client so I can continue my backup that had been working for the past several months and was 60% complete
Is there some new technique or source to install the Crashplan headless client or has this reverted to manual install and if so which one
I believe my unit it Intel Dual core 1.6 Ghz x86
Thanks for any help/guidance
Minor update – it showed up as Crashplan (not sure why it did not show up)
I installed it and it starts and then stops immediately
I have tried Java v7 and v6 (uninstall v8 tried v7, uninstall v7 and install v6)
Same response
Crashplan starts and then stops immediately
you will have to change the amount of Ram that Crashplan is using. The instructions that are posted lists where and what values depending on the unit and how much ram your synology has.
same issue here.. newest DSM.. DS713+.. it used to work, not anymore.. tried Java 6,7,8.. no success… crashplan log says it starts then stops.. tried adjusting memory settings file no success.. anyone? I can check all logfiles etc, but not sure what is the problem.. here is one logfile output (/volume1/@appstore/CrashPlan/log/engine_output.log)
[08.03.14 19:34:37.247 INFO main root ] Checking Java memory heap max.
[08.03.14 19:34:37.253 INFO main root ] Previous Java memory max heap size was 512
[08.03.14 19:34:37.263 INFO main root ] END Loading Configuration
jtux Loaded.
[08.03.14 19:34:43.082 INFO main root ] ***** STOPPING *****
[08.03.14 19:34:43.084 INFO Thread-0 root ] Stopping service…
[08.03.14 19:34:43.375 INFO Thread-0 root ] Selector shutting down…
update: it appears that some java process was hanging with a listening port 4243, and I found that by using netstat -tulpn | grep 4243 and was now able to start up the crashplan finally…
I tried the netstat command
netstat -tulpn | grep 4243
Ran with output
tcp 0 0 127.0.0.1:4243 0.0.0.0:* LISTEN 23730/java
Still no success
I also edited the memory in
/volume1/@appstore/CrashPlan/syno_package.vars
and increased to 1536 (I upgraded to 3Gb)
Still no avail
I can’t seem to grab the output log but essentially it says
Date/Time : Crashplan Started v3.6.3 GUID
Date/Time : Crashplan Syopped v3.6.3 GUID
The date and time are the same for all starts and stops
Thanks for any suggestions
The first time CrashPlan runs, it only accepts connections to the engine from the same host (127.0.0.1). My scripts edit this to 0.0.0.0 (allowing connections from all hosts), but I can only make this edit once the config file exists. The config gets created the first time it runs, that’s why CrashPlan must be launched twice before it works. This is explained in the notes on this page which I think a lot of people aren’t reading. Perhaps some of you are stopping and starting too quickly for that first run. Look in at the log in Package Center to confirm that it started the first time before you stop it.
If you somehow have an orphaned process listening only for requests from 127.0.0.1 then reboot your NAS and it should be fine after that.
Thanks patters – great work here and great support and guidance too which is greatly appreciated
I am embarrassed to say that a simple re-boot of the synology device solves the problem and it is now connecting and re-sync
One remaining question
Should I/Can I upgrade from Java v6 to Java v7 or Java v8
Thanks,
Glad to hear you’re back up and running. With the threat of that Synolocker malware, CrashPlan is a more relevant protection than ever.
Java 6 isn’t maintained any more so it’s a potential security risk, and 8 is too new for most applications, so I’d recommend Java 7.
I installed using Java v8 and later downgraded to v7 since I seen some people getting it to work on that but still it just run and die off by itself. i tried multiple times already. The logs just say starting up, load configuration, jtux loaded then it goes into stopping.
hi, that was my problem too! For some reason one of the java-processes from perhaps a different java version was still running, locking up the listening port for the Crashplan service.. see my reply a little bit up on this thread to solve your issue
Weirdly it just work suddenly after I did 2 reboots, no idea why though but I am not complaining.
Anyone tried to disble the service on the windows machine that you are using it as a client? like illustrated above?
“Once the engine is running, you can manage it by installing CrashPlan on another computer, and editing the file conf/ui.properties on that computer so that this line:
#serviceHost=127.0.0.1
is uncommented (by removing the hash symbol) and set to the IP address of your NAS, e.g.:
serviceHost=192.168.1.210
On Windows you can also disable the CrashPlan service if you will only use the client.”
The moment I disable the service it seems to be not able to access the service on the NAS. I double check the settings on the UI it seems to reflect the one in the NAS as well. Anyone seeing that?
I disabled the service on Win 8.1 Update 1 with no issues accessing my DS412+ afterward.
Some here, it’s keeping running and stopping by itself… Logs just say starting up, load configuration, then stopping….
Sometime it startworking for a while with no reason… I don’t know what to do… tested with java6, Java7 and java8
Thanks for a great tutorial! It was easy to follow, and I managed to get everything working smoothly with the CrashPlan backup.
However, in the process of setting this up, I have lost the possibility of external access to my DS213. I have an Airport Extreme, and it has worked perfectly fine in the past 1-2 years with the port forwarding. Previously, I have been able to both use the EZ-Internet, the Setup Router in Router configuration (in the Control panel), or doing it manually in the Airport Extreme (all have worked). Now, neither of these work despite many attempts and after several restarts of the Diskstation as well as the router. When trying to set up the port forwarding, it just goes into a waiting mode and sometime hangs, and sometimes comes back, but without being able to write the rules to the router.
I have not changed anything else except installing the CrashPlan packages, so it seems like this has caused some sort of conflict. Does anyone else recognize this? If I remove the Crashplan and Java packages, and then reinstall, will Crashplan central be able to pick up the image, or will I have to backup everything once again (took a month or two this time, but almost done now).
Please help, thanks in advance!
Bug Report; installed most recent versions as of today (Aug 10, 2014):
DSM 5.0-4493 Update 3 (14/7/19)
Java: ejdk-8u6-fcs-b23-linux-i586-12_jun_2014
CrashPlan 3.6.3-0027
> ps w
…
27732 crashpla 635m S N /volume1/@appstore/java8/ejdk1.8.0_06/linux_i586/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanServic
…
Truncates “CrashPlanService” as show above breaking both
/volume1/@appstore/CrashPlan/bin/CrashPlanEngine (at _findpid()) and
/var/packages/CrashPlan/scripts/start-stop-status.sh for status
What this looks like to the user is that after install the package is “stopped”, but it is in fact running. Package action “Stop” does not work, and “Start” may attempt to run multiple instances, not sure. Possible workaround: install package, let it run and initialize conf, then restart DSM. I have modified the broken scripts and it works for me and have not tested the workaround.
Thanks,
Michael
Thanks. I always thought that was a shoddy way of detecting the running process, but that’s actually the official CrashPlan script not mine. Currently I’m mid way through a total re-write to use a daemon script of my own instead.
Coud you plz tell me what have you done to fix this ? I’m having the same problem :(
You should be able to get around this by using Java 7 instead of Java 8 until I can release the new package version. The path to the Java 7 binary is not so long so the truncation of “CrashPlanService” won’t occur in the output of the ps command.
Thank you for your feedback, but i’ve tried all java versions from 6 to 8, no one is working :( I have no backup for 3 weeks :'( If someone can tell me how to fix the script?
I’m unable to start the Crashplan Package on my Synology. It’s immediately getting ‘stopped’. I’m unable to debug the issue. The following the versions I’m using:
DSM version: DSM 5.0-4493 Update 3
Java: Java SE Embedded 7 – 1.7.0_60-0027
Crashplan: 3.6.3-0027
To help analysing the bug, I’ve checked and like Michael Barrientos, the commande lunched is truncated:
ps w | grep -i crash
6776 crashpla 635m S N /volume1/@appstore/java8/ejdk1.8.0_06/linux_i586/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanServic
I managed to change the environnement (.profile in /root and /etc/profile) like this:
PATH=$PATH:/volume1/@appstore/java/bin # Synology Java Package
JAVA_HOME=/volume1/@appstore/java # Synology Java Package
CLASSPATH=.:/volume1/@appstore/java/lib # Synology Java Package
And I created a symlink in /volume1/@appstore like this:
DiskCraft> ls -all java
lrwxrwxrwx 1 root root 52 Aug 11 20:02 java -> /volume1/@appstore/java8/ejdk1.8.0_06/linux_i586/jre
Now my process is still truncated but it’s having more characters (as java path is shorter)
7566 crashpla 635m S N
/volume1/@appstore/java8/ejdk1.8.0_06/linux_i586/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=t
I can see the process running in DSM (It was’nt the case before the chage) but it’s still not backuping.
I’ve read the CrashPlanEngin script, and in my understanding the correct command should be something like :
/volume1/@appstore/java8/ejdk1.8.0_06/linux_i586/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Djava.io.tmpdir=/volume1/@tmp /volume1/@appstore/CrashPlan/lib/com.backup42.desktop.jar:/volume1/@appstore/CrashPlan/lang
Right?
I don’t why the command is truncated :'(
Plz help
Thank you for this great tutorial. I have, however, a question regarding access to the headless client with a local installation of the crashplan software: Crashplan is up and running on my Diskstation; ui.properties file modified according to description above. The software however does not connect, it only shows the local harddisk. Any hints?
[Update]
I had 2 problems:
– The first was because the long Java 8 path… I’ve fixed but my backup was still not working (even with java6 and java7).
– The second problem is that I was trying to adopt my old backup (and avoid to reupload 500Go of data)… When I triyed to adopt crashplan keept rebooting all the time… I don’t know if it’s a problem on crashplan server side, or synology side… Anyway I’ve started a whole new backup from scrach and it’s working now.
Hello,
Have the same problem. I own a DS412+ and installed Java 8 with the help of your packages. Then I installed Crashplan. When I want to run Crashplan it says immediately “Stopped”. So the package isn’t running.
I uninstalled Java 8 and installed Java 7 and reinstalled Crashplan. Same problem occures. When I SSH into the Synology I still see this in top:
/volume1/@appstore/java8/ejdk1.8.0_06/linux_i586/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=Crash
It still uses Java 8 instead of Java 7? Now I don’t know if this is the problem or not.
Is there some sort of manual to fix this?
@patters Or can you fix this and update the package? :-)
I have nearly finished a comprehensive overhaul of the package which will include DS414j support, will run as root to eliminate the need to re-do permissions every upgrade, and will target DSM 5.0 systems only. There have been a number of changes since the original package – libffi.so.6 is now included with DSM for instance, and Intel systems no longer need the glibc version-faking shim since DSM 5.0. This version will also fix the problems with the CrashPlan daemon wrapper script by using a much better start-stop-status script. Finally firewall settings will be pre-populated with a CrashPlan application entry for users that use the DSM firewall.
Unfortunately however on Thursday lightning struck a neighbour’s house which broke my phone and inexplicably killed the ethernet ports on my broadband router. Amazingly I still have functioning Internet via wifi, and have confirmed my NAS is still ok but I can’t get it online to test before I release. A new router is on its way, but it may take a week…
Hi Patters, great work! I was wondering, will this also clear up the issues with crashplan not working on a DS213+ (it keeps on disconnecting when approached through the desktop application and it seems to get stuck on certain files and therefore never progressing/finishing a backup set)?
I realise the 512MB memory limit is a problem with my backup size of ~800GB but I was hoping for a solution, e.g. through different memory stack usage. However, if this is fundamental problem, what DS (preferably 2-bay) would you recommend?
Thanks a lot!
How funny this is exactly the same issue i have since java 1.7.60 on my 213+. Neved had this problem before.
I’m unable to start the Crashplan Package on my Synology DS213+. It’s immediately getting ‘stopped’. I’m unable to debug the issue. The following the versions I’m using:
DSM version: DSM 5.0-4493 Update 3
Java: Java SE Embedded 7 – 1.7.0_60-0027
Crashplan: 3.6.3-0027
I would stop/ uninstall Crashplan, uninstall java 7, reinstall java, reinstall crashplan. That shall make it :)
Seriously, that worked for you? I have tried that many times but it doesn’t solve it for me…
I did the same thing to get it to work too no idea why.
>
I tried uninstalling and re-installing the packages..but it didn’t work for me!
DS411+II
Could only get CrashPlan working using v7 or Java. Is that normal? It just refused with v8.
Thanks
Maybe a strange thought but could we move this to some forum? Maybe on the Synology website? There’s extremely useful information, hints, bug-finding, etc.
Thank you for making a Synology package! This makes setting up Crashplan so much easier.
Like everyone I had problems getting my Synology to hibernate. In my setup I have several Crashplan clients which backup local files to Crashplan on my Synology (DS212j). Using the crontab in this setup is not an option because clients not active during certain times of the day.
I found the post by hammer useful but it still didn’t do the trick. Crashplan still reads default.service.xml every once in a while, preventing hibernation. To fix this I moved this file to /etc (which is in RAM) replacing it by a symbolic link pointing to the new location:
1. Move the default.service.xml file to the /etc directory:
mv /volume1/@appstore/CrashPlan/conf/default.service.xml /etc/
2. Make a symbolic link pointing to the file at the new location:
ln -s /etc/default.service.xml /volume1/@appstore/CrashPlan/conf/default.service.xml
3. Just to make sure change the ownership of the symbolic link to the Crashplan user:
chown -h crashplan:root /volume1/@appstore/CrashPlan/conf/default.service.xml
I hope this helps some of you. As said I also followed Hammers instructions. For the completeness of this post, these are his instructions:
1. Symlink “log/app.log to “/tmp” (tmpfs filesystem so the file will probably only be written to RAM) as the application occasionally updates “log/app.log” even when CrashPlan is doing nothing.
Run the following commands:
rm /volume1/@appstore/CrashPlan/log/app.log
ln -s /tmp/CrashPlan_app.log /volume1/@appstore/CrashPlan/log/app.log
chown -h crashplan:users /volume1/@appstore/CrashPlan/log/app.log
2. Edit “/volume1/@appstore/CrashPlan/conf/service.log.properties” to prevent “log/service.log.0″ to be written constantly with a lot of unneeded messages. Set all existing log-levels to WARN or OFF (see below).
3. On all backup sets: Disable “Advanced settings (Configure)” -> “Watch file system in real time”.
4. Mount volumes using noatime (http://forum.synology.com/wiki/index.php/Spindown_issues).
An alternative to 1. is to symlink “log/app.log” to “/dev/null” (ln -s /dev/null /volume1/@appstore/CrashPlan/log/app.log) but this creates error messages in the “log/service.log.0″. The errors can be muted by adding “log4j.logger.com.code42.logging.AppLogWriter = OFF” to “conf/service.log.properties”.
Here’s my complete “conf/service.log.properties”:
#############################
# Backup log.properties
# Code 42 Software, Inc. 2005
#############################
log4j.rootLogger=WARN
# Package Level modifications
log4j.logger.com.backup42.service.ui.UIServer.level = WARN
log4j.logger.com.backup42.service.ui.UIClientExitedCheck.level = OFF
log4j.logger.com.code42.backup.level = WARN
log4j.logger.com.code42.peer.level = WARN
log4j.logger.com.code42.peer.PeerConnector.level = WARN
log4j.logger.com.code42.peer.NATContinuation.level = WARN
log4j.logger.com.code42.os.level = WARN
log4j.logger.com.code42.io.level = WARN
log4j.logger.com.code42.event.level = WARN
log4j.logger.com.code42.messaging.level = WARN
log4j.logger.com.code42.nio.level = WARN
log4j.logger.com.code42.win32.level = WARN
#Only if symlinking app.log to /dev/null
#log4j.logger.com.code42.logging.AppLogWriter = OFF
I have a DS412+ and am running the Crashplan 3.6.3 on it. When I try to connect from my computer (a mac) the app runs for awhile before stopping with the error message “crashplan has been disconnected from the back up engine”. It seems that because of that it is not adding the new folders that I have added to the back up. When I log in to the Crashplan website and look at the files that can be restored, that folder isn’t listed there. Do you have any idea on what I can do to fix this.
Hi,
I have the same problem since a few days, although I didn’t change anything in Java or Crashplan packages… maybe the latest small upgrade from Synology?
Crashplan is constantly scanning and then indeed it the package stops and is restarted on my DS214play, disconnecting the PC client. Right now I stopped the package, completely useless.
I am considering uninstalling and reinstalling, but last time I did that a folder with ~ 600 Gb of data was removed from the backup, even though I recovered the previous settings! Had to do it again, took like a month…
I think I’ll wait for the next upgrade that is announced for soon!
I have a feeling Crashplan doesn’t like people using their soft on NAS…
Thanks in advance for your help if you have any insights!
Mine is Working great!
had to change the port also to 5000.
So now the hibernation problem is the only thing that remains?
Maybe a stupid suggestion? But isn’t it possible to shut crasplan of in the computer cliënt?
By Settings>Back-Up>Back-Up Will Run. And than configure whatever your need is?
Will this work?
Having the same problem. I’m constantly getting the “crashplan has been disconnected from the backup engine” after analyzing the folders. Recently upgraded my DSM to the latest version because of all the Synology hacks going on so I went ahead and upgraded Java to 7 and the latest package for CrashPlan.
@hulldini and @Fred : Guys, I had the same problem as you on my DS412+. First of all, look at your logs. For my case, I had actually 2 problemes:
– Crashplan was not showing as running in DSM because of the latest version of Java8. The path of java was too long… Solution, change the path of your java8 to something shorter via a symlink.
– After the first fixe, crashplan stucks scanning and restarting again and again… The problem is I was trying to adopt an old backup. I definitely didn’t found a solution… I just started a full new backup from scratch… And its works again.
I was doing the adoption to use an old backup originally. Did the same thing you suggested and started a new backup after I saw it was having issues but mine is still not working. Still doing its first scanning and then crashes as soon as that scan is done.
Well, I upgraded yesterday to latest version, DSM 5.0-4493 Update 4 (I guess I had Update 3 before) and it seems much better! I could backup new pictures without a problem. No idea if this is really the reason… but try latest upgrade!
But now crashplan crashes when trying to backup my video folder, it might be because a file is too big. I have seen that already, just removing it from the backup list solves it. Will try tonight…
Yes, same goes for me. Updated to update-4 and suddenly Crashplan started working as it always has. Strange but great! However, it would be good to understand the root cause to prevent future issues. Hopefully Patters can interpret the changes made in update-4 and link them to the issues described by so many people earlier. Cheers!
What I found out so far… The CrashPlan(PROe) Client stops because the directory /tmp/@tmp is missing (as shown in one of the logs of the CrashPlan Client itself). After manually creating that folder (mkdir /tmp/@tmp) and changing the privileges (chmod 0777 /tmp/@tmp) the client is working without problems. I had this problem twice on new Synology (DS1813+ and DS412+) and as I remember it was a problem starting (only with fresh installs so far) with the update-3 (but I am not quite sure about that).
Well, unfortunately mine still crashes after a while :'(
(although there was definitely an improvement after upgrade)
I have 2 backup sets, one with high priority with smaller documents and one with low priority with videos. It seems to crash on the second one, while scanning a small file.
Now I had to redo this part during the last month or so (~600 Gb) so I really wouldn’t want to uninstall and start from scratch – again – as people above mention was the only solution :(
Waiting for the next crashplan upgrade then… Thanks in advance, Patters!
Dear all
Thanks for the great package, been using it for one year without too many hickups.
Since DSM 5.0-4493 v4 upgrade, a few days ago, my Crashplan 3.6.3-0027 (green) has frozen.
I can see this from the GUI.
What I mean by this, is I have a connection to CP central, but the upload is stuck. (Pause is off)
Just to check, I moved the first file where it was stuck, just in case it was a problem file, no joy.
Logs don’t say anything…
I have Java 8 installed, everything was fine until I updated DSM.
Has anyone got the same problem, can anyone give any helpful advice.
Cheers Mala
Have you tried using Java 7 instead?
Just had one more issue which I solved
Crashplan was running, but when in the GUI, GUI disconnects at 460GB
Re opening the GUI starts the scan from scratch, and closes always before or at 460GB
Solution: I took some of the folders out of the backup to see if there were too many jobs.
After doing this, my GUI scan progressed to the end, and Crashplan is now backing up.
I will now add folders bit by bit.
Thank you all
Unfortunately, Crashplan has suddenly stopped again, after running many days without a problem. I would be very curious what the root cause is to this problem as it seems quite random. Is it linked to the total size stored at Crashplan (are the actively changing/sabotaging stuff at their end to prevent big backup sets?), is it linked to filenames/paths? Because I really don’t understand why it runs perfectly for so many days and then suddenly, without anything changed that I know of, suddenly drops and refuses to start properly again.
Patters, can you explain this, as you have the needed in-depth knowledge? Would be great to understand it! Thanks.
DS213+ | DSM 5.0-4493 Update 4
@olije same here, it stops yesterday without any changes from my part :( Don’t know why…
Do a search in this community for heap size. I suspect, like a lot of problems, it is due to the fact that when CrashPlan installs on the Synology the heap can been to low for the amount of files being backed up.
You can think of heap as memory that is used to keep a list of things to do. In this case it is a list of files to be backed up. If the heap is small then memory runs out and CrashPlan stops. If the heap is large enough then there is enough space for that list and any work/list/data that Java requires.
The Synology I have is the 1512+ and I bought that because it could be upgraded to 3 GB of memory. Currently I am backup up 4.7 TB of data without a glitch. I would also say that I add about 12 GB of data ever week (I have some action cams and have kids and ride a motor bike, so there is lots of stuff I want to keep).
I have 10 TB of disk currently and have had my system for over a year now (all data has been backed up and usually takes about a day if I had a bunch more video). I know what you are looking for is here it is just a matter of looking through the posts. As well there are lots of good people here that have made tones of suggestions and replies, including Patters.
Thanks, Shane for your reply. What you’re basically saying is that a DS213+ (and many other similar diskstations) are just not fit for running backups like this, since the memory can not be expanded. That would mean spending a lot more money ~($1000) on a diskstation and HDD’s, which would leave me with an overkill compared with what I need.
What still puzzles me though, is that after Update 4 my backup suddenly started running again and backed up many 1000’s of files more before crashing again. This would suggest that in Update 4 something was changed that positively affected the allowed heap size or other way of memory management in my DS213+. And that is exactly the kind of ‘root causes’ I would like to understand from highly skilled guys like Patters as this could potentially point towards solutions for the lower-spec diskstations. A workaround, of course, would be for Synology to enable memory upgrades for these lower spec machines. Cheers.
Memory seems to be a recurring problem. My DS411+II is backing up 8 TB of data, so I split this into 6 separate backup sets, reducing the concurrent memory requirement for CrashPlan.
The NAS powers on at 8 am and off again at 11 pm (except fri & sat, where it runs 24/7).
My backups run all the time, and verifies the selection once every day at 8 am.
Another user (sorry, can’t remember the name right now) had an excellent post about Advanced Settings. The only setting that changes between my sets, is the “Data de-duplication” setting. The remainder is always Compression=off, Encryption=on, Watch=off, OpenFiles=on.
Hi, try it with Java 7 as Patters also suggested. As stated before, my Crashplan stopped working some months ago, but all is working perfectly again since I installed Update-4 of 5.0-4493. As I am using Java 7, hopefully this will also work for you. It really is great that it works again. Great work Patters, code42 should be very happy with you, as undoubtedly many people use Crashplan only because you have enabled the headless use of it!
Thanks for the advice, I installed Java 7 as suggested, everything is working after the following alterations.
I also applied some Java RAM allocation fixes which I had missed as 512MB seemed to be causing problems according to forums,
/volume1/@appstore/CrashPlan/syno_package.vars – USR_MAX_HEAP=1536M
/volume1/@appstore/CrashPlan/bin/run.conf – SRV_JAVA_OPTS – Xmx512m
/volume1/@appstore/CrashPlan/bin/run.conf – GUI_JAVA_OPTS – Xmx1536m
I have already had the max ram installed 3072 MB.
Now I can see my server again
I edited “C:\Program Files\CrashPlan\conf\ui.properties” text file, and put in the IP address of my Synology “serviceHost=x.x.x.x”
Are there any plannings to support DS414j (Mindspeed Comcerto 2000 ARMv7)?
I’m working on it yes. I have had very little time though so it’s still in progress.
Patters, FYI – I just returned from VMworld where I managed to spend time with both the Synology and Code42 folks. They’re both well aware of your work and said that they heard from plenty of other attendees that we’re all using your work.
Unfortunately, Code42 has no plans to support headless operations for Crashplan (at least none that they would talk about) and Synology’s hands are tied. The Synology folks in particular were very thankful that you’re doing this work and helping their customers take advantage of Crashplan, even though Code42 doesn’t support it.
Thanks as always for all the great work!
Well, if you think of it, Code42 has absolutely no interest for Crashplan to work on NAS… if it’s installed on a personal computer, usually the disks are smaller than 1 Tb, especially now with SSD. And to my knowledge, it’s not possible to backup an external hard drive (they claim it’s a technical problem, but I’m not sure I believe that…)
When on a NAS, it’s usual to have 4 Tb of data, on a machine that is on 24/7 and can backup constantly… bad deal for them as backup size is illimited! ;)
Why does everyone seem to ignore backing up to ‘Friends’. Almost always faster than backing up to ‘Crashplan Cloud’.
Not necessarily, depends on their cost side. Moreover, I doubt people would join Crashplan if you could only backup from or via your PC. I wouldn’t because I have all my relevant data on the DS and definitely do not want my PC on 24/7 only to enable the possibility for backups. Therefore I think code42 should actually actively market this opportunity with a good value proposition. I would even be willing to pay a bit more or otherwise have some kind of limit or differentiated plans. And last but not least, looking a few years ahead, the (private) cloud is here to stay and expand, so $/TB will also rapidly decrease, making e.g. 4 TB not such a big deal…
@Fred: I have several TB on my NAS that I would like an *external* backup of.
Remember that RAID redundancy is not a backup, e.g.: http://www.cnet.com/how-to/digital-storage-basics-part-3-backup-vs-redundancy/
I therefore have an unlimited Family package and would most likely use an official Crashplan client, if available.
@Aj: backing up to ‘Friends’ is a nice option, but I don’t have any friends with several TB of free space that I may use for my own purposes and vice-versa. I think the ‘Friends’ option is good, but for smaller backups, i.e. I’d more likely to have a few GBs to spare than TBs
IMO, you don’t “spare” space for your friends and neither do they for you. You buy the harddrives needed and install them in your friend’s machine.
My dad and I do that. Half of the disks in my Synology are mine, the other his for his backup. If one of those disks needs to be replaced, he buys it. Same with my disks in his machine…
I have a friend on the East Coast (I am on the West Coast to be don’t share earthquakes or super storms), and we back up to each other. I have second backup at a friend’s in Los Angeles, a backup that was seeded.
While it sounds like a good (and probably also a fast) option, and a great way to spread risk, it’s simply not for me. I don’t have spare room for other peoples disks, nor room for other peoples data. I therefore chose to backup to CrashPlan Central. Problem solved.
Thanks for enabling headless
I am just wondering if most of the stability problems are with [Crashplan – vanilla Green]
I see few posts mentioning PRO or PROe
Does anyone know if the upload speeds are greater with PRO or PROe
I am not a business, but PROe still offers great value.
Do Crashplan offer discounts on other accounts like they do for Crashplan Green?
Thank you
@olije same here, it stops yesterday without any changes from my part :( Don’t know why…
Does Crashplan not start for anyone else on DSM 5.0-4493 Update 4 with Java 1.8.0_6-0027
and Crashplan 3.6.3-0027?
Everything installs but crashplan doesn’t run. It used to run before on previous versions.
First thank you very much for this package! I would like to exclude the @eaDir and all sub folders / files from being backed up. I think it will greatly reduce the number of files and thus help with some of my memory issues. I have a 1512+ with 3GB of RAM and USR_MAX_HEAP=1536M which is working but still it is really not necessary for me to backup all the thumbnails. Problem is I am NOT REGEX savvy. Here is what I have in my exclude list.
THUMB_B.jpg
THUMB_L.jpg
THUMB_M.jpg
THUMB_S.jpg
THUMB_XL.jpg
*/@eaDir*
I thought the */@eaDir* would exclude do it, but this does not seem to be working. I built this list a while ago. Looks like there have been updates either with DSM 5 or PhotoStation that have changed from the THUMB_*.jpg I can probably add another exclusion for the SYNOPHOTO THUMB PREVIEW.jpg. But it will still build out the folder structure under the @eaDir.
I added my exclusions through the GUI, and just wrote them as they are (the last one being temporary files for Chrome downloads):
Thumbs.db
dekstop.ini
@eaDir
#recycle
.crdownload
Just to let you know that I changed my USR_MAX_HEAP value from 512M to 1024M and Crashplan started working again.
Well after thinking I had things working, the GUI started crashing again.
I found a 64 bit version of the Crashplan client, so “in for a penny, in for a pound” I upgraded.
BIG MISTAKE, I tried to do a restore as suggested by crashplan before computer adoption (didn’t work). I adopted My DS, somehow the backup was lost for the second time with CP.
I don’t like the way adoption works, I have never managed it without losing my backups.
So what now? Well I cannot see my DS any more in the GUI, I checked everything, Telnet, ports, firewall, nothing works, but my DS is available in my network
Conclusion… I’m beat for once, I am giving up with CP.
Do what I did and save yourself a ton of headaches…I purchased a used MAC Mini on ebay for a few hundred dollars. It can be set up to auto mount all your DS volumes. Backing us a DS via the Mac is officially supported by CP. It worked perfectly and backed up quicker than via the DS alone.
So much easier and reliable. So happy I did this and now my DS remains 100% backed up.
Let me know if you have any questions.
Hi David,
Sounds like a nice workaround although it partly defies the solution of having one single, low power consumption unit as your central storage with all its inherent possibilities. It might be more worthwhile spending the few hundred dollars on an upgrade towards a DS1513+, which seems to have sufficient memory (after max upgrade) to work well. What do you think?
BTW, which MAC OS should I be looking for, should I want to move in this direction? I have seen some MAC mini’s for ~$150, but they run Tiger, which does not work with CP anymore.
Cheers!
Why do that? It is really easy to get a Synology unit to run Crashplan.
Also, if you get an “cheap” Mac Mini, and it isn’t able to run 10.9 or anywhere close, you can always stick Ubuntu Linux on it…..
Haha, if it’s “really easy”, I could really use some pointers per my Sept 7th post. :)
Hi olije,
I am using a 1513+ and was having the same issue that everyone else is. It seemed that I spent more time trying to get CP to work than it actually spent working. I got a Mini that is running OSx 10.8 and it works perfectly. I was so tired of having to fix CP on the DS, and this way, it just works. Always. Reliable and fast.
Plus, now that my large backup is complete and I am down only to small daily backups, I will schedule it to run only at night and the remainder of the time, I may use it as the computer connected to my TV – to run Skype and watch the DVDs and Blurays I have ripped to my DS.
Hope that helps!
Hi David,
Thanks for you answer. Really surprises me that even with a 1513+ there is trouble. I was contemplating buying one but now I’m cured of that option. But what I’m curious about is why you have the 1513+ in the first place then. Is it sheer storage room? You might as well work with a few USB HDD’s plugged in, a lot cheaper!
What you clearly illustrate is actually the root cause of all the discussions here. Despite the good work from Patters, CP is still a DIY kit that needs a lot of attention and maintenance. As posted earlier, I think they would be very wise to make an official, well working package for the Synology diskstations. Anyhow, I’ll keep the Mac option in mind although I find it pretty expensive. Might as well start backing up to Amazon S3 or HiDrive. I also found IDrive which I used a long time ago from my PC. Not too bad pricing @ $47,-/year for 1 TB. Would be enough for me for the near future. Unfortunately as one of the few, they don’t support de DS213+ (1513+ is however).
I’ll need to keep on pondering on a solution…
Cheers!
Hi Olije,
Yes, it is not the easiest solution, but it certainly is one of the least expensive. I decided to go with the 1513+ for volume. I realize I could have gone with the less expensive box and add USB drives, but I like having everything enclosed in one box as well as the beefier hardware.
I am sticking with CP because of the unlimited storage space, plus, we purchased a family plan to back up the entire family, so for the cost, it can’t be beat. Plus, with the Mac Mini option, it is super easy and reliable.
As I mentioned, I also plan to use the Mini as a home theater PC, so I will certainly get my use out of it.
Good luck finding what works best for you!
My 213+ was doing great for a while, but now – no matter what I do, I get an out of memory error…
I’ve edited the XMX and the user settings in the synoresouce to try and give CP more memory, but anytime I go over the base amount the Crashplan client can’t connect.
My backup set is about 600Gb.
Any ideas?
Yeah, same here. Very frustrating!
As pointed out several times on this page by several users, the main problem seems to be the memory overflowing. Apparently it can even (yet less frequently) happen to systems with e.g. 2 or 3 GB of memory.
Therefore, what I would really like to plea for is solving the FUNDAMENTAL issue of memory overflowing. Without exactly knowing how the software works (and risking nonsense in the next sentences), I could imagine the application monitoring memory usage and at a certain level either clearing out unneeded information or writing the data to a temp file for later use. In other words, PREVENT the memory from overflowing, no matter how much memory is available. Or if CP prevents this way of working, perhaps backup a set in smaller chunks (e.g. max 10k files or max 5 GB per chunk).
PATTERS, would be great if you could comment on this layman approach of mine. I really would like to understand the fundamentals of this recurring problem. As I am up for renewal of CP in a couple of months I am curious whether this problem is structural or not. If so, I will drop the use of CP and try to find a different solution, although with regret…
I second your call for help!!! I am also willing to PAY PATTERS for a more stable package and support.
I already donated via Paypal a couple of weeks ago (when CP was still working :-S)
My Crashplan starts and stops as well. I found I have hundreds of restart logs containing this:
Starting CrashPlan Engine … Using standard startup
./CrashPlanEngine: line 17: ./../CrashPlanEngine.pid: Permission denied
OK
A directory permissions issue? How can I tell what user is executing the CrashPlanEngine script?
Thanks patters for your work, quick question:
How does this actually work in practice? Does my PC back up to my NAS, and my NAS is the only direct connection to CrashPlan? If so, would this mean that my whole family could back up to the NAS and yet I’d only need to purchase a CP license for my NAS?
Every time I upgrade dsm do I need to reinstall the java manager package or only the java version?
Not any of those for the recent DSM 5x updates, but I remember having to install the java version once (don’t remember the details though). In fact, CP has been impressively stable for me for months. If you drag the Control Panel and Package Center to the DSM desktop, it will be easy to check if all packages are running after each update.
I’ve edited /volume1/@appstore/CrashPlan/syno_package.vars to 1024M but Crashplan still starts and stops immediately. Any ideas of what I might try?
Do you know when the version of CrashPlan for Synology will be available? I am trying to decide to wait it out or manually revert the DSM firmware. Thank you so much for this program. It has been great to have direct back on Synology.
TJ
I too have the same problem. Crashplan starts and stops.
I ‘ have 2.2 to backup and one ds214 with 512kb of ram.
Is it of in a problem of ram? or I have the impression that I have the problem since the update 5 of the dsm 5.0
Sorry for my english
Thank you google translate
2.2TB to backup and only 512MB of RAM will be a problem. How many files are in that backup set? With such a low amount of memory, You should reduce the number of files per job to < 50.000. Check the advanced settings and set the dedup and compression settings to "auto".
First of all: Thanks Paters for Your work.
The package is working great.
We have nearly twenty customers with Synology-NAS systems running patters package and I have seen most of all problems, mentioned here.
Most of them can be solved by:
– use Synology machines with Atom-CPUs (especially with larger backup sets)
– maximize RAM of the Synology (especially with large backup sets)
– modify the synology_install_vars file to use 1024MB or more of memory.
– Split the backups in multiple jobs, I always try to keep the number of files per job to less than 100.000 Files.
– big files (especially movies) should be done in an own job and disable the compression and deduplication (with highly compressed movies there won`t be much loss and the cpu and ran usage of the CrashPlan application decreases a lot
– After each DSM-update, first check, if the Java Manager is up-to-date and the installed Java is up-to-date.
– Stay a Java 7, this is working great.
– if something isn’t working (wrong ownership-errors, etc.), uninstall the package, check that the complete app folder on /volume1/@appstore/CrashPlan(PROe) is deleted. Also delete the CrashPlan-user in the user settings of the Synology. Re-Install the package and do as told (wait a few seconds after Installation and stop the package, then start it again).
one addition: check the log-files of CrashPlan (/volume1/@appstore/CrashPlan(PROe)/logs
Check the service.log.0 and the engine_output.log. CrashPlan tells a lot about problems in the different log files. A problem with ownership of the “CrashPlan.pid” file in most of the times is caused by “manual changing of ownerships”. Uninstall the package and reinstall it.
Thanks for sharing your experience. So, if I were to sell my 213+ and buy a 214play instead, you reckon my problems with CP would be solved? FYI: my backupsets are smaller than 100k files and I have no huge video’s in that backup.Total backup size approx 800GB.
Hi olije,
I can`t tell definitely with an 214play, because our customers are using DS411+II and up, but looking at the technical details of the the 214play, it should be at the same performance level as the DS411+II. The customer using the 411+II is saving about 750GB mit about 500.000 Files of different kinds. We split up the jobs to 5 or 6 backup sets, this way it is working without problems.
My crashplan does not work. Synology 213+, DSM 5.0. Backup of 420 GB. It stopped working after installation of DSM Update 4, and Update 5 did not help, neither changed anything. I tried different Java packages – with 8 Crashplan shows “Stopped”, with 6 and 7 it is running, but apparently restarting – I see row of mountains in CPU Resourse Monitor (peaks 60-70%, then falls to 3-4%). I am trying to make it run for 2 weeks now, tried a few dozens restarts, uninstalled and reinstalled both Java and Crashplan for about 10 times, changed Max Heap size to 1024M. Logs don’t show anything strange, engine log fnds with “jtux loaded”. Engine_crash log is empty.
The only thing I can think about is a cut line of Java command that is truncated:
DiskStation> ps -w |grep crash
21532 crashpla 1151m S N /volume1/@appstore/java7/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPla
21781 root 4716 S grep crash
I can’t understand what the hell is with that program. Maybe someone can help me, PLEASE!!!!!!
Have You had a look on the CrashPlan logfiles inside the CrashPlan directory? Check the service.log.0 of CrashPlan.
How many files do You backup? Reduce the number of files per job to < 100.000, less is better.
Hate to sound dumb – but how does one split up the backup into separate jobs?
OecherWolke,
I checked this log – can’t understand everything, but there are two repeating WARN lines:
1) [09.19.14 20:08:00.820 WARN main com.backup42.service.ComputerUniqueId ] Unable to store computer identity. null, com.code42.exception.DebugRuntimeException
com.code42.exception.DebugRuntimeException
2) [09.20.14 16:22:11.156 WARN BWQ-Security::-0_655 de42.messaging.security.SecurityProvider] SP:: GeneralSecurityException: finalizeExchange, remote client likely has an invalid PbK. Closing session. Session[id=655096815588737380, closed=false, isLocal=true……….
I have no idea how this can be solved.
And thanks for advice – now I have at least some information.
Serg
Matt, just open the settings in CrashPlan -> Backup, there is a button to activate backup sets or something like that.
Hi Serg,
never seen that messages before. Which version of CrashPlan are You using? CrashPlan, Pro or PROe?
The first message looks like the GUID of Your CrashPlan can’t be stored.
Please connect via ssh to the Synology and check the folder /volume1/@appstore/CrashPlan/cache
If this folder is empty, it looks like a problem with privileges.
The second part looks like, the connection to the CrashPlan-Server can’t be established because of an invalid key (or maybe the missing GUID from part 1).
I would send these error to Your CrashPlan-Support. Just tell them, Your are using a Linux-machine and can`t connect to the server.
Was CrashPlan able to run at any time at Your Synology? Are You using a firewall which maybe blocks outgoing TCP-traffic at the Ports 4280-4286?
I too have a 213+ and it’s working fine – so it is possible.
My setup:
DSM5 – Update 4 (haven’t tried 5 yet)
CrashPlan: 3.6.3-0027
Java SE 7: 1.7.0_60-0026
I hope someone can help. I upgraded Synology to DMS5.0, subsequent to which I uninstalled Crashplan, reinstalled Java 7 and Crashplan. I pointed crashplan to the existing instance “Diskstation” when prompted in crashplan itself. From the client I can see “Diskstation” with a green (active) circle, but it says “Diskstation is unavailable – backup location is not accessible”. Likewise, or similarly, from the headless server the crashplan log file says “not read for backup from macbook pro. Reason: the backup location is no accessible”.
Any thoughts anyone?
have you adopted your previous backup via the frontend interface? That’s always necessary after reinstalling CP. Hope this helps. Cheers.
the adoption is indeed required if you have reinstalled crashplan…
I think I’ve found a wait to avoid all the misery of reinstalling CP and adopting it. It did work the last 2 DSM updates.
– Stop Crashplan
– Uninstall Java 7 BEFORE the DSM update
– update DSM
– Reinstall Java 7 again
– restart Crashplan
Works for me…
Thanks BertXL for your suggestions. However, my conclusion from everything I read here is that ultimately it doesn’t really matter which procedure you follow. Sooner or later the backup will crash. That is because the ROOT CAUSE is not properly understood by anyone as to yet. Everything points towards memory overflow but it is unclear if that is caused by the number of files, the type of files, the size of files, the size of the entire set or some combination of these. So, again, what is really needed is a FUNDAMENTAL understanding of how CP works and to program algorithms that STRUCTURALLY prevent any overflow, no matter the configuration or backup size. See my earlier ‘layman’ approach on this somewhere up on this page. And that is where experts like PATTERS come in but I reckon he is very busy as I have seen no comments from him for the last weeks. We’ll need to have some patience.
yes I have via the Crashplan interface and that seemed to be all fine. So unfortunately it must be another issue I think…
problem solved! Somehow the crashplan folders “owner” was set to another “user”, so i changed the user back to “crashplan”, and made sure all changes were applied to sub-folders.
Will be interested to see how long that will last. Let us know in a few days if CP still works.
Hello guys,
Just to let you know, I just updated my Syno 411+ to DSM 5.0-4493 Update 5. And all is fine.
I have just stopped Crashplan package, uninstalled Java, updated DSM, installed new Java, started Crashplan package.
All is fine.
Cheers! Flavio Endo
Hi Patters and Community!
I have been a user of this package for several years now and love it! Thank you for creating such a great package!
Here is my issue:
-Recently added a good amount of data to backup and it was working great.
-I updated a bunch of my photos with some metadata which triggered a lot of data for crashplan to update.
-Seemed to be working fine, until this morning (the next day) I noticed that it was apparently “frozen” mid-upload of a photo. I can still click around in the app but the backup is stopped.
-Looking at resource monitor, the java package had about 300MB memory used and 0 CPU activity, with a status of sleeping.
Here are some additional facts and troubleshooting:
-I increased the heap size from 512 to 1024. Would this not reasonably fix a memory issue if it was using 512 previously? (to the best of my knowledge I had not updated it previously, and when checking, it showed as 512)
-my backup was approximately 1TB with maybe 200K files before the new 360GB of files (started using a gopro, just got back from my honeymoon where we used 2 of them!) was added.
-even after adding, i did not see any issues until the update of a large amount of metadata across many of my pictures (not sure if this is what is causing the issue, but the only thing I can point to that changed significantly).
-I also changed how my files are backed up in sets, taking a large chunk comprised of videos and putting that in a separate set from my photos. For reference:
Set 1: Photos – 900GB
Set 2: Video – 250GB
Set 3: Everything else – 100GB
-I removed the video backup set to reduce the size and that did not make a difference, even with increased heap size.
-I feel like I have tried to do every possible route to diagnose and fix this issue. If there is anything you can do to help me fix this that would be great! I am now considering building a freenas box and selling the DS413 as I think there may be some more flexibility to upgrade any hardwear I want (and use plex with transcoding, hibernation, etc)
Thank you!!
Update, not sure if CP worked something out on its own, but it appears to be working now. I think the heap size increase is what helped. I confirmed that the change is holding by using “java mx” which returns 1024. Maybe it just needed some time to work through the re-sync after i uninstalled. Still feel like I will reach a limitation with this setup again down the line so I am contemplating doing a freeNAS box still, but for now, it appears that we are good.
Uninstalling Java 7 prior to installing the update worked!!! Just reinstalled and CrashPlan is back up and working.