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 
My synology fails to even download the .jar files. I tried to extract them from the 4.4.1 Linux install from the Crashplan website but there aren’t any .jar files inside. Does anyone know how to download them manually?
I am done with it. Tried all the steps mentioned. Got the NAS to update the Crashplan, but the client will just not connect. Changed both the NAS and PC .ui_info file, but the package on NAS just stops. And the strange thing, the .ui_info file is changed afterwards (on NAS). I was giving it a final try, since my subscription ends in a month or so. I thank Patters for a year of good backups.
Does anyone have other suggestions than Idrive? I love the prices, but I just don’t want a gui on port 80 of my NAS.
These days the upgrades never seem to work. I just wait until Code42 updates the actual main download and then I update the package to pull that. That hadn’t been done when I checked earlier this week, but I’ll take another look in a bit. Hopefully we’ll get this fixed soon.
Code42 have changed the folder naming inside the main .tgz archive. Also JNA has been updated to version 4.1.0. Their bundled jna.jar now includes an ARM binary. They also made a new requirement to put the NAS IP in the .ui_info file on the client computer. I have the new 4.4.1-0034 package working on Intel, but I need to test on ARM and ideally on PowerPC. It’s late now, so I’ll have to continue tomorrow.
Ok, so the included ARM libjnidispatch.so doesn’t work for me so I’ve made new ones for armel and armhf architectures. Now I have to make the package able to cope with legacy installations of CPPROe. I also need a willing PowerPC test subject to see whether inotify support (for realtime backup) will actually work now that Code 42 is using a newer libjna.
Thanks for all your work on this patters!
I did pretty extensive research before jumping the ship, and the fact ís, if you want to archive around 1 TB of data, iDrive is the only option price / direct Synology support wise.
I tried IDrive. However when I installed the package it is supposed to give you a url on the nas to go to in order to configure the package. However in my case it didn’t work, the web files were missing.
When you use IDrive with sinology do you need a business plan? the business rate is a lot higher
That´s strange. You have to have web station activated obviously, but on mine 1511+ I just installed the app, run it from the top left menu, and that was it. The address is like /IDrive/
I have regular personal plan.
That’s too bad. I’m trying Idrive now, but it doesn’t seem to backup anything. Job runs, nothing happens. I guess it’s mandatory to use the admin account instead of an account in the admin group, although I didn’t try reinforcing the admin account yet. Besides port 80 this will be another feature I don’t like about Idrive
.
I’ve got iDrive running since a couple of days. Runs on port 443 (add an ‘s’ to the http address), I have port 80 closed. Very very good backup speeds and so far all files are being backed up (1TB does take some more time). Check your logfile for the error. There’s a good offer on the Net for 15 bucks a TB the first year.
I did like Crashplan very much. Set once and forget about it. All precious data backed up. But the frustration due to the update issues again and again, and the time it takes to find a solution, is enough for me now. iDrive is not as sophisticated as Crashplan with continues backup and versioning, but my data is off-site. So far so good.
Nothing in logfile. Job is running though. Nogo for me.
Be sure you are checking the right log – every backuped file is properly logged.
The right log? I have a log in NAS and a log in Idrive app. Both are empty. Disk space 0%. Pretty sure nothing is backupped. But let’s not discuss Idrive here. This is the Crashplan topic. And that’s not working too!
I don’t quite understand your issue with port 80. I can connect to the idrive account on my NAS remotely using a custom port.
It’s not that you cannot connect, but if you run a website also and you want it to stay on default http port, you and everyone else also will be able to connect to the Idrive part (by default Idrive url). This can only be changed if you can setup Idrive to listen to another port than webstation. Since they also require to use the Admin account (which I had disabled) it’s a bit of a nogo for me, securitywise.
And another thing; your Admin password is being exposed if you do a ps w|grep idrive . You don’t want that either. For details you can refer to: http://forum.synology.com/enu/viewtopic.php?f=251&t=105026
I wonder what other surprises are in store due the iDrive folks? I paid for a year back in 2012 or 2013, but I bailed when I found they were storing my password in a barely obfuscated text file (a=c, b=d) and using an unpatched Windows DLL from 1999!
They claim they fixed these issues, but I haven’t verified. Just be careful!
This package fell off my list several days ago for my DS415+ (C2538 avoton). Could you please check that http://packages.pcloadletter.co.uk/ has this architecture properly flagged?
I was running in to the same issue with the .ui_info file changing after every start of Crashplan.
I got fed up, so I closed out of all of Crashplan executables and verified it via Task Manager. Then I modified the file using Notepad++ as an admin.
Once the change was complete, I set the file to “Read Only” via Properties. (Windows 7)
Same feelings here. I was really happy with Crashplan & Patters pacakge, but the number of times I had to update all kinds of obscure config files is getting ridiculous.
I wonder if the updates from Crashplan are designed to break things…. Thanks Patters for all the hard work, it’s really appreciated, but the updates from Crashplan make it impossible for the users.
For now I will try Amazon Glacier, it’s a package from Synology, so no more weird problems I hope.
let us know how glacier works out
Finally got the 4.41 working with the latest suggestions in this thread. Thanks very much guys!
Unfortunately it looks like I can’t use iDrive with my DS312+ on account of it being a QoriQ processor and neither a x86 or ARM installer will work.
I can’t remember for the life of me now why I went for the + version of this NAS…
I succed to upgrade crashplan to 4.4.1 on 2 NAS ) but the 3rd failed and i don’t know why..
i noticed that :
i don’t need to edit, on client ( Linux in my case) , /usr/local/crashplan/conf/ui.properties anymore.
i only need to edit /var/lib/crashplan/.ui_info and change uid and ip ( i didn’t change 0.0.0.0 to the real IP on NAS, i did, only on Linux)
Find a way to make it work from scratch
Remove the package through Synology GUI
Then
Service started
Update your client (mine is under Windows in 4.4.1
Then on the server side (on the synology) go to
/var/packages/CrashPlan/target/upgrade/
You’ll see that the server tries to update to (for me) 4.3.0
You have to (follow what is on this site http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/)
unzip -o /var/packages/CrashPlan/target/upgrade/xxxxxxxxxxxxx430.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
unzip -o /var/packages/CrashPlan/target/upgrade/xxxxxxxxx430.jar “lang/*” -d /var/packages/CrashPlan/target/
Then restart crashplan on Syno
I’ll try to update to the next version 4.3.3
Again
unzip -o /var/packages/CrashPlan/target/upgrade/xxxxxxxxxxxxx433.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
unzip -o /var/packages/CrashPlan/target/upgrade/xxxxxxxxx433.jar “lang/*” -d /var/packages/CrashPlan/target/
You’ll have to do that for each uper version of crashplan till you reach 441 … then the service start
Go to
var/lib/crashplan/.ui_info
Copy your ID and change it for Windows:
C:\ProgramData\CrashPlan
PORT,UI,IP_Syno
Good luck
I definitely appreciate Patters doing this. I am going to send a token of support to him in a moment. I guess I will investigate iDrive as well… I am backing up more than a tb so I will likely have to trim back and look for redundant files if I go with iDrive. The funny thing is that I would bet a lot of folks would gladly pay for something between a personal account and a business account for support Synology backup on Crashplan… I know I would be happy to pay it just to avoid the hack-nature this has become (and I agree… it almost feels like Code42 is doing things to make this more difficult…like they are happy to take our money and equally happy to screw with our ability to archive). I was okay with having to fiddle with a Java install now and then and edit a ui properties… but now we see people saying things like “all I had to do was this…” followed by all kinds of bash commands and changing settings on multiple computers just to open SSH tunnels so you can access the terminal to perform the commands. It is comical to see someone write “all I had to do was…” followed by 20 lines of code that you hope you get right lest you royally F*%ck your box.
Anyway… thanks again Patters… I am going to wait until Code 42 posts the changes to the main file then follow your install package once updated. I will also have to go in an notify Code 42 that this is going to be the last time for me… if they don’t show some move to help us out then I am going to finalize my iDrive subscription…they have made hundreds of dollars off of me so far. It is no longer a cute little thing… I look at the number of people paying them and see a competitor that is supporting the Synology… and maybe iDrive deserves the next few years of my money.
That pretty much sums it up. Lets make it an epilogue and move on.
This past weekend I complained to Code42 about the lack of support for Synology products, and they sent this response:
“We’re aware of the passionate community around Synology devices, but they are not something we plan to officially support.”
I was suckered into a longer-term plan for the rate reduction, so I’ll probably wait another year or so before trying iDrive.
They have reasonable instructions on their website so i don’t know why the are reluctant to support it (I guess various issues etc being headless – which could be overcome if the client could easily connect to machines rather than manually changing configs).
But I’ve been away and only noticed this morning my mac and NAS hadn’t backed up for 3 days. Both had the software removed. So I had to install it again on both, but with zero changes they started working again. I also had no issues connecting to the NAS after changing the .ui_info file either.. thats on a DS412+
I’ve tried all the upgrade steps multiple times. Starting over from scratch each time. Here’s a screen shot of my log:
http://cl.ly/dR7z
Everything is smooth until getting stuck at 4.4.1
Does anyone have an idea of what I could be doing wrong?
could you try
mv upgrade.sh upgrade.sh.old in xxxxx441.xxx directory and restart Crashplan
no, it won’t work, delete xxxxxxxx441.xxxxxxxx directorie(s) and restart crashplan
I don’t know if I’m the exception here but after going through the 4.3 update process a couple of weeks ago it’s been pretty stable. It did stop just yesterday and I had to get the UI information again after restarting the Crashplan service but it’s running fine now. I too wish this was a bit more stable but I don’t think it’s the fault of this package creator. I’m very grateful for the work done on this package as it’s very straightforward. This is, after all, a headless client and is primarily designed for Linux gurus (which I am not one) so this package is very appreciated.
1
patters package 4.3.0-0033 ( which correspond to 4.3.0, 4.3.2, 4.3.3, 4.4.0, 4.4.1) is ok with Intel NAS but not with ARM NAS
After fews restart of crashplan, upgrade to 4.4.1 is ok on Intel Nas but not with ARM (Marvel)
mmmm maybe it’s false….. because i succed to upgrade crashplan to 4.4.1 on a marvel NAS….
for 4.3.0 to 4.3.3, i used automatic upgrade (via gui)
for 4.4.0 and 4.4.1, i didn’t use automatic upgrade but I used
unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar *.jar -d /var/packages/CrashPlan/target/lib/
unzip -o /var/packages/CrashPlan/target/upgrade/1435726800440.jar lang/* -d /var/packages/CrashPlan/target/
and
unzip -o /var/packages/CrashPlan/target/upgrade/1435726800441.jar *.jar -d /var/packages/CrashPlan/target/lib/
unzip -o /var/packages/CrashPlan/target/upgrade/1435726800441.jar lang/* -d /var/packages/CrashPlan/target/
and it work’s now….
strange….
this helped me. ds213+
I’ve managed to upgrade by applying http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/ instructions on the latest upgrade jar (1435726800441.jar).
This means extracting the nested jars from the jar and copying them to the lib folder. There will be some duplicates but everything should be okay.
However in 4.4 for some reason, code42 went from using properties files for logging to using xml. If you don’t have the proper files, Crashplan will start but the log files will be silent.
You can get them by upgrading your client (Windows in my case) client and copying over the conf/*.xml files to the NAS.
I find Crashplan upgrade quite annoying – for a backup service, breaking the clients every 2-3 months is not fun especially since one discovers this by accident.
Thanks to Patters and Chris for their support.
Just like Chuck above, I have sent an email to Crashplan telling them that enough is enough and if they keep on breaking on each upgrade, I’ll take my money elsewhere.
Thanks!
Wow that was a marathon, after hours of scrabbling around I re-installed the original package, then ran through all four upgrades (32,33,40,41), did all the .ui_info things including IP address in the PC version of the file, and eventually found the post above about renaming jna-3.2.5.jar. Now I finally have everything working (well it’s chewing through “synchronising block info” which is about the same!).
Thanks to everyone above for the hints/tips. Really not impressed with Crashplan right now. Unfortunately I have a DS413 which idrive doesn’t seem to support, so if I want to move it looks like it would have to be Glacier. Will cost more I suspect but at least is a Synology supported package. Have 8 months left on my CP subscription so will see how it goes…….
Thank you! I was going mad… jna-3.2.5.jar did the trick… :)
Yeah, I really don’t care for Code42’s ‘Bugger Off’ attitude about this. I mean I don’t expect them to create a native client for Synology, but they could at least be a little forthcoming and helpful with someone that does (Patters).
I’ve contacted them a couple of times and each time they’re flat out ‘We don’t care’ which is really off putting considering we’re paying customers, wouldn’t you at least try to accommodate people a little bit? Heck, aren’t more customers better?
The way things are going I’m afraid they’ll one date put something in place which will totally cut us off, then what?
Like a couple of you I’m moving to iDrive, so far so good although it’s great having a native client although it doesn’t seem as feature rich as the Mac/Windows one.. Ohh well..
Patters, just wanted to say thanks for all the time you’ve put into your solution, too bad Code42 are jerks and ruin the party far too often!
So I’ve been amazed at the number of comments covering all the issues since I first posted back in January during my eval of Crashplan on the Synology 415+. Given backups are so important, and you just want them to work, the continued breaking of the solution just scares the heck out of me!
I evaluated the various options for Crashplan on Synology (DS415+) and found so many issues I didn’t feel comfortable trusting it to reliably backup.
I switched to iDrive. It has been working seamless since I installed it back in January – yes it costs me a little extra (1st year $14.95, next year ~ $50 for 1TB), but the amount of time I have saved… well, even just reading the comments and trying the options would have cost more in manpower.
I get what people are saying that this should “technically” be possible, and yes, people may already be heavily invested with multiple computers backed up to Crashplan to want to persist getting it to work, but if you want a reliable backup mechanism for a Synology NAS I can highly recommend IDrive.
PS – I do not, or am in no way associated with IDrive – I just want to let people know there is a viable time saving option than continually faffing with Crashplan installs and configuration.
Nigel
What happened to the Crashplan package? it is not listed on the site anymore; anyone know where it is?
Two possibilities, it does not list packages that are not compatible with the NAS architecture, in my case I think there is a problem with ARM support in 4.4.1 for my 214se. The other is that patters may have pulled the package while he determines the way to make 4.4.1 work better for everybody (thanks patters)
I just published new packages for CrashPlan version 4.4.1. The JNA native binaries are updated to version 4.1.0 (CrashPlan no longer uses 3.2.5). I have tested on Intel and armel, but armhf (new ARM systems with NEON) should work fine. The only doubt is PowerPC. Please let me know if it doesn’t work on PowerPC and I’ll have to stick it back to the old 3.2.5 JNA library which didn’t work for realtime backup anyway.
Thanks patters for all your hard work.
I ran the update on my DS1512+ and it wont start.
The last posting in its log is that it updated to 4.4.1-0034
There is normally something after each failed attempt to start the service. After this last update there is nothing new in the log.
Suggestions?
I just un-installed crashplan & re-installed it.
It wont start and it is not reporting anything in the log file. Not a single character.
No idea why my DS1512+ is having the issue with the new release.
Intel Atom processor. Due to the Atom I am forced to use old java I believe. Currently running java SE 6 1.6.0_38-0032 & Java manager 7.0.51-0032
Any guidance on what I can do would be appreciated.
Thank you
Thank you very much patters for your work! I have been successful in updating my 214se, Marvell ARM and connecting with Linux CP client.
Looks like my DS413 still doesn’t work with the latest update. Client connects just fine, but no backup activities seem to be happening. I’m getting a “waiting for backup” status on the client. I installed Java 8 (update 6) and there is now only one error reported: Exception in thread “W17190486_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
How do we get/install the 3.2.5 JNA lib?
Yes, I have another report of the same symptoms. I will revert to the older JNA for PowerPC, hopefully tonight. Realtime backup will continue to be non-functional on PowerPC.
Should be fixed now for PowerPC. I haven’t incremented the package version since it’s just a minor change to a separate binary pack. You can either uninstall and reinstall, or edit the file /var/packages/CrashPlan/INFO and set the version to something lower than 0034 and update using Package Center.
Should be fixed now for PowerPC. I haven’t incremented the package version since it’s just a minor change to a separate binary pack. You can either uninstall and reinstall, or edit the file /var/packages/CrashPlan/INFO and set the version to something lower than 0034 and update using Package Center.
The fixed worked on my DS413. I uninstalled, then reinstalled, and then had to stop/start and wait for the GUID to change (took a minute or so). I then updated my client guid and everything worked! Thanks for the awesome support Patters!
Just want to echo what everyone else has said — thank you for all your hard work and the quick turnaround for fixes!
Patters, thanks very much for the quick turnaround. It’s crazy that Crashplan doesn’t jump all over you to get you officially supported and compensated. They’re going to loose a lot of business if this mess with the updates and extra file edits keeps up or if you just get ticked off enough with them to stop providing updates.
I found I had to stop and start the package even after it was running. Doing so regenerated the ID and once I had that in the file the client was able to connect.
I can confirm the same findings as Richard and had to restart to get the key. Thanks Patters!
ok so I found the error log and it looks like the latest crashplan package does not like the java 6 my ds1512+ atom cpu uses.
Here is the contect of the engine_error.log found at:
/var/packages/CrashPlan/target/log/engine_output.log
Exception in thread “main” java.lang.UnsupportedClassVersionError: com/backup42/service/CPService : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: com.backup42.service.CPService. Program will exit.
ok so I uninstalled java 6. Downloaded java 8 per patters instructions.
Installed java 8. Now I can start the crashplan services on the ds1512+ (yay) however my head (windows pc) crashplan is hanging when opening it.
Both are v 4.4.1
I checked the GUID & pasted it into the head ui file & restarted the head crashplan but still nothing but a hung splash screen.
I believe the NAS is connected to crashplan as crashplan central is indicating the NAS has been connected for 2 minutes. I just don’t seem to have head/gui access to the NAS headless install.
Backing up what I already have configured is better than no backups for now.
Make sure you specify the Nas ip address at the end of the I’d. This is the new requirement for this version.
Same thing here @slidermike. I’ll keep my eyes on this thread. I have a DS412+.
Don’t forget you need to change the 0.0.0.0 in the file to the IP of the NAS. New wrinkle in this version. So it should look like Port,ID,NAS IP
If it hangs at the splashscreen like that it’s an issue with the client GUID/IP address. Go back over the instructions (which were updated for this version, as mentioned in the changelog).
I too am having issues whereas crashplan seems to be running better and connecting to crashplan central, but I’m unable to connect the 4.4.1 GUI.
I notice different results from the Grep command to check ports on the NAS
netstat -na | grep LISTEN | grep 42
tcp 0 0 ::%17:4242 :::* LISTEN
tcp 0 0 ::ffff:127.0.0.1%18:4243 :::* LISTEN
Looks like it’s still only listening on the loopback adapter, not all interfaces (0.0.0.0). This is the default behaviour on first run. On second start, my package script forces it to listen on all interfaces (as mentioned in the instructions).
It somehow didn’t change for me on my ds213j, but after ssh as root and updating /var/lib/crashplan/.ui_info to 4243,guid,0.0.0.0 I could connect login, adopt the NAS and see it working again
The latest 4.4.1 package and/or my Java update from patters package has resolved the timestamp issues in the log displayed in the package centre. Time is now correct and reflects my timezone.
Although my unit had sucessfully performed an upgrade to 4.4.1 on it’s own over several restarts, I just did a complete reinstall using Java 8 SE and the new CrashPlan PROe package. Everything went quite well.
Thank you Patters for all the work you have done!
It is now working for me – windows client and DS212j Marvell. thank you patters, I appreciate your efforts and am going to make a contribution.
Hi Patters, the file “C:\ProgramData\CrashPlan\conf\ui_(username).properties” doesn’t have a service port entry
Did you update the client computer’s CrashPlan to 4.4.1?
Same for me and I just installed client 4.4.1 on the computer.
This was in the file:
#Mon Oct 05 20:40:53 CEST 2015
window=560,215,800,610
I’m back up with client GUI and everything.
Updated the package to 4.4.1
I added to the .ui_user.properties:
servicePort=4243
serviceHost=DS IP address
and used the IP address for my diskstation in the .ui_info instead of 0.0.0.0
Hope that helps anyone.
It does not work for me yet. The serviceHost IP address and IP address in the .ui_info is that the same?
The client says “can’t connect to the backup engine”
Answer myself :), I followed this instruction “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.”
But then I tested to start the service again and then the client started :)
So now it looks like I’m back in business!
Any chance of getting a CrashPlanDesktop script included in the package so it would be possible to display the client on an X server via ssh? It might be impossible for dependencies though :-)
Cheers
I don’t think that’s going to work considering Java Embedded is headless, so it’s probably missing lots of display library functionality to keep size to a minimum.
Thanks for the prompt reply – and the good work :-)
HC
Thanks again Patters for your great work!
Notice it stopped working a couple of days ago, followed the updated instructions and all working fine again – many thanks!
So I was able to get the new JS library and the new CrashPlan running on our DS414+ but the client on my computer refused to open past the splash screen. Not sure if this helps anyone, but I had to download the new version of the Windows client from CrashPlan, install it, and then redo the .ui_info and the .ui_properties to redirect to the NAS. Soon as that was done, I was back in business.
Good luck!
You have always had to match the client with the server version of CrashPlan. I have updated the client installation notes to make this clear.
Hmmm, is one or more javafiles that you install on the Synology capable of acting as a client ?
Imagine the CrashPlan client software shared from the Synology. To start the client you would create a link to the client (for instance \\IPADRESSOFSYNOLOGY\CrashPlanDesktop.jar/exe/…) – that will now always match the server – an off you go? (You would of course/probably need a proper java installation on the desktop computer with proper libraries installed and such)
Crazy thoughts – I know :-)
HC
So I think my issue (Mac OS X) is the ui.info file. I cannot edit it directly so I have to make a duplicate and trash the original. Then when I try to launch CP client it bounces for a while, then disappears (never see the splash screen). When I revert to the original UI info file, I get to the clent screen, but for the local machine, not the NAS. So, am I doing something wrong in editing the ui.info file? I have made all the other changes (GUID etc) as noted.
I had the empty .ui_info issue. I first populated it with the string I’d used in the past, using cat > , then I uninstalled / reinstalled CrashPlanPRO and a new token was written to the file.
Otherwise what’s worked consistently now, GUI-wize, is the Putty Tunnel and the following syntax in .ui_info:
L4200 localhost:4243 for v 4.1.1
4200,e59eba80-6c7a-489f-ad07-2730d3ddafb0,127.0.0.1
Thanks Again Patters!
Still not back in business. :-(
Removed and reinstalled the Crashplan package on NAS so I have the latest version.
Client was already on 4.4.1
Stopped and started the service on NAS
Changed the .ui_info at PC, to my local network NAS IP and the security key
On NAS changed the .ui_info to local network NAS IP
Even added the Service host and SErvice port in the .ui_USER_properties file on WIndows.
Client just doesn’t seem to reach my NAS Crashplan service.
Another hour of my life lost to this.
OK so today I tried to update to 4.4.1 on the NAS via GUI but of course it screwed up – it’s stuck on Installing and I cannot even get to the logs.
I’ve had to do some weird SSH things previously to be able to update the package in the past few months, but this time it’s just stuck.
Can anyone advise what to do?
P.S. My Win client was already 4.4.1 and everything was working smoothly even when connecting to an older verion on the NAS, so I guess I should have never tried and tweak what works…
Ah ok, seems the GUI was just stuck for some reason. Or maybe it took all of 20 minutes to install? In any case after restarting the PC and it’s now showing that 4.4.1 is installed on the NAS and the client is connected too. Whew. Another non-fatal upgrade is behind me!
Complaining, complaining complaining complain compla comp com com co ccccccccc
I’m getting a little *bleghhhh* about all the complaining….
YES it is annoying to see the icon missing in the tray and knowing what it means.. the updated the package and now my backup is stopped…… It means troubleshooting, AGAIN….
Yes, Crashplan does not support the headless NAS solution. But after all it is a backup solution for desktops, and not made to backup several Tb of storage from a NAS, on the contrary it is rather cheap..
Yes, It is very memory unfriendly with very large backups… But if you split those backups in smaller portions, you can still manage to backup >3Tb with 1528Mb of heap size.
Yes, They screw up our backups when they push again an update. But after the update, check the parameters, .ui_info; still both the same ID? Is the IP adres still in the configuration of the client? Did you start-stop-start the engine on the NAS? Did you check the Crashplan wiki? Is there in the headless config a change in the settings they mention you should change (yes, the new IP adres in the .ui_info is not mentioned yet, thats their flaw)? Did you check the previous posts of the other users? Yes there are many posts, but pfew.. I see all answers come by every 20 or 30 posts…..
yes, you can complain that you have a lot of work to do updating 20+ clients, but then its not consumer anymore, think about another more business related backup solution… And Crashplan provides for that servers to backup to…
The grass is always better on the other side of the road..
yes, for some models iDrive has a Synology client, but still not everybody can enjoy it, because of the different processor models.
yes, they have a real cheap introduction for 1Tb the first year, but after that year… Or when going over that 1Tb limit…
Think positive, and do your troubleshooting solid, fundamental and focused.. Still problems? Post here your complete troubleshooting and the problem your facing, and maybe.. maybe there is a quick solution, else? Wait till Patters can update the package and install that one, and than again, check your parameters afterwards, they might have changed the UID or somethine else during the install……..
I want to do a big shoutout to all the work, troubleshooting, programming and making it available as a repository after all….
PATTERS!! Your doing a masterpiece of work, thanks!!!
Hear, hear!
The most useless comment, right after this one.
Thanks – I agree with what you wrote. CrashPlan is simply not intended to backup huge volumes of data, and it has been clear since the start that Code42 do not support headless NAS installs. This is very much at your own risk and yes, there’s a bit of work to do each time the product gets updated. Also with all this talk of iDrive remember that one of CrashPlan’s differentiators is its peer to peer functionality, which AFAIK the competing products lack. I think someone also mentioned that iDrive opens up port 80 via uPnP which would be reason enough not to use it if true.
I want an option to disable further updates! Would be kinda nice to get it to work, and then leave it in that condition for a while :-)
Not possible I’m afraid. It’s Code42 that pushes the updates to its software.
I hope you know complaining is merely frustration and not about the work and effort you put in it. For some people it’s just a bit of work, others try for days and then it still doesn’t work. Everyone has a different level of skills also. Anyway, I appreciate you have made this solution available to us. I have one month left to get it working again before my subscription ends. I will give it another try. And about Idrive; port 80 is one thing, but echo-ing the administrator password in the process list visible for everyone is ofcourse a huge nogo.
@patters: first of all again thanks a million for all your hard work!
It does seem to me it is possible to force CrashPlan not to accept upgrades, at least for a while. I am saying this because I am still running CrashPlan 4.3.3 (using version 3.6.3-0027 of your package) and in my log I have periodic entries like these:
I 10/05/15 02:48PM Upgrades available at central.crashplan.com:443
I 10/05/15 02:48PM Downloading a new version of CrashPlan.
I 10/05/15 02:48PM Installing upgrade – version 1435726800440
I 10/05/15 02:48PM Upgrade failed – version 1435726800440
However, this does not stop CrashPlan from merrily continuing to back up my files!
Of course, it remains to be seen how long CrashPlan will continue to accept connections from version 4.3.3 of their backup engine. As everything still works for me, I intend to wait and see what happens.
However, from the point of view of your package, if you are able to mimic the state I seem to be in by forcing the auto-pushed upgrade to fail, then your package would potentially be stabler. At the very least you would be buying yourself some time to investigate the next CrashPlan upgrade before your users start experiencing failures. Once you’re ready to support the next upgrade, you would update your repository; we would upgrade your package which would accept the waiting upgrade, while continuing to fail the next auto-pushed upgrade.
Hi,
so if I undrestand this correctly the backup engine (at least on Windows) is upgraded by Crashplan automatically and silently? If yes is there no way to prevent THAT from happening?
thanks!
After some trial and error with all the hints and tips, I have my Crashplan on Synology back up & running. Upgrade worked after installing Java 8 and restarting twice. Client connection by updating the .ui_info (not only the GUID, but also the 0.0.0.0 to the NAS IP) .
I’ve donated a little bit of money to show my support and gratitude.
I managed to update my Synology’s crashplan to version 4.4.1 after upgrading to Java 8. The Synology interface confirms the version number and says it’s running. However my client is not able to connect to the server.
I read through all the comments and I think I’ve properly modified all the files.
Contents of .ui_info in /var/lib/crashplan:
4243,be8478b1-fd36-4415-b2f9-3e430637c4f3,127.0.0.1
Contents of .ui_info in c:\programdata\crashplan:
4243,be8478b1-fd36-4415-b2f9-3e430637c4f3,192.168.0.22
Contents of ui.properties in Win7:
serviceHost=192.168.0.22
servicePort=4243
I’ve disabled the crashplan service on my Win7 machine and it didn’t help.
Did I miss a step?
Hmmm, that /var/lib/crashplan should end with 0.0.0.0 not 127.0.0.1. Did you definitely stop and start the CrashPlan package at least once (as per the instructions)?
I’m in the same position. I have definitely done several stop/starts and the .ui_info in /var/lib/crashplan does not have an IP of 0.0.0.0. I stop Crashplan, edit it with VI, start crashplan, and shortly after the guid has changed and the server IP has been restored.
It seems like something in crashplan is changing/restoring the values.
It is working, I just can’t get a connection from the client on my laptop
Does appear something on the server is resetting it :(
Server> echo `cat /var/lib/crashplan/.ui_info`
4243,80695c72-88e0-4222-9874-f3bc8cac317f,0.0.0.0
Server> echo `cat /var/lib/crashplan/.ui_info`
4243,80695c72-88e0-4222-9874-f3bc8cac317f,0.0.0.0
Server> echo `cat /var/lib/crashplan/.ui_info`
4243,80695c72-88e0-4222-9874-f3bc8cac317f,0.0.0.0
Server> echo `cat /var/lib/crashplan/.ui_info`
4243,80695c72-88e0-4222-9874-f3bc8cac317f,0.0.0.0
Server> echo `cat /var/lib/crashplan/.ui_info`
4243,cebc9777-4055-48cd-a523-2f39a3247519,172.16.0.10
I have the same issue, get different guid, and I have restarted and waited between each echo command . Running DS212j.
Stopping and restarting Crashplan changed the 127.0.0.1 to 0.0.0.0 and my client now connects properly. I must have forgotten to do this step this time.
Perhaps it’s expected, but for others who may run into this, when I stopped and restarted it, the GUID on the server side changed and I had to update my c:\ProgramData\CrashPlan\.ui_info file.
FWIW, my permissions for /var/lib/crashplan/.ui_info are set to 644 for anyone looking at permissions as a root cause of their issues.
Thanks Patters for the quick reply and awesome work.
One question: is it still necessary as off version 4.4.1 to read-only a file ( and if: which one is it exactly?) or is this tweak outdated?
Pingback: Crashplan on Synology Diskstation – successfully setting QoS DSCP values to de-prioritize upload traffic | Paul George
I finaly got it to work again!
– Follow the guide
– The server side .ui_info on the NAS neds to be changed from port,guid,127.0.0.1 to port,guid,0.0.0.0.
– .ui_info on the server side is read only so you need to log in to a ssh session as root and make it writable, chmod +rw. After that you need to edit the file to port,guid,0.0.0.0 using vi.
Thanks for a fantastic job on the crashplan package.
Best Regards Christian
Thanks Patters… I contributed to your paypal a couple days ago after venting my frustrations around Code42. I did try the free iDrive and it definitely feels a bit simple feature wise… I may still have to investigate it some more (I sent them a note asking about some intermediary pricing since it jumps from 1tb to 10th… they said to contact them directly about custom prices (for those interested). I am a bit nervous around some issues raised by folks related to passing around admin passwords and the like.
I went through and applied the latest package to my DS1515+ and made the changes on the mac. For those interested in a few tips (I always have to look this up), for ssh, you need to enable it on the DS. If you have a custom port (like 12345), then the nomenclature is ssh -p 12345 root@192.xxx.xx.xxx
On a Mac, in order to make changes to the hidden .ui file, you need to first be able to see it so you need to open terminal on the Mac and type
defaults write com.apple.finder AppleShowAllFiles YES [hit enter]
killall Finder [hit enter]
when you are done changing that file, just repeat above and change YES to NO
Hope this helps a few people.
Once again, thanks to Patters for updating the package and instructions. Mine is now scanning again after about a week. I so badly want to love Crashplan without reservation… We can, however, show love for Patters without reservation. He is a rock star.
Still struggling with some strange connection problems after the upgrade. 4.4.1. with java8
PC:: Cancelling connection attempt due to timeout – pending connection=PendingConnection[timeout(ms) = 5000,
Internal client who wants to connect to the NAS keeps saying: “Connecting to backup destination”. Console can connect normally from another client.
Anybody experiencing the same problem or knows the solution?
Amazon cloud drive and google cloud storage support are coming with multi-version backup feature with the all new DSM6.0 (though the release could be 6 month from now). So these will be natively supported by Synology as a Backup&Restore solution (They are supported now already but only with Cloudsync). I think this will replace Crashplan for me in the future.
Source: https://www.youtube.com/watch?v=0WFfz7lV4wM
What about security? What about encryption?
All Your data in direct access to NSA?
http://www.handelsblatt.com/global_edition_stories/safe-harbor-the-death-of-trans-atlantic-data/12414820.html
Europe’s highest court on Tuesday struck down a key legal principle that had enabled U.S. web giants to operate in the European Union and store and manipulate the personal data of people living there.
What about you haven’t watched the video I linked?
As I’ve gain so much help in from this forum, hope this helps anyone:
My Current setup:
DS1511+ – Upgraded to 3G Memory
DSM 5.2-5592 Update 4
Patter’s CrashPlan Version 4.4.1-0034
Patter’s Java SE Embedded 7 Version 1.8.0_51-0034
CrashPlan + 3 Version 4.4.1
Order of steps I took:
1. Stopped and Uninstalled old Patters Crashplan package and old Patters Java (7 at the time) package.
2. Updated DSM to version 5.2.5592 Update 4
3. Installed new Patters Java SE Embedded 8 Version 1.8.0_51-0034, and started it
– which requires ejdk-8u51-linux-i586.gz downloaded from Oracle and placed in DSM Public folder
3. Updated to Patters CrashPlan Version 4.4.1-0034
4. Made my three changes listed below using Putty to SSH as root into DS1511+
A. EDIT syno_package.vars
a. cd /volume1/@appstore/CrashPlan
b. vi syno_package.vars
c. Change “#USR_MAX_HEAP=512M” to “USR_MAX_HEAP=2944M” removing the # and bumping up to 2944.
d. Hit “ESCAPE” – “:wq” – “ENTER”
B. EDIT run.conf
a. cd /volume1/@appstore/CrashPlan/bin
b. vi run.conf
c. Change to “-Xms256m -Xmx2944m” on first line
d. Change to “-Xms128m -Xmx1024m” on second line
d. Hit “ESCAPE” – “:wq” – “ENTER”
C. EDIT CrashPlanEngine
a. cd /volume1/@appstore/CrashPlan/bin
b. vi CrashPlanEngine
c. Add lines (a couple of line above “# Common functions used for…”:
#Increase open files limit
ulimit -n 65536
d. Hit “ESCAPE” – “:wq” – “ENTER”
Steps B and C Patters says is redundant… but I dont want to jinx myself and change what worked for me :)
5 Started CrashPlan, then stopped it, then started it again
6. Updated the client (PC) side Crashplan to Version 4.4.1, by downloading and installing it onto PC
7. Located conf/ui.properties:
C:\Users\\AppData\Local\CrashPlan\conf
8. Updated the conf/ui.properties – and added the line “serviceport=4243” and “serviceHost=192.168.1.XXX” – where XXX was my DS1511+
9. Using Putty to SSH as root into DS1511+ : echo `cat /var/lib/crashplan/.ui_info`
10. Locate .ui_info and make changes : C:\Users\\AppData\Local\CrashPlan also adding “192.168.1.XXX”
for example : 4243,47a24b57-d10e-4af2-80b1-XXXXXXXXXXXX,192.168.1.XXX
note: I put the 192.168.1.XXX of my DS1511+… I’ve seen people say leave as 0.0.0.0, so I don’t know if it works because of it, or in spite of it.
I currently have 3.3TB uploaded spread out across 22 backup sets.
Hope this helps,…. and a thousand thanks again Patters!
As soon as I fund my Paypal… expect some thanks!
RAJ
Thank you Patters. Remember folks, he accepts donations. Send him $5 or $10 or more. His work helps us all save money because CrashPlan is one of the lowest cost services and without him, we’d have a hard time using it.
Yesterday i fixed it. I needed to change the 0.0.0.0 to my real Lan ip for it to work 192.168.1.140
BUT today, the string in the file ui_info was not the same (Had been resetted), so i had to redo the same thing with echo `cat /var/lib/crashplan/.ui_info` and add it to the file again. Strange that it “resettet” itself.
I am seeing the same thing. ui_info seems to change every day
My email exchange with code42:
Dear Code42,
Why won’t you support Crashplan on Synology NAS?
And worse, why do you seem to purposely and repeatedly crash the package from Patters on pcloadletter by pushing updates and changing little details?
I understand that backuping a several Tb NAS is less profitable for you than a 128Gb laptop… then why don’t you make a bit higher price for NAS users? I would be ready to pay for that!
130’000 people installed the (unsupported) Synology package. Is it really a market to turn your back to?
Meanwhile, if nothing has changed when my Crashplan suscription is over, I’ll definitely not renew it. Sadly.
Hello, Frederic.
Thank you for contacting Code42.
I appreciate your passion for your Synology device. The community around Synology is very devoted, that’s for sure!
However, CrashPlan was not designed for that architecture, and adding Synology to our product roadmap and QA cycles would be very disruptive to our development process. It just doesn’t make sense for us as a business.
Sorry it’s not the answer for which you were hoping!
Regards,
Adam
I think this is VERY simple why Code42 do no want to support NAS. How many people are out there with 4-10TB of hard disk space on their computer? What about NAS users?
NAS users would essentially be freeloaders on unlimited plans costing next to nothing to the subscriber and losing money to the supplier. It is really that simple!
To Leon’s comment about ui.info:
Yesterday i fixed it. I needed to change the 0.0.0.0 to my real Lan ip for it to work 192.168.1.140
BUT today, the string in the file ui_info was not the same (Had been resetted), so i had to redo the same thing with echo `cat /var/lib/crashplan/.ui_info` and add it to the file again. Strange that it “resettet” itself.
Is there any way to prevent this from happening – happened to me to and to have to run all the GUID steps and ui.info modification every time I launch the client seems unsustainable.
Any ideas or solutions?
Agreed. Seems to be resetting for some reason.
I have a DS413 and I’ve upgraded to the 4.4.1-0034 package but its currently crashing while trying to initialise the WatcherDriver with:
java.io.IOException: Platform is not supported, glib: unknown, kernel: unknown
anyone else run into this issue?
Successful update to 0034, seem to run correctly on NAS DS412+
Anyway, .uifile_info shows a different port number: 4249 instead of 4243.
I tried to update C:\ProgramData\CrashPlan\conf\ui_(username).properties with this port number to get something coherent between server and clien (aslo same port number in C:\ProgramData\CrashPlan\.ui_info) but no sucess to connect with the client.
I also tried to change port number in .uifile_info, but comes back to 4249 with new GUID…
any tip?
thanks
Finaly managed with my issue…
ServicePort given .ui_info from server is 4249 and not 4243… thus I set this port number in all related files on the client:
.ui_info
ui.properties
ui_(username).properties (for which I had to add new line for servicePort as it was missing)
0.0.0.0 IP adress set to my NAS IP adress
…works like a charm !
Thanks a lot for this development and good support.
Hello
Despite all the good recommendations found here (thank you all !), I cannot connect to my NAS using the Crashplan Client since I upgraded to version 4.4.1 on NAS and PC… I am getting on my PC when I start Crashplan a message saying “Logged out by authority. Incorrect login token”… strange as I followed Chris Nelson’s process to have the .ui_info file updated with the correct port,token and NAS IP address… Anyone has an idea ? Thanks