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
PC LOAD LETTER 
Upload speed?
Hi, I have 10Mb/s upload at home,
but Crashplan from Sinology is uploading to CrashplanCentral at 700 kb/s :(
Is there anything I should tune it?
*When I use crash plan from a desktop machine uploading to CrashPlanCentral it uploads at 8Mb/s…
Thanks.
There is a support article here
https://support.code42.com/CrashPlan/Latest/Configuring/Speeding_Up_Your_Backup
If I remember correct I just turned of compression and everything ran much faster,
Hi,
Crashplan was stopped on my DS1010. I did a manual update to 3.6.3 (0026) and then crashplan started to run again. But on my computer, the crashplan console will not start. When starting crashplan, only the splashscreen appears and stays there. Any idea what’s wrong?
Well, a reboot of the DS1010 seems to do the trick :)
I’m having upgrade problems, too. I’m currently on package 3.5.3-0025. The log messages show that there is an upgrade going on, but that finally went away after several restarts, and now the log says it scanned for files. But there are still two serious problems:
1) I can’t connect the headless client, it just hangs at the splash screen.
2) CrashPlan on the web shows my DiskStation 412+ contacted the server when it restarted, but nothing since. This despite the fact that I deliberately touched some files.
OK, some new (and positive) developments. I had to reboot several times, and I had to restart the CrashPlan agent, before I could finally connect the UI client. It seems that mostly patience is required. Also, when I finally connected the UI client, the DiskStation had lost all config. Fortunately, I was able to “adopt” the old backup, which means I didn’t have to re-transfer all the contents of my DiskStation. A few reboots and restarts later, and a few hours to “resync”, and I’m happy to report that everything is working again.
If you upgraded the Windows client software (or it auto-updated) it may have overwritten the UI.PROPERTIES file and reset the port to 4243. It need to be servicePort=4200.
I seem to have hit a problem with a recent update…
Lots of problems with CrashPlan updating itself to 3.6.3, but it finally seemed to do it successfully. The package version still shows up as 3.5.3-0025 in package centre, and no updates are shown as available…
Trying to start CrashPlan manually from the shell results in this;
nas-lon> /var/packages/CrashPlan/scripts/start-stop-status start
Could not find JAR file /volume1/@appstore/CrashPlan/bin/../lib/com.backup42.desktop.jar
Can anyone help? Preferably without loosing any backup archives stored on this box!?
Tried your 3.6.3 packet on an Intel Atom (DS710) I had to reinstall java, before it worked. Else it kept saying stop and restart before connecting the client. Also tried without having Java installed but it will not let me install it then, even that the 3.6.3 contain its own Java.
Thanks for keeping my NAS backed up!
really good work but perhaps you can put amount of memory warning earlier in the posting
I enthusiastically installed, then realised no way would I have enough RAM on my ds212j
Do we know if Crashplan works with DSM 5.0? Patters, thanks again for all your work in getting and keeping this running for the community.
CrashPlan and Serviio are both working, but I had to remove/reinstall the Java 7 package to get things working after the DSM upgrade (from DSM Beta 5.0 Update 1 to DSM 5.0 Final).
Thanks tcw… I had to uninstall and reinstall the Java 7.0 SE and now working. I did try first the Java 7 from synology but crashplan still didn’t run.
Another thanks to tcw… got CrashPlan working again after DSM 5 upgrade by reinstalling the Java 7 Embedded package from patters.
I upgraded from DSM 5.0 beta 1 to DSM 5.0. Afterward, the CrashPlan package wouldn’t start. I didn’t check any logs, but saw that tcw was running it on Java 7, so I uninstalled the Java SE for Embedded 6 package from Patters, and installed the Java 7 package from Synology. Crashplan package now starts and things are as they were.
Just to add my 2 cents worth …
Crashplan 3.5.3 auto updated and began to stop and restart over and over again. Tried all the above suggestions with little joy. Read back through the initial instructions and noticed that the user crashplan needs a “homes” directory, which of course was not there but did not effect the operation of 3.5.3. Created the “crashplan” folder under the “homes” share and gave the crashplan user ownership, started crashplan, stopped it and started it again (to gain client access) and has been running ever since.
Thanks to all for their suggestions and to patters for his excellent work. Hope my experience helps someone out of a bind.
Cheers.
It is possible to automatically add the necessary firewall rules after install in spk files
the following needs to added to the .spk
Add /conf/cp_port to the .spk
The content of the file is:
[CrashPlan]
title=”4243 TCP”
desc=”CrashPlan”
port_forward=”yes”
dst.ports=”4243/tcp”
in te postinst section add the following
PACKAGE_PATH=”/var/packages/CrashPlan”
SERVICETOOL=”/usr/syno/bin/servicetool”
# add port-forwarding config file
${SERVICETOOL} –install-configure-file –package $PACKAGE_PATH/target/conf/cp_port
in the postuninst section add the following
SERVICETOOL=”/usr/syno/bin/servicetool”
# remove port-forwarding config file
${SERVICETOOL} –remove-configure-file –package cp_port
I have a 212+ that i just put on the initial release of 5.0 and i encountered the same rocky update that you did Patters, i ened up having to remove crash plan, and java update java, then run the install again, i logged in and had to re adopt my DS and then enter my password again, i am in the process of syncing my data again.
however it seems to keep disconnecting from crash plan ever 4-6 percent then reconnects after a bit and then disconnects again. i am not sure if this is an issue with the client installed on my DS or a general crash plan issue.
are there any log files or anything that you need to look at?
You will find a lot of information in the bullitpoints at the top of the page, including this:
“The log which is displayed in the package’s Log tab is actually the activity history. If you’re trying to troubleshoot an issue you will need to use an SSH session to inspect the two engine log files which are:
/volume1/@appstore/CrashPlan/log/engine_output.log
/volume1/@appstore/CrashPlan/log/engine_error.log”
Try looking at those log files.
I am having a similar issue. I too had to uninstall java and CP, and then did a reinstall, and was able to re-adopt my machine. Once, I found that when I inspected Package Center, I found that CP was not running, and I therefore restarted it. It has been running OK for the past 12 hours. Nevertheless, I can’t get the client to reconnect again. I have the correct IP address as far as I can tell. I am happy to inspect the log files mentioned above, but would need some instructions on how to access them. Any other thoughts would be appreciated.
I had the same prob with the auto-update of 3.5.3 on an ds212+ ARM 512Mb RAM
I did (roughly, but you get the picture): Uninstall, reboot, install, restart service, fire up client, adopt backup, restart service a couple of time because it died, restart client a couple of times because it hangs when the service is down. Then… it worked…
I think the key here is reinstall and reboot.
I was having problems connecting to my Synology install from a new WIndows PC, so I removed and re-installed the package. I’ve since resolved all my connection issues, adopted my backup and all is smooth but one issue. None of my Friend backups are working (I backup many client systems to my storage as a part of the service I offer)…I get “Backup disabled — backup location is not accessible.” Is there some rights issue I need to resolve? If I lose backup history, it’s not the end of the world, but I do need to get this going. The Friend systems are connecting to my server and showing green, but no backups are running.
In the “inbound” section, try clicking on the drop down arrow to the right of your friend’s job. Then click “Attach an Archive” and select the folder that was previously used for your friend. It will take a while for CrashPlan to synchronize the archive file but will then start the backup. Check back the next day to see if it worked.
I rebooted and then was able to connect the client to the backup engine. However, after the client was attached for about 5 minutes, it disconnected. I launched the client again, and it connected for about 3 minutes and kicked me off. I tried a third time, and it has held for about 2 minutes and kicked me off again. The error is: “Crashplan has been disconnected from the backup engine”. Let me know if anyone has any thoughts. Thanks.
– Encrypted folders? –
When backing up a synology-encrypted folder to CrashplanCentral,
I get an empty folder, without its contents.
is that normal?
Thanks
Same Problem on my ds1813+ did you find a solution?
Since the latest DSM update (5.0-4458) yesterday Crashplan isn’t starting anymore. There’s not even anything to be seen in the log. It used to work fine with previous betas of DSM 5. (I’m on DS 214+)
SAme issue here with DS1513 :-( Package is now broken
You have to reinstall Java. I reinstalled both Java and Crashplan and now it’s working.
I had CrashPlan running on DSM 4.3 and upgraded to DSM 5.0. After the upgrade both Java and CrashPlan needed to be upgraded. I chose Update All, which started with CrashPlan, then when it couldn’t dinf Java it failed. I then upgraded Java and now CrashPlan does not show up as a package. The directory has been renamed from @appstore/CrashPlan to @Appstore/crashplan_mig_data, but the app does not appear as a package to uninstall or re-install. I’ve removed and reinstalled Java, rebooted the Synology several times, etc., all to no avail. I’ve removed and readded the CrashPlan URL listed here in the packages list and still nothing. I’m not sure what to do to make the package appear again, but I really need it back. Any thoughts or advice would be greatly appreciated.
Read the comments here and still can’t get the package to show up in Package Center so I can uninstall or reinstall it. I’ve rebooted to no avail. Other ideas?
Tip after upgrading to DSM5.0: Reinstall your Java embedded. Check out the readme.
If you update DSM later, you will need to re-install this package or else UTF-8 and locale support will be broken by the update.
Hello,
nice tuto you give us there.
I have a problem, when I first launch crashplan, it connects well on my DS411, and it asks for the “archive password required”.
When I enter a password, and a question/answer, it gives a 3box windows to validate. I save and then I receive an error : “crashplan has been disconnectec from the backup engine”.
any idea ?
I’m unfortunately having an issue with CrashPlan where it stops saying that the backup destination was disconnected. Im running 5.0 on my DSM 1513+ and with the synology Java. Any suggestions?
thanks
Will the CP Pro be updated? It is still on 3.5.3 and cannot get to work anymore. Was working, then broke on DSM4.3, reloaded all , tried update to 3.6.3 on client – but Syn still on 3.5.3. Upgraded to DSM5 – still same issue client cannot attach to syn.
After 17 days of no backup, it looks like the DSM 5.0 upgrade helped. Delete/reinstall java, delete/reinstall CP on NAS (DS411slim), reinstall GUI on Win7. Edited the conf on PC to point to the NAS, nothing edited on the NAS config manually. I as able to adopt, and CP started to work on the NAS. Immediately started to upgrade. Te Package center shows 3.5.3, the log file shows 3.6.3. The Win7 client is 3.6.3 64bit. Big thank to patters for maintaining the whole setup, Crashplan support knocked me off when I opened a case.
@Ron – Patters posted the .spk file for Pro 3.6.3 a page or two back in the comments. To get mine working I uninstalled Java and Crashplan. Downloaded the latest version of Java from the Oracle site, put it on the Synology and then installed Patters Java package. After that do a manual install of the CrashplanPro 3.6.3 file. Stop and Start the service (I found a reboot after that helped too)
Then connect with your desktop client (edit the config file to point to the Synology if not already done). You should then be prompted your from Crashplan account info. Once that’s all done you should see the option to Adopt the previous backup from the Synology. Do that (put in password one more time if prompted). It’ll take to some to do the block check but after that you should be good to go.
FWIW mine’s running on a DS213. I really wish Crashplan would officially support the headless NAS solution.
Is it possible to run two of the client packages side by side? I’d like to use the PROe client to backup my NAS, and also run the regular CrashPlan home client to offer my NAS as a backup destination for my family. Would this work?
It looks like, this is not possible:
That was the Answer, I had the same question asked here:
I don’t think so. From memory the start stop script looks for a process running containing the text CrashPlanEngine, which all versions use – so things would get mixed up.
DSM5, new Java7, USER Home services enabled,…despite putting http://packages.pcloadletter.co.uk in the Package Sources, I don’t get CrashPlan in the list of available downloads… Am I missing an important step some where
I couldn’t see the package either, I just downloaded it with a link in a previous comment and installed it manually.
Found my mistake… I should have been looking in the community folder for packages…
Crashplan is working awesome for me on several Synology units. Wondering if I need to hold off on upgrading to DSM 5? Running rock solid on latest 4.3 atm with all my units. Please advise if it will break Crashplan?
Just installed on DSM 5. When followed instructions to the letter everything started to work.
For me it is working normally, just had the work load to reinstall, adopt the machine, but that is OK. the DSM 5 is more organized and clean, I liked.
After upgrade to DSM 5.0, I reinstalled Java then CP. I can’t get the GUI to connect. In SSH I can see the engine is running but there’s no listener on port 4200 when I run netstat. Any advice?
I had this same issue, but in my case I was making it wrongly.
In my Putty, I had setup the tunnel, but it is not needed.
What I do is SSH (using Putty), normally, no extra configuration.
Open the ui.properties and set the 2 and 3 line to this:
Extract the # for each of them
serviceHost=192.168.X.Y (insert the NAS IP address)
servicePort=4243
And it all work normally. Hope that helps you.
Thanks Flavio. Unfortunately that didn’t work for me.
Not the best question, but have you restarted the NAS already? just in case :)
Worth asking but yes, I’ve restarted several times.
I finally got it working. Turns out that I had to reinstall the software on my desktop. The Synology package was working all along! Now I’ve just got to figure out why my friend’s backup destination is unavailable.
Ahh, it’s just a matter of attaching the archive. Easy peasy.
This is a nice package, but there’s a problem. With very large backups, CrashPlan bumps up against the open file descriptor limit. They document this problem and its solution at http://support.code42.com/Administrator/3.6_And_4.0/Troubleshooting/Too_Many_Open_Files
The solution given is to add “ulimit -n 65536” to CrashPlanEngine. Unfortunately, it appears only root can increase file descriptor limits, and you’ve set the package up to run CP non-root (as “crashplan”?) so the given solution fails.
Or so it appears to me. Suggestions?
I had drawn the same conclusion, and will release the next version of the package to run as root to fix this issue.
Great, thanks!
In the mean time, have you any quick hints as to what to hack to manually make the change? I’m reasonably comfortable with unix(ish) system administration but mostly BSD variants. I’m a complete neophyte on Synology and Linux in general, so I’m all at sea trying to figure out even where the package gets started.
Hm, well after posting that last I did find /var/packages/CrashPlan/scripts/start-stop-status.sh and have tried changing
DAEMON_USER=”`echo ${SYNOPKG_PKGNAME} | awk {‘print tolower($_)’}`”
to simply
DAEMON_USER=”root”
This seems to have (once again) lost me my CP configuration, but I’m soldiering on for now to see whether it answers. At least CP does now start up and doesn’t log an error for the ‘uname -n’.
One thing that solved that for me and many users here in this forum, is this:
Idea from Casper K that rocks!
I’m using my Crashplan without any issues after I applied that solution.
Thanks! That seems better than my DAEMON_USER=”root” hack, and generally has a better smell than running as root.
Seems to be working for me though time will tell (my computer is now “synchronizing” and probably will be for some hours to come, then we’ll see for sure).
That’s very strange. I have just confirmed this works, but I can’t explain it. When I tried this in isolation a few weeks ago, I’m sure that changing ulimit in a root shell session had no effect on a subsequent su-launched process running as the crashplan user. Maybe it’s different when it’s done within a script’s local environment. I’ll release that new version…
N.b. I did use “ulimit -n 65536” which I believe means “unlimited” rather than the suggested 65000. Probably doesn’t matter for practical purposes.
New package version out with ulimit fix for very large backup sets. If you have just upgraded to DSM5.0 ensure you remove and re-add the Java package first, before attempting to upgrade CrashPlan.
Thanks patters, good support. So far, testing well. Requires the service stop and start to allow client access and need to “adopt” the existing backups, not a complaint, merely informational for others.
Cheers,
KrisH
Upgraded right now, I didn’t need to adopt in my case (Running DMS5.0 Final and previously package ver 26).
Thanks :D
Hey patters, I donated to you a couple weeks ago and never got any confirmation, just curious if you received it and had a beer on me! Would have come from rbuck AT cfpwood DOT something.
I really appreciate your work on Crashplan for Synology. Thank you.
Hi – just checked and I did get your donation, thanks very much. I have been away for a few long weekends recently – snowboarding and just got back from a stag weekend (bachelor party) – so I can safely say that your funds were put to good beer-drinking use! Thank you very much to everyone who has donated :)
I suggest that everyone donates with the paypal button in the top right section, as we wouldn’t have CrashPaln on Synology without patters!
Thanks :)
I agree.
Hello,
great package so far! :-)
But as the crashplan application is not running under root, not all files can be backuped. I have files and folders in my home folder which cannot be accessed.
I changed the user in your script, but every upgrade removes the changes.
Have you an idea / solution?
Things seem to be working – however I changed location of backup archives on DS1513+ to different shared folder on volume 1. It looks like things are backing up to that directory but there are no files or folders (typically folder with GUID for each machine). Is this normal?
for crashplan, do you recommend Java V7 or V8 ?
V7, since V8 only just came out.
I can’t get V8 working with CrashPlan – it simply won’t run, even though it seems to install successfully. Has anyone else been able to successfully get it to work with v8, or does the installer need to be modified to allow the newer Java version?
Rolling back to 7 and it launches fine and I can get the GUI to connect, but then when I try to log into my account it simply says “Unable to connect, check your network”. I can connect fine from another machine, and can install/download apps etc just fine. I don’t see anything denied in my F/W or router logs. Any pointers on where to dig further on that error?
I was using it perfectly fine previously before updating to DSM5, but somehow the upgrade broke it and I had to reinstall.
The chance of established software being tested to work with a major new Java release that has just been published is nil – don’t be surprised.
V7 for intel proc yet? Last time I had to use V6 with intel proc synology.. Apparently I am doing a fresh Java install once I upgrade to DSM v5..
With DSM 5.0 yes.
CrashPlan is working for me with Java 8 and the latest patters package on DSM 5. DS1513+
Sorry, I am using ejdk-8-fcs-b132-linux-i586-03_mar_2014.tar.gz
Crashplan is working for me with java 8 on ds414 with dsm 5, but the package show “stopped” on the status.
In fact, the status is wrong.
A small bug ?
Finally after weeks of struggle CrashPlan is working again. My setup had been working perfectly on a 1513+ until the latest CrashPlan update. After that I’ve had endless problems. Finally after a memory upgrade to 4GB, java upgrade to v7, and package upgrade to 027, I’m back in business. My backup set is huge (3.9TB and 732K files) but it seems to be working. I’ve had to allocate 3GB to java heap. The way I finally got all this to work was:
1) uninstall java and CP
2) installed java v7
3) installed 027 CP but did not run it
4) modify Crashplan user permissions
5) up java heap memory to 3072M
6) start CP; stop CP; start CP
Voilà, after adopting my old back and synchronizing, backup has now been running for 12 hours. Before it would disconnect within minutes of starting the backup.
Thank you Patters for your continuous dedication to this project.
Hi all
On DS413 DSM 5.0, java v8 & CP 027 crashes, leaving a process behind.
After reverting back to v7 (removing java v8, re installing java v7, killing the java v8 process and re installing CP 027), I’m up and running again. Guess java v8 on DS413 will have to wait!
Uninstalled Java 6, installed DSM5, installed Java 7 (via the Synology package manager), installed CrashPlan 3.6.x, adopted the machine. Worked first try. Many thanks, patters!
Ran the update to 027 this morning and now Crashplan PRO will not restart on my Diskstation 412+.
I’m a total newbie on this. I was able to initially setup DS412+, java, and CrashPlan, but my Linux troubleshooting is pretty non-existent.
Is this my unique problem?
Even with this current issue, I have to say that the CrashPlan package is exceptional!
I hate it when people don’t follow up on problem fixes, so here is my update:
Yesterday, crashplan pro would not restart even after a server restart.
Today I just went in again through package center and hit start, ta-da, all is right with the world again. I find no reason for it, but I do love it when stuff fixes itself.
SCRATCH THAT! STILL NOT WORKING. Apparently it ran for about 15 seconds then quit. I am not back to square one. I hit RUN and the status changes to running for one second then reverts to Stopped.
Anyone else having this problem?? I’ve restarted everything. DSM 5.0-4458. Java 1.7.0_51
What does the log in Package Center show?
If that doesn’t show anything useful, look in
/volume1/@appstore/CrashPlan/log/engine_error.logWhen you upgrade you need to start CrashPlan, wait until you can see “CrashPlan started” in the log (in Package Center). Then stop and restart the package. That’s because the start-stop-status script has to make some edits to the configuration files which don’t exist until first run. This explains why you saw the behaviour you reported. This is described in the sixth item in the Notes section on this page.
Thanks for the reply. The only file in the crashplan folder is backupArchives which is now empty. I probably blew everything away when I reinstalled the crashplan package….
I never have the opportunity to stop the crashplan service and restart it because it will not stay running long enough to get to the stop button.
It worked just as you said it would the first time I installed in two months ago. Now it won’t run.
Apparently no logs are being generated either.
I have uninstalled java, my java manager, and crashplan. Then installed the java 7 embeded from PCloadLetter and a fresh crashplan.
Same problem. Crashplan will not stay running.
There are no log entries in crashplan.
I upgraded my DS1812+ to DSM 5.0-4458 and CrashPlan tp 3.63-0027 and am no longer able to do local backups to my NAS. The clients all say Destination unavailable – backup location not accessible. I am using the same share as before the upgrade and have verified permissions. i have tried rebooting the nas to no avail. any help would be appreciated.
In the “inbound” section, try clicking on the drop down arrow to the right of your friend’s job. Then click “Attach an Archive” and select the folder that was previously used for your friend. It will take a while for CrashPlan to synchronize the archive file but will then start the backup. Check back the next day to see if it worked.
when I tried that I received this message. The backup engine does not have access to the given location.
i may have been a little to quick in my response I updated permission and tried again looks like they are now backing up. thank you.
Another successfull update to DSM 5 on DS414.
Uninstalled Java – Upgraded to DSM5 – installed the official Java Manager from Oracle (now available in the Package Manager) and reinstalled Crashplan. Didn’t even have to adopt my old Backup set – everything just worked as it did before on DSM4.x
Remember to Donate people – I just send 10 GBP your way Patters – Please keep working on this project :)
Pingback: Mac Mini Server vs Synology 1513+ (Part 2) - HoosierMac Consulting
Having issues with 3.6.3-0027. I did a fresh install of the PC Loadletter version of Java SE 1.7.0_51-0023 and then fresh install of 0027. The crashplan package will not stay running for more than one second. I click run, the status changes to running, then changes to stopped. It does this every time I click run.
0026 worked just fine. Is there anyway to revert to that package???
CrashPlan on DS214play Doesn’t See My Files:
I created some Shared Folders on my new NAS. Installed Java and Crash Plan on my NAS. Installed Crash Plan on my Mac and pointed to my NAS. Set up a Crash Plan account. Configured Crash Plan with my Shared Folders. It backed up my empty Shared Folders.
Used rsync on my Mac to copy more than 40G to a couple of the Shared Folders on my NAS. Waited over night. Nothing was backed up.
Tried changing file selections in the Backup tab and Crash Plan does not see the sub-folders. Click on the arrow and it briefly opens up with Loading and then closes back up and removes the arrow.
Tried Verify selection now. Tried restarting Crash Plan. Tried adding a sub-folder using the DSM File Station. Tried copying a folder with Mac Finder. Tried expanding homes.
I can expand @tmp and other @ folders but not homes or any of my Shared Folders in Crash Plan.
Logged in with SSH and every thing is 777.
Checked /volume1/@appstore/CrashPlan/log/engine*.log and service.log.0. Did not see any errors. I see ‘Scan done and nothing to do’.
I have new everything, DS214play with an Intel processor and 1G memory, DSM 5.0-4458, Java 1.7.0_51 installed by Java Manager package, Crash Plan 3.6.3-0027.
Reinstalled Java and Crash Plan multiple times. Rebooted my NAS. Still does not see into those folders.
Noticed something odd when I used SSH as root. The permissions on the Shared Folders i created were 000 and 711 on homes. When I am admin, they are all 777.
Gave the crashplan user read access to those directories. It have postponed the backups until later but at least the scan picked up the files.
Thanks for that last line about configuring user access to the shared folders, totally solved my frustrations this morning.
I had to reinstall both crashplan pro and java because crashplan showed as “stopped” in the package center, and would not start. I finally got everything back up and running, but crashplan desktop app could not “see” into the shared folders during file selection, and new files I was creating were not backing up.
I had forgotten that step about configuring the crashplan user from within DSM.
Ah, that last line totally solved my frustrations this morning!
I received an email that crashplan had not run in 5 days for our office server, which could be a huge problem if it ever crashed. The crashplan pro package was listed as stopped, and I could not get it to start. I uninstalled the cpp and java 7 packages and reinstalled both on our DSM 5.0-4482. This solved my problem of crashplan not starting in the package center, so after loading the desktop crashplan application on my PC, I adopted the settings from the previous crashplan setup.
Everything seemed fine until I noticed it still wasn’t finding any new files. Under file selection in the crashplan desktop app I couldn’t “see” into the shared folders to view any sub-folders or files. It wasn’t until I read your comment that I remembered to set user permissions for the crashplan DSM user to allow read access to the shared folders to be backed up.
Thanks man, I can feel the headache disappearing already!
Comment and questions about permissions best practices for the daemon user.
It seems that the CrashPlan daemon user needs read access granted to Shared Folders with Windows ACL Permissions, even when the Windows ACL is off (“Enable advanced share permissions” is unchecked). All custom shares created under DSM 5.0 have this, and shares created in earlier DSM versions can be converted to have it. As far as I can tell the daemon user had no permissions granted to shares created under under DSM 4.3 and is only in the users group (which has no permissions to those either). This caused some head scratching for me, so wanted to share this in case it comes up for someone else.
Right now I’ve granted the daemon user read permissions, and will need to update this if I create a new share, which is ok. This is a home setup, so I’m looking for a balance of ease of use but with reasonable permissions. Is there a ‘more correct’ way to do this, for example adding the daemon to admin users? Any thoughts are appreciated.
Successfully installed both, DSM5 and Crashplan 3.6.3. Had to install Java 7 again then it worked. However, Java 8 did not work.
This worked for me:
1) uninstall Java7 & crashplan 3.5
2) reboot
3) install Oracle Java 7 package
4) install crashplan 3.6
5) reboot
Uploading at 10.4 Mbps now :)
Thanks
I posted on March 11 and 12, and am still having problems. Based on reading the various materials, I have a question: I have a 412+ (Intel Atom Processor) running DSM5.0. I used to use Java 6. From what I read, am I supposed to use Java 8 now? If yes, is this the version I am supposed to use: ejdk-8-fcs-b132-linux-i586-03_mar_2014.tar.gz ? Thanks.
I’d suggest using Java 7 rather than 8. It will take time for software to be confirmed as .compatible with Java 8
Pingback: QuickTip: Unsticking a stuck CrashPlan backup on a Synology DSM | The Thirteen Thirty-Seven