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

shoot… the XML got stripped out, but you get the idea.
I have a Synology DS212+ running the latest Crashplan Headless client.
When I run the following command:
netstat -an | grep ‘:424.’
I only see the NAS listening on 4243 and not on 4242.
I had this running successfully until a couple of weeks ago when crashplan decided to do an auto update. I just finished updating everything manually and can’t connect do to the NAS not listening on 4242.
Does anybody have any ideas what I might be missing?
Thanks…
I’ve just received my DS411 and decided to try out CrashPlan. After a few failed attempts at doing it myself (correcting scripts, finding missing lib files, etc.) I was just about to give up when I found the packages – great job, man!
Unfortunately something’s going on with my DiskStation that I still can’t get it to work properly… I’m running DSM 4.0 (2198), Java SE for Embedded 7 (also installed via the spk), with the 3.1 Toolchain for Marvell 88F628x. I’ve bootstrapped my machine following the instructions on the Synology Wiki.
After the CrashPlan package installed without errors, I ssh’d into DiskStation, stopped and restarted the service and, according to the logs, everything should be working fine – nothing on engine_error.log, “CrashPlanEngine status” reports as running, etc, – except that I can’t connect.
I tried changing the service host on my Win 7 Desktop application, tunneling using SSH and telnet’ing directly to no avail. After several tries, I ssh’ed to the DiskStation and telnet’ed itself from there – still getting connection refused.
Using netstat, I found out that only the 4243 listener (127.0.0.1:4243) is working – the Engine listener on port 4242, that should be bound to all interfaces, isn’t running at all. I’ve already:
1) Stopped / started the service again (via web interface and CLI);
2) Rebooted the DiskStation;
3) Reinstalled java, toolchain and crashplan;
4) Altered the my.service.xml (location tag) to bind to the actual IP and a different port;
5) Reinstalled DSM (ok, this was pretty extreme but I thought there might be leftovers from my previous attempts).
Any ideas on what could be going on (and how to get the 4242 listener up)?
Only start the service using the Package Center GUI. If you start it using the command line while logged in as root the daemon user won’t have permission over the log files etc. next time it runs. To fix that try
chown -R crashplan /volume1/@appstore/CrashPlanI have the same problem, run: chown -R crashplan /volume1/@appstore/CrashPlan without succes, no error and still no connection.
Which CPU type, which syno model, and which package please?
Tried chown -R … Did not work for me. Only 4243 is listening.
This all is since Crashplan did there update.
First the ds212j and now the D712+ and the
“Crashplan package” DSM4.0 latest version
Just tried again – only 4243 is up after starting via Package Center. I also chown’ed and restarted via CLI but no use.
My config is:
– DiskStation D411
– CPU Marvell Kirkwood mv6882
– DSM 4 (2198)
– Java SE 7
– Toolchain 3.1
– Crashplan package (standard)
Thanks!
Hi
Same issue here on DS411 / DSM 4 / CrashPlan 3.2-003 / Marvel Kirkwood mv6282 CPU
Did notice this in service.log.0
[03.25.12 21:26:08.845 INFO main com.backup42.service.CPService ] Config: ServiceConfig@2280049[ version=3, configDateMs=null, log
[03.25.12 21:26:08.846 INFO main com.backup42.service.CPService ] *************************************************************
[03.25.12 21:26:08.881 INFO main com.code42.utils.SystemProperties ] == MEMORY ; maxMemory=371.30MB, totalMemory=19.40MB, freeMemory=
[03.25.12 21:26:08.896 INFO main com.backup42.service.CPService ] uid: 0
[03.25.12 21:26:08.896 INFO main com.backup42.service.CPService ] gid: 0
[03.25.12 21:26:08.897 INFO main com.backup42.service.CPService ] pid: 14337
[03.25.12 21:26:08.899 INFO main com.backup42.service.CPService ] open files: cur=1024, max=1024
[03.25.12 21:26:08.930 INFO main com.code42.crypto.SecureRandomUtil ] SecureRandom instance CREATED.
[03.25.12 21:26:08.997 INFO main com.code42.queue.BackgroundWorkQueue ] BWQ-FileTransfer:: Initialized – numWorkers=1
[03.25.12 21:26:08.997 INFO main .common.filetransfer.FileTransferService] FT:: initialized – numWorkers=1, growthMaxWorkers=2
[03.25.12 21:26:09.003 INFO main .common.filetransfer.FileTransferService] FT:: Added module. client-logs -> log
[03.25.12 21:26:09.084 INFO main com.backup42.service.CPService ] Creating MessageProvider with options=MessageProviderOptions[nam
[03.25.12 21:26:09.109 INFO main com.code42.messaging.nio.MessageProvider] MessageProvider(): options=MessageProviderOptions[name = Peer, n
[03.25.12 21:26:12.326 INFO main 42.messaging.security.DHBlowfishProvider] DH: Initialized. Done generating algorithm parameters – time(ms)
[03.25.12 21:26:12.422 INFO main com.code42.queue.BackgroundWorkQueue ] BWQ-Security:: Initialized – numWorkers=1
[03.25.12 21:26:12.423 INFO main de42.messaging.security.SecurityProvider] SP:: SecurityProvider initialized. protocolVersion=1, symmetricA
[03.25.12 21:26:12.423 INFO main com.code42.messaging.nio.MessageProvider] Security provider-Peer: primary=PK, secondary=DH
[03.25.12 21:26:12.435 INFO main com.code42.messaging.nio.MessageProvider] MessageProvider(): Default Socket settings:
——————————————————-
Socket Details : Socket[unconnected]
——————————————————-
localPort : -1
port : 0
receiveBufferSize : 43690
sendBufferSize : 8192
soLinger : -1
soTimout : 0
trafficClass : 0
inetAddress : null
keepAlive : true
localAddress : 0.0.0.0/0.0.0.0
localSocketAddress: null
OOBInline : false
remotSocketAddress: null
reuseAddress : true
TcpNoDelay : true
[03.25.12 21:26:12.856 INFO main backup.watcher.ScheduledFileQueueManager] SFQM: Setting manualFileChangeCheckInterval=30000; ScheduledFile
[03.25.12 21:26:13.100 INFO main com.code42.messaging.nio.MessageProvider] MessageProvider(): options=MessageProviderOptions[name = UI, num
[03.25.12 21:26:13.158 INFO main com.backup42.service.ui.UIController ] Interface LISTENING on 127.0.0.1:4243
[03.25.12 21:26:13.199 INFO main com.backup42.service.CPService ] Not authorized, skip setting up backup layer.
[03.25.12 21:26:13.336 INFO main com.code42.queue.BackgroundWorkQueue ] BWQ-DefaultGroup:: Initialized – numWorkers=1
[03.25.12 21:26:13.337 INFO main com.code42.queue.BackgroundWorkQueue ] BWQ-DefaultGroup:: maxWorkers=2
[03.25.12 21:26:13.363 INFO main com.code42.peer.PeerGroup ] PG::DefaultGroup maxAttempts=2
[03.25.12 21:26:13.364 INFO main com.backup42.service.peer.PeerController] SocialNetworkModel has changed, updating peers.
[03.25.12 21:26:13.396 INFO main ckup42.service.peer.CPCAutoRegisterRetry] Create AutoRegister retry system check…
[03.25.12 21:26:13.398 INFO main com.backup42.service.CPService ] CrashPlanService started.
Any idea?
Thanks
Well, oddly enough it started listening on both 4242 and 4243 the next afternoon. I did not change anything during that time so I can’t explain why it started working all of a sudden.
I’ve moved on to being aggrevated with the performance of surveillance station.
;)
Hello,
I have uploaded more than 300GB with DSM 3.2/ Crashplan 3.0.3 on my DS411j thanks for this wonderful package.
Since the 3.2 Crashplan / DSM 4.0 updates however, crashplan seems unable to back up. It correctly detects the files, says “Backup running”, but is stuck on “Analyzing” and doesnt go further.
Any suggestion appreciated.
Hello,
I’ve got the same problem. I’m running DSM 4.0 with Crashplan 3.2:
To do: 4’330 files (10,3 GB)
Completed: 2,8480 (5,4 GB)
CP always stucks at the same point: “Backup running” / “Analyzing”. Then CP pauses until the next backup.
Interestingly enough, I am able to restore files… But not to upload them. What could be wrong ?
Is there any detail in the engine logs files?
– engine_error.log is empty
– history.log.0 shows:
……
I 03/25/12 09:15PM [Default] Starting backup to CrashPlan Central: 4,330 files (10.30GB) to back up
I 03/25/12 09:15PM [Default] Completed backup to CrashPlan Central in < 1 minute: 0 files (0MB) backed up, 0MB encrypted and sent @ 88 bps
I 03/25/12 09:15PM – Unable to backup 4,330 files (next attempt within 15 minutes)
….
The strange thing is, i can delete the backup, restart it and then it goes until 4,330 files remaining.
– engine_error.log is empty
– history.log.0 shows:
……
I 03/25/12 09:15PM [Default] Starting backup to CrashPlan Central: 4,330 files (10.30GB) to back up
I 03/25/12 09:15PM [Default] Completed backup to CrashPlan Central in < 1 minute: 0 files (0MB) backed up, 0MB encrypted and sent @ 88 bps
I 03/25/12 09:15PM – Unable to backup 4,330 files (next attempt within 15 minutes)
….
The strange thing is, i can delete the backup, restart it and then it goes until 4,330 files remaining.
Not sure, but have you tried to talk to Crashplan about it?
There is a lot of problems with the 3.2 version: http://support.crashplan.com/doku.php/3.2_known_issues
Hard to tell if its the Syno package or 3.2
I had a similar problem with a few files, but I found out that the crashplan user didn’t have read access to the files. I changed the file permissions to allow crashplan read access and then the files went. Have you checked to see if the crashplan user can read the files that aren’t backed up?
From the “Notes” above;
– The engine runs as the user “crashplan”, so make sure this user has access to the folders you want to backup.
So far I haven’t talked to CP about this. I tried to uninstall CP and Java, reinstall and create a new profile. Backup works fine!!! Now I am trying with my real profile, it is adopting the old computer. Usually takes around 1 day given large number of files, so I’ll see tomorrow if it works
If we have installed Java as per Kenneth Larsson’s blog on setting up Crashplan, do we need to remove it before installing the Java SE package? Or can we just install the Java SE package as is? Thanks!
You probably ought to. You can find out where it installed Java to by running:
echo $JAVA_HOMEDelete that folder, then remove the bit where JAVA_HOME is defined in the file /etc/profile.
You should also remove any mention of that Java folder where it has been appended to the PATH variable in /etc/profile.
I don’t have an Intel NAS so I can’t test this out for you though.
DSM 4.0 wanna force me to update Crashplan, whats new in the package?
https://crashplan.zendesk.com/entries/21184682-software-update-scheduled-for-monday-evening-march-26
Maybe they manage to fix the errors lots of people have now.
And Crashplan autoupdated itself again….
AND… it stopped itself again without being able to start again :(
Patters…. HELP ;-)
03/27/12 05:36AM Upgrades available at ega-msp.crashplan.com:443
03/27/12 05:36AM Downloading a new version of CrashPlan.
03/27/12 05:37AM Download of upgrade complete – version 1332824401321.
03/27/12 05:37AM Installing upgrade – version 1332824401321
03/27/12 05:37AM Upgrade installed – version 1332824401321
03/27/12 05:37AM CrashPlan stopped
Same here… I’m getting annoyed at CrashPlan now for two updates in the same week or so lol.
Any way to exclude backup of @eaDir – folders? Im not sure for what reason I should have backup of those dirs…
CrashPlan Pro have an “Filename patterns to exclude” under “Settings”.
I think CrashPlan Home have that option too.
Havent tried it yet.
Yes this works.. I also configured it like this…
An update kicked in today (1332824401321) and now CrashPlan won’t run.
Thoughts?
Its because the headless Linux client dont autoupdate, so we have to waith for Patters to update the package and then update the client.
CrashPlan request that the server and client be the same version to work.
An normal desctop client autoupdate.
Psss. Svein;
the headless client DOES update… but the client will nog start anymore now…
Log:
03/27/12 05:36AM Upgrades available at ega-msp.crashplan.com:443
03/27/12 05:36AM Downloading a new version of CrashPlan.
03/27/12 05:37AM Download of upgrade complete – version 1332824401321.
03/27/12 05:37AM Installing upgrade – version 1332824401321
03/27/12 05:37AM Upgrade installed – version 1332824401321
03/27/12 05:37AM CrashPlan stopped
It does? ok, maybe Crashplan was yust talking about turning that off, because it usaly makes problems even on full Linux Servers.
But I guess we still need to waith for Patters to update to fix it :)
Maybe the auto update search for some paths that dont exist on the Synology install or something.
I have mine start from cron nightly to do backup and it auto-updated last night. Now when you try to start from cron it complains of a missing jar file that Sam has mentioned up in the thread somewhere (“Could not find JAR file /opt/crashplan/bin/../lib/com.backup42.desktop.jar”), so we probably need another update from Patters.
If it helps, here is the only line in the engin_error.log that I have:
log4j:ERROR Attempted to append to closed appender named [null].
Thanks
My CP updated last night and the service will not start. I get the following error in the engine_error.log
log4j:ERROR Attempted to append to closed appender named [null].
I only installed CP for the first time yesterday. The service started after the initial install but I did not connect to it with the GUI client so I cannot confirm it was working properly. When I tried to connect this morning using the client (which failed) i noticed the upgrade and the fact that the it was not running.
I’m on it…
YOUR GREAT Patters!!
Im in the same situation as DarrinBM (although I had crashplan 3.0.3 on it before via another way).
Im amazed to see how fast patters is on it ;-)
Ok, the ARM CrashPlan 3.2.1 package is on the repo. I’ll update the other builds now…
In a similar situation. I uninstalled CP and tried to reinstalled it (I believe it is the new package on the repo), I got the error message “The operation failed. Please log in to DSM again and retry”
Don’t uninstall it – you’ll lose all your setup and have to adopt again. The package is upgradable. If you click Refresh in Package Center it will show you an update button on the package if a newer version is available.
EDIT – I just checked on a DSM 3.2 system and it looks like the update isn’t offered :(
Looks like that version of Package Center doesn’t like the version numbering.
EDIT2 – It’s also not showing on DSM 4.0. The version numbering detection seems a little buggy…
Sorted, thank you very much for the quick response!!
Is the intel package also updated?
(cannot see it yet, dsm 4.0 DS1812)
Very strange. The CrashPlan and CrashPlan PRO packages for ARM & Intel are all updated. However, it seems that Package Center doesn’t notice an update is available going from version “3.2-003” to “3.2.1-004”. The addition of that extra decimal messes things up for some reason. I don’t recall that being a problem for the various Serviio packages I have made (0.6 -> 0.6.1 and so on).
I have circumvented the issue by giving the repo slightly different version data (3.2-004 instead of 3.2.1-004). The side-effect will be that you’ll get a continuous Update badge showing even after the update. I’ll leave it like that for a few days until most people have upgraded, then I’ll set the repo back to the true version number. Irritating I know…
CrashPlan PROe did not get an update btw.
As far as I know, PROe is on an quite different update cycle. The current version have been out for ages. I know they are working on an new version but no one knows then it will be out.
I wil switch to CPHome sooner or later, because the PROe is an test for work (Im supposed to pay license pr computer that runs the PROe software, but I don’t) but I think I wil wait til I have tested PROe on sinology for at least an week. And since its so many problems with the Home edition now, I think I wait til Code42 have sorted them out…hehe.
Using the crashplan headless client on my syno, everything worked fine for a week, then stopped uploading for some reason and the package “stopped” and wouldnt “run”. So I re-installed and adopted my box over again. Now the syno package is saying an update is available seconds after re-installing?
Is this a real update? im confused. I installed it, 2 minutes later theres a new update? coincedence?
See my comment just a bit further up the page from this one. There’s a problem with Package Center not detecting the version update unless I fiddle the values in the repo. So you only need to update once. If you’re on 3.2.1 then you’re on the latest.
So I keep getting a “failed to download” when I try to update from 3.2-003 to 3.2-004 even after a restart. Any ideas, patters.
By the way, thanks for being so on top of the updates, we all appreciate it!!!
Which CPU arch, intel? And which version of the package (normal or PRO)?
I am on an Intel NAS (1511+) using the normal package…sorry about not including that before. I will also add that after the “failed to download” message comes another message that says “Crashplan: Broken.”
i shouldn’t have uninstalled, but now that i have, how do i re-install it. Every time i try to install it, I get the error “Operation Failed” – are there files i need to delete? even after a restart and a install i still get this error. please help, i do appreciate your effort.
Ran the update package , but still in package centre the Update notification is there ? DS1511
Still have a problem I cant connect 100% have to open a ssh tunnel to do so
Crashplan user has access to filesystem
Let me know if you need additional logs etc :)
Thanks
Hi
I have an issue that I haven’t seen above: my service on port 4242 is not starting but I have noticed that my DS411 does not seem to be recognized. In the following of the service.log.0 file I replaced the guid number with stars.
My setup: DS411 / DSM 4 / “your” CP 3.2.1 / Java 7
[03.27.12 19:30:04.082 INFO main com.backup42.service.CPService ] **** LOAD MODEL ****
[03.27.12 19:30:15.455 INFO main com.backup42.common.User ] Legacy User: Setting username from email=null
[03.27.12 19:30:16.417 INFO main com.backup42.service.CPService ] DEAUTHORIZE – Invalid model! My computer not found for guid=****************, loggingIn=false, reauthorizeError=null
[03.27.12 19:30:16.419 INFO main com.backup42.service.CPService ] DELETED file=conf/service.model
[03.27.12 19:30:16.432 WARN main com.backup42.service.CPService ] FAILED to delete file=conf/service.login
[03.27.12 19:30:16.445 WARN main com.backup42.service.CPService ] FAILED to delete file=/volume1/@appstore/CrashPlan/conf/import_key
[03.27.12 19:30:16.457 WARN main com.backup42.service.CPService ] FAILED to delete file=conf/service.copier
[03.27.12 19:30:16.473 INFO main com.backup42.service.CPService ] CACHE DELETED cacheDir=/volume1/@appstore/CrashPlan/cache
[03.27.12 19:30:16.482 INFO main com.backup42.service.ComputerUniqueId ] CHANGE COMPUTER IDENTITY! GUID reset but not changing. guid=**************, reason=Invalid model! My computer not fo
[03.27.12 19:30:22.240 INFO main com.backup42.service.CPService ] **** LOAD MODEL ****
[03.27.12 19:30:22.571 INFO main com.backup42.service.CPService ] Model valid for GUID ******************
[03.27.12 19:30:22.597 INFO main com.backup42.service.CPService ] GUID is *******************
[03.27.12 19:30:22.597 INFO main com.backup42.service.CPService ] NOT AUTHORIZED
[03.27.12 19:30:22.598 INFO main com.backup42.service.ComputerUniqueId ] ComputerUniqueId.guid=*****************
[03.27.12 19:30:22.599 INFO main com.backup42.service.ComputerUniqueId ] ComputerUniqueId.authDate=null
[03.27.12 19:30:22.599 INFO main com.backup42.service.ComputerUniqueId ] ComputerUniqueId.username=null
[03.27.12 19:30:22.631 INFO main com.backup42.service.ComputerUniqueId ] ComputerUniqueId.securityKeyType=AccountPassword
running a netstat on the DS1511 …nothing running on port 4242 only port 4243 active
tcp 0 0 127.0.0.1:4243 0.0.0.0:* LISTEN
Hi Kevin
Thanks for the info. Was desperately looking for service on port 4242 before connecting the Desktop. It turns out that 4242 only is used to exchange with the desktop.
Issue solved, thanks.
Dude, that was it! I’ve been stuck with the whole 4242 not showing up on netstat that I didn’t even try to connect using the client. I just did and now everything is working – hurray!
Installed the 3.2.1 -004 upgrade no problems, working fine here. Did notice the upgrade icon is still highlighted in the package center under CrashPlan.
I have updated again to correct that update badge issue. The new version number starts with 3.2 but it is in fact using CrashPlan 3.2.1. It’s just that Package Center seems to dislike switching from a single decimal point number to a number with two of them. I fixed a stupid typo that was preventing the updated CrashPlan PRO from working at all. I also made a few things a bit more intuitive:
. On a fresh install you get reminded to restart the package a second time to allow remote client connections
. If you upgrade the package in Package Center, a second restart is no longer necessary (I preserve conf/my.service.xml), so the client can be connected immediately
. The CrashPlan daemon’s network binding is forcibly reset to 0.0.0.0 each time the package is started (since some people reported it mysteriously resetting to 127.0.0.1 occasionally).
I updated CrashPlan PROe to bring the package up to date with these changes.
Thanks for the updates, that fixed the problem for me…no more “failed download.” I definitely appreciate it. Keep up the great work!!!
Fantastic work patters !
You deserve a medal, really !
A medal? Or a donation more like. Mine is coming right up after surviving the first update.
Crashplan should make synology support official…
Thanks :)
Out of interest: 923 uniquely IP addressed Synos checked in with the package repo yesterday. Judging from the size of the log files, it’s usually a little more. It’s frustrating that Dropbox doesn’t offer download stats – I have no way of knowing how many downloads each of the individual packages gets.
I am in 3.2.1-004 and everything is working fine. Is it a problem if I dont do the -005 upgrade ? If it ain’t broken, don’t fix it… or is there an issue if I dont update ?
It’s up to you. It won’t harm it either way. Both are running the 3.2.1 version of CrashPlan.
After going through the second crash plan update and this time being able to use your update function in the packet manager, the crash plan client shows after reauthorization a text box saying: Real-time File Watcher Disabled…
I don’t remember this box from earlier versions – did I miss something?
Are you on Intel? Someone reported something similar a while back but I don’t think it affects everyone. I could be wrong though. I only have an ARM syno so I can’t test (I’ve never seen that on ARM).
There’s some info about troubleshooting real-time backup here:
http://support.crashplan.com/doku.php/client/troubleshooting/real-time
Can you tell me the current value on an Intel system if you run:
cat /proc/sys/fs/inotify/max_user_watchesOn ARM systems it’s 102400, and I had made the assumption that it would be the same on Intel.
Yes, it is a DS2411+, which is Intel-based. The value is 102400 too, so your assumption was correct.
And now, after connecting from a different computer to the synology, this messages is not shown any longer… will keep an eye on it, time will tell, if it has to do full system scans or gets notified on file changes…
I do not believe the file watcher ever worked on Synology:
http://forum.synology.com/wiki/index.php/CrashPlan_Headless_Client#Real-Time_Backup
The new message CrashPlan displays I believe is just a new feature in 3.2.x telling you that it cannot use the file watcher.
I find that Wiki frustrating. The whole point of a Wiki should be that anyone can sign up and contribute, but it’s private and locked down. Right at the beginning of my experiments with my Syno I discovered how to include package icons, back when none of the info ‘out there’ mentioned this, and no other 3rd party packages had icons. I wanted to share this discovery and couldn’t post on the package wiki. I even asked on the Synology forums for a login and got no response.
It seems that many people are finding the CrashPlan installation page on the wiki and, because it looks like an official Synology thing, are assuming that it’s the suggested way to install CrashPlan. So novice Linux users end up making all these changes to their systems and then get completely stuck when an update comes along or they want to uninstall it (no guide for that on the wiki!), and they’re understandably frustrated when they discover they could have just used my single click installation package. And I can’t even edit the wiki to mention the existence of a CrashPlan package.
Anyway, back on topic – inotify support. With the ARM version of CrashPlan that I use, I have the real-time protection box ticked in the Settings menu, and when I change stuff in the folders I back up it gets noticed and synced to CP Central within 15 minutes, which would seem to imply that it does work. I definitely get no errors or messages about real-time protection failures in either of the engine logs. Are you saying that on Intel your changes only get synced after the full scan at 3am? Or is ‘real-time’ supposed to mean instant replication with no 15 minute intervals?
One thing that might account for an ARM/Intel difference is that the ARM version has a recompiled libjnidispatch.so which is included in jna-3.2.5.jar (JNA is Java Native Access, and it’s mentioned in Richard’s error log he posted earlier). See this guide for more detail:
http://www.opticality.com/blog/2011/07/16/installing-crashplan-on-a-pogoplug-pro/
This might be a crucial file for inotify support, and maybe the stock Intel one provided by CrashPlan isn’t right for the glibc and kernel versions used for DSM. It would be great if someone was able to test including the amd64 libjnidispatch.so binary available at the bottom of this page:
http://packages.debian.org/sid/libjna-java
You would need to extract it from the .deb package using the method here:
http://www.markinthedark.nl/news/ubuntu-linux-unix/88-install-playstation-media-server-pms-on-a-synology-nas.html and pack it into jna-3.2.5.jar as per that pogoplug guide.
It still comes up with the error on my intel based DS:
[03.29.12 17:30:41.353 WARN W27750143_ScanWrkr com.code42.backup.path.BackupSetsManager] BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel:
com.code42.exception.DebugException: BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:407)
at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(BackupSetsManager.java:330)
at com.code42.backup.path.BackupSetsManager.access$1600(BackupSetsManager.java:65)
at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(BackupSetsManager.java:1035)
at com.code42.utils.AWorker.run(AWorker.java:158)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:40)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:392)
… 5 more
Patters,
Indeed my changes are notice on the moment a full scan comes by. For my crucial folders I made the scan come by every 30 minutes now.
The realtime protection box is still checked, but does nothing.
I am willing to test the possible solution, but I have no idea how to do it.. The extracting and packing in a new package or something sounds to me like magic… (to little linux knowledge on my side, and the info pages you mention have to much different info)
Tell me what to do, and I’ll test it right away ;-)
Ah, ok. So it sounds like the Intel version has never worked properly whereas the ARM one is just fine. It’s highly likely to be that library then. I’ll have a look at it later today hopefully and make a new JNA jar file for you to try.
That sounds nice Patters. Keep me posted
Also please provide me a way to “roll-back”. Just in case of it will mess up the total crashplan ;-) (or is a simple reinstall a good way to roll-back in case of emergency?
Try applying this update manually in Package Center (it should upgrade your existing install).
http://dl.dropbox.com/u/1188556/crashplan3.2-x86-006-beta.spk
I have included replacement libjnidispatch.so for both amd64 and i386 in jna-3.2.5.jar and included libffi.so.5 which that library depends on (as in the ARM package). One thing I’m not sure about is whether I need to use the amd64 or the i386 build of libffi. I put both in the package, and the symlink in /lib will be created to link to the 32bit library.
Try it and see if it works. If it doesn’t, then perhaps it will need the symlink changing over to point to the 64bit library. Let me know…
If you want to regress back to the current release version you should find that Package Center offers you the Upgrade button (it can’t seem to tell wether the version is less then or greater than – if it’s different, then it’s offered as an update).
Patters,
It will not connect to the crashplan servers anymore: connecting to backup destination.
And in engine_output.log it comes up with: Exception in thread “W8036743_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:21)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:392)
at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(BackupSetsManager.java:330)
at com.code42.backup.path.BackupSetsManager.access$1600(BackupSetsManager.java:65)
at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(BackupSetsManager.java:1035)
at com.code42.utils.AWorker.run(AWorker.java:158)
at java.lang.Thread.run(Thread.java:662)
I mean the Engine_error.log
And rolling back with the update button does not work, because the update button will not appear ;-)
In Service.log.0 it comes up with a large error:
[03.30.12 13:10:56.714 ERROR main backup42.service.backup.BackupController] Exception setting up BackupController! java.lang.NoClassDefFoundError: com/sun/jna/Library, java.lang.NoClassD
java.lang.NoClassDefFoundError: com/sun/jna/Library
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)
at com.code42.jna.PlatformFactory.getLinuxPlatform(PlatformFactory.java:41)
at com.code42.jna.inotify.InotifyManager.(InotifyManager.java:45)
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:21)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:392)
at com.code42.backup.path.BackupSetsManager.setUp(BackupSetsManager.java:128)
at com.code42.backup.BackupManager.setUp(BackupManager.java:140)
at com.backup42.service.backup.BackupController.setUp(BackupController.java:415)
at com.backup42.service.CPService.start(CPService.java:472)
at com.backup42.service.CPService.main(CPService.java:1622)
Caused by: java.lang.ClassNotFoundException: com.sun.jna.Library
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
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)
… 21 more
Can you try:
[ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5 && ln -s /volume1/@appstore/CrashPlan/bin/libffi64.so.5 /lib/libffi.so.5…which will tell it to use the 64bit libffi. If the error is the same, no need to post it.
To go back to the working version, either remove and reinstall, or to upgrade you can edit the file /var/packages/CrashPlan/INFO and set the version number to a lower number (like 3.2-003). Then reload Package Center and you’ll be offered the upgrade.
Patters,
I’m sorry to say, but the error stays the same. Even after trying the commandline you mentioned.
I reverted to the 005 version, and it works instantly again!
(backup, not the realtime)
Can you try this one? The difference is that I’ve compiled libffi for Intel myself this time, using a Ubuntu VM and it seems a lot bigger (which would seem to indicate that the last version I included wasn’t right):
http://dl.dropbox.com/u/1188556/crashplan3.2-x86-006-beta2.spk
I also found some other old guide for ARM CPUs in which the guy got the same reported inotify error message you got before he had realised that libffi was required, so I’m hopeful this may work.
Patters,
Tried it again. It looks ok, but unfortunate it is not :(
-After installing and starting, when connecting with the client, i have to give my account details, I don’t get further anymore :S
It keeps on coming up with a red error: Unable to connect, check your network. (after installing the -005 version againit works instantly again.
-The engine error log stay’s empty
-The service_log.0 gives 3 warnings (the x’s are replacements):
[04.01.12 12:05:40.068 WARN QPub-DefaultGroup com.backup42.service.peer.PeerController] Closing connection to unknown peer, peerId=xxxxxxxxxxxxx
[04.01.12 12:05:40.070 WARN MQ-Peer-3 com.code42.nio.net.Connection ] MessageConnection caught Disconnected: The connection is closed! Ignoring outbound buffer request! MessageConnection[ sessionId=xxxxxxxxxxxxxx, readBuffer=com.code42.messaging.nio.MessageConnection$MessageBuffer@145e5a6, maxBufferSize = 1048576, currentSize = 0, enqueued = true, #items = 0, Connection[31983457, state=0, context
[04.01.12 12:05:40.071 WARN MQ-Peer-3 com.code42.peer.IdentifierAgent ] IdentifierAgent: MessagingClosed while sending IdentifierResponseMessage to [xxxxxxxxxxx@0.0.0.0:4242]
After a few more tries, I cannot connect with the old version too. Maybe there’s something going on at Crashplan from what I cannot connect right now..
I will test it once again when I am able to connect again..
I got it working again to log in…
But the problem with the error of March 30, 2012 at 12:09 is back again.
Exception in thread “W30940873_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
Ok. Thanks for testing. I’ll let you know if I have any other ideas. I guess I really need an Intel syno test machine.
I have made a new version. That beta2 version was unfortunately the same as the first due to a stupid oversight building the package. However, I don’t think I compiled libffi properly in any case. This one is definitely compiled using the syno toolchain, and linked against the syno glibc version:
http://dl.dropbox.com/u/1188556/crashplan3.2-x86-006-beta3.spk
Patters, goodmorning!!
Tried this morning the beta3, but the error is still the same :(
What result do you get if you run:
uname -rIs it kernel 2.6.32.12? Just wondering because apparently CrashPlan doesn’t support inotify on kernel 3.0.
It comes with version 2.6.32.12
@patters: Here is some info why no one can edit the wiki:
http://forum.synology.com/enu/viewtopic.php?f=115&t=37371
Just a new note on Crashplan for Synology.
After these recent updates I was having a heck of a time getting CrashPlan to work properly again.
It turned out my problem was CrashPlan was running out of java heap space.
I had to set my Xmx=512 to Xmx=1024 in ../crashplan/bin/run.conf
CrashPlan is now working properly again and using ~700MB of memory on my 1GB DS1010+
It may be because my backup is large, at 6.3TB currently and still growing.
Thanks for the tip!!
Crashplan on my DS1511+ has been restarting continuously ever since the update, and your tip on increasing the heap space seems to fix it all!
(I also have 5+TB & > 750000 files)
Help …been trying this for a few days now and was getting somewhere but only via SSH tunnel now going backwards :D
– Background DS1511, java 1.6.030 is installed
I have updated to the latest package and cannot connect either directly by changing the ui.properties or via SSH tunnel .
Looking at the NAS and running a netstat returns nothing on 4242 or 4243 even though the package is running in synology.
changing my.service.xml keeps going back even after restarting the package !!
From my.service.xml ‘excerpt ‘
3600000
<fileHandler append="true" count="10" level="ALL" limit="512000" pattern="lo
900000
CONSUMER
true
0.0.0.0:4242
STILL_RUNNING
NORMAL
false
IOPOL_THROTTLE
127.0.0.1
4243
Engine Output log
cat engine_output.log
[03.29.12 16:55:20.422 INFO main root ] Locale changed to English
[03.29.12 16:55:20.425 INFO main root ] *************************************************************
[03.29.12 16:55:20.426 INFO main root ] *************************************************************
[03.29.12 16:55:20.426 INFO main root ] STARTED CrashPlanService
[03.29.12 16:55:20.430 INFO main root ] CPVERSION = 3.2.1 – 1332824401321 (2012-03-27T05:00:01:321+0000)
[03.29.12 16:55:20.431 INFO main root ] LOCALE = English
[03.29.12 16:55:20.433 INFO main root ] ARGS = [ ]
[03.29.12 16:55:20.433 INFO main root ] *************************************************************
[03.29.12 16:55:20.744 INFO main root ] Adding shutdown hook.
[03.29.12 16:55:20.749 INFO main root ] BEGIN Copy Custom, waitForCustom=false
[03.29.12 16:55:20.749 INFO main root ] NOT waiting for custom skin to appear in custom or .Custom
[03.29.12 16:55:20.750 INFO main root ] No custom skin to copy from null
[03.29.12 16:55:20.750 INFO main root ] END Copy Custom
[03.29.12 16:55:20.765 INFO main root ] BEGIN Loading Configuration
[03.29.12 16:55:20.919 INFO main root ] Loading from default: /volume1/@appstore/CrashPlan/conf/default.service.xml
md5 Loaded.
[03.29.12 16:55:21.223 INFO main root ] Loading from my xml file=conf/my.service.xml
[03.29.12 16:55:21.379 INFO main root ] Loading ServiceConfig, newInstall=false, version=3, configDateMs=null, installVersion=1332824401321
[03.29.12 16:55:21.380 INFO main root ] OS = Linux
[03.29.12 16:55:21.618 INFO main root ] AuthorityLocation@23738549[ location=central.crashplan.com:443, hideAddress=false ]
[03.29.12 16:55:21.622 INFO main root ] END Loading Configuration
DELETED file=conf/service.model
FAILED to delete file=conf/service.login
FAILED to delete file=/volume1/@appstore/CrashPlan/conf/import_key
FAILED to delete file=conf/service.copier
CACHE DELETED cacheDir=/volume1/@appstore/CrashPlan/cache
[03.29.12 16:55:22.878 INFO main root ] BEGIN Loading Configuration
[03.29.12 16:55:22.879 INFO main root ] CpsFoldersMigrate is not necessary. /volume1/@appstore/CrashPlan/conf/my.service.xml file does not exists.
[03.29.12 16:55:22.880 INFO main root ] Loading from default: /volume1/@appstore/CrashPlan/conf/default.service.xml
[03.29.12 16:55:22.921 INFO main root ] Loading ServiceConfig, newInstall=true, version=3, configDateMs=null, installVersion=1332824401321
[03.29.12 16:55:22.922 INFO main root ] OS = Linux
[03.29.12 16:55:22.922 INFO main root ] Initializing backup paths last modified to now. lastModified=1
[03.29.12 16:55:23.004 INFO main root ] AuthorityLocation@4205299[ location=central.crashplan.com:443, hideAddress=false ]
[03.29.12 16:55:23.061 INFO main root ] END Loading Configuration
jtux Loaded.
ui.properties file (Mac) /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties
only the service host is pointing to the NAS IP address everything else is commented out
If you need more info then let me know
Thanks in advance
Did you activated the home-drives for the users?
control-panel -> user -> user home button..
Do you have the firewall on NAS turned on? I had to open ports 4242 and 4243 on the firewall in DSM to connect from a desktop client. You should be able to specify the IP address(es) of your client machines if you don’t want to open it up to every one.
Thanks
User Homes are activated
FireWall has access allowed on all ports (default) no ports are restricted :)
screenshot of the my.service.xml (the interesting bit) since the comment got eaten up originally
http://crmtechnik.clarify-it.com/d/2gdmf2
User Homes are activated
FireWall has access allowed on all ports (default) no ports are restricted :)
And now by magic !! I am now connected without ssh tunnel . Adopted previous backup and off we go .
Thanks for the additional support there guys .
@patters small donation coming your way as appreciation for the package and support
Hi Patters,
First of all, thanks for this package and for your quick replies in the comments. Even with my limited IT knowledge (never done linux before, made an SSH connection or anything similar), I was able to get CrashPlan running on my Syno.
One annoying issue though: everytime I come home and want to fire up my crashplan GUI on my laptop to check out backup status, it is not able to connect to the crashplan service on the NAS. I can connect to the NAS itself, but the crashplan GUI gives me the “cannot connect” error talked about above by many people. Interestingly, stopping and starting the crashplan service on the NAS fixes the issue. Any idea on what might be wrong?
For some people (I think on Intel only) the IP address binding was periodically being set back to the default value of 127.0.0.1. This means you would only be able to connect a client if it was actually running on the Synology machine. Since the client connects from a remote machine we need to have the service listening on all interfaces (0.0.0.0). I don’t know what would cause this resetting behaviour but to avoid people having to edit the config manually I decided to have the package’s start script make this edit to the config each time. This is why the problem is fixed for you each time you restart the package. It would be better of course to figure out why it’s being reset. However, I don’t have an Intel syno…
Thanks Patters. Later this weekend I’ll try to make sense of the earlier comments related to this issue and see whether I can confirm that this is the issue. I am on a DS210j though, so on ARM, so it is not an Intel issue. I’ll be back to you.
Hi Patters,
it worked fine for a while – but just today I got connection errors again that could only e solved with restarting the service. The annoying thing is that restarting the service seems to cause the service to re-index my whole backup folder.
Any idea on how to deal with this?
I’ve having a bunch of problems getting these packages to work correctly. I used to run crashplan the old way but recently decided to give this a try when 3.2 came out. I have a ds411+ii. The first issue seems to be with the java package. It doesn’t seem to detect the file in the correct place. You can see the details here: http://screencast.com/t/CzDy2InYIzWA
If I run the install script by hand, everything installs correctly. I only revisted this today since the Crashplan package update said it was successful but doesn’t seem to have actually installed anything and I wondered if it was due to some package dependency that wasn’t fullfilled.
I uninstalled and reinstalled the Crashplan bundle and while it says it’s successful, I can’t find the binaries anywhere on the system. Where can I look to help figure out what’s wrong?
Not sure about this. Have a look at the part of the Java package script that looks up the actual folder path of your ‘public’ share (line 15 in preinst). Based on the error message it does look to have located it correctly though. It takes it from smb.conf. Have you disabled SMB perhaps, and maybe the path in smb.conf is no longer accurate?
The CrashPlan binaries would normally end up in /volume1/@appstore/CrashPlan (volume1000 in your case). Something about your environment is confusing my scripts though, and I’m not convinced that volume1000 makes any difference.
/usr/syno/etc/smb.conf has public defined and I can access it over the network. I tried to figure out why the bash file isn’t detecting the presence of this file and ultimately gave up. That was when I bypassed the script and called it myself and everything worked ok. So it’s just the preinst script that is failing, specifically here I believe:
[ -f ${JAVA_PICKUP}/${JAVA_BINARY}.tar.gz ] && JAVA_BINARY_FOUND=true
I can’t tell why though.
This is mostly a curiosity at the moment, it appears that the crashplan package itself is just giving up and not installing the crashplan binaries.
Here’s what I get after an install:
DiskStation> pwd
/var/packages/CrashPlan/etc
DiskStation> cd ..
DiskStation> ls
INFO enabled etc scripts target
DiskStation> ls -lah
drwxr-xr-x 3 root root 4.0K Mar 30 16:36 .
drwxrwxrwx 10 root root 4.0K Mar 30 16:36 ..
-rw-r–r– 1 root root 12.3K Mar 27 19:11 INFO
———x 1 root root 0 Mar 30 16:37 enabled
lrwxrwxrwx 1 root root 32 Mar 30 16:36 etc -> /usr/syno/etc/packages/CrashPlan
drwxr-xr-x 2 root root 4.0K Mar 30 16:36 scripts
lrwxrwxrwx 1 root root 31 Mar 30 16:36 target -> /volume1000/@appstore/CrashPlan
DiskStation> cd etc
DiskStation> ls
DiskStation> cd ..
DiskStation> ls
INFO enabled etc scripts target
DiskStation> cd target/
DiskStation> ls
bin install.vars
DiskStation> ls bin
btw, where can I download the package directly? I haven’t seen the url or a reference for what the layout of a package repo is so I can figure out how to wget it. I figure i can walk through each script until I see what’s up.
Now I’ve had a think – the CrashPlan installer used to be downloaded to /tmp and extracted there, but I once found that it failed because the /tmp partition is tiny. So I set it to /volume1/@tmp instead, which wasn’t a good idea either since it doesn’t exist on your system (for some reason your partition is called /volume1000). I’ll have to change that. As for smb.conf – I think it is being read. How else would the error message know about /volume1000?
I had a volume1 when I first setup the system but then I added additional disks right away and it’s been 1000 ever since. Shrug.
I don’t think the tmp is the issue for sure, I symlinked /volume1/tmp over to /volume1000/tmp and the install appears the same (and nothing was created in that tmp folder).
What’s the url to download the package directly? I figure I can unpack it and try to execute each script in turn and then we can see where it falls down.
I’m away from a computer so I can’t tell you. But you should change your symlink – it’s /volume1/@tmp
You do need the @ sign.
Can’t believe I missed that. Symlinking with the @ works so this is the problem. The insertion of the default inbound location on startup is an issue too. I had symlinked that before, but it might be nice to have it do this only if the current path is inside the install folder.
So I just need a reliable way of reading what the primary storage volume is. I might do some kind of find, searching for @tmp then.
As for default friends backup location – it’s hard set at install time, but not during upgrades, and not at each startup. That used to be the behaviour but I changed it in the last version.
maybe read the smb.conf like for the java package?
I’m thinking more along the lines of:
find / -name '@tmp' -maxdepth 2 | head -n 1Incidentally I’ve managed to fix the timezone support for Daylight Saving Time in Java. It turns out that I have to give Java the modern Linux timezone name (e.g. ‘Europe/London’, rather than say ‘GMT0IST,M3.5.0/1,M10.5.0’). After spending some time looking at it last night I discovered that I can take DSM’s own name for the currently configured timezone from /etc/synoinfo.conf and look it up against a conversion list in /usr/share/zoneinfo/Timezone/tzname. Not exactly trivial :) I’ve fixed the scripts, so all future versions of my packaged Java apps will have this improvement.
THX !
I am using a Qnap, but your work also make it possible to run CrashPlan 3.2 on the Qnap platform.
Again THX!
Just a quick message to say THANK YOU for spending the time on this. A great piece of work. I’ve successfully installed Java and Crashplan headless on a DS2411+ and am controlling it from a local PC. I’m running a test backup now but it’s running fine and memory usage (1GB installed) is no problem at all.
Thanks again.
Thank you for this package, it works like a charm !!!
CrashPlanPROe was updated yesterday, but I have got it confirmed that this is only for new installes and the update version havent been released yet.
So keep the PROe package as it is for now :)
Hi all, I’ve managed to register myself onto CrashPlan’s affilate programme, so please use the link in the Notes section of this blog post if you end up signing up to one of the paid backup plans. :)
EDIT – Oh dear, affiliate links aren’t permitted on blogs hosted on WordPress.com :( The policy says there are exceptions though, when it’s not the sole focus of the blog, so I’ll ask them nicely…
I want to thank you for this amazing work!
Run Crashplan on DS211j now and it works perfertly. Thanks a lot.
as mentioned above, I am having the problem, the service of the CrashPlanPROe-Client isn’t running, when startet from the package-manger-gui.
The installation of the Java-package ends up with an that the package couldn’t be installed. But it shows as installed afterwards.
Just to mention: I am using the “old” CrashPlanPROe-version Release 03.08.2010, because the new version of CrashPlanPROe is out, but my CrashPlanPROe-server is still running the “old” version, because the updates are not available yet, only new installs can use the new CrashPlanPROe 3-version.
The download-path for this “old” version is still:
http://download.crashplan.com/installs/linux/install/CrashPlanPRO/CrashPlanPRO_2010-03-08_Linux.tgz
/volume1/@appstore/CrashPlanPROe/bin/CrashPlanEngine status
shows “Service running”,
but a
netstat -an | grep ‘424.’
doesn’t show any services running.
The my.service.xml is always reset to servicehost=127.0.0.1 when the service is started via the package-manger-gui.
Correcting that entry to servicehost=0.0.0.0 and restarting the CrashPlanPROe-Engine via
/volume1/@appstore/CrashPlanPROe/bin/CrashPlanEngine restart
shows the services running (netstat -an | grep ‘424.’)
DS> netstat -an | grep ‘424.’
tcp 0 0 ::%136900768:4242 ::%135699616:* LISTEN
tcp 0 0 ::ffff:127.0.0.1%136900976:4243 ::%135699616:* LISTEN
So the Java-package is installed, without it, the packages won’t run.
But:
I still can’t connect from the Mac with a CrashPlanPROe-Client and the my.service.xml-file is again reset to servicehost=127.0.0.1.
I haven’t installed any other stuff (ipkg, the machine (412+) is a default installation of DSM4.0-2198
Patters: did You change anything on the CrashPlanPROe-package (because of this new version)? Than You should create two packages, because the “old” CrashPlanPROe-versions will be used for a long time, until all CPPROe-Servers are updated. This will take a long time (≈ 1 year approximately), because of new licenses and so on.
I have my phone-date with Synology at the end of April, at that date, they will provide me with informations about upgrading my servers (costs, problems ;)…..).
Thanks
Sven
ok, one success:
I can connect via a ssh-tunnel (redirect local port 4200 to remote-port 4243 on Synology) and now I can connect.
But that isn’t a real option.
How can I suppress the reset of the my.service.xml-file?
chflags isn’t available on the Synology (without ipkg I guess; but I want to keep the installation as default as possible for my clients).
Thanks in advance
Sven
Hi :)
I told patters not to change the PROe package yet, because like you say, no one can update yet.
Here everything just work.
I had always needed to use the ssh tunnel redirect port to connect my GUI to the CPP client running on my Syn, never got it to work any other way and I really don’t see the problem with it.
Hi Svein,
I don’t have a problem with the ssh-tunnel, but it isn’t a real choice for default users.
I don’t understand why this setting is reset to 127.0.0.1 on every start of the CP-service. This isn’t done on “manual installs”.
Even the documentation from Code42 tells how to connect to an headless client with ssh, so I guess its the official way to do it. Normally you don’t need to connect to it very often :)
For the 127.0.0.1 thing, do you start and stop it very often? I usually just let it run.
But I guess the starting script made by Patters resets the 127.0.0.0, if I remember some older post correctly.
Hi Svein,
the script instantly changes the setting back to 127.0.0.1, so a change to 0.0.0.0 doesn`t work at any time.
I am just a bit confused why the startup script is programmed to change this value..
I have a DS411. Everything was working fine prior to the 3.2 CrashPlan upgrade; I reinstalled CrashPlan a couple of times while patters worked through the libmd5 issue.
I was able to adopt my old computer, but now CrashPlan is stuck showing “Sychronizing” in the UI but not actually sending any data.
I’ve just uninstalled and reinstalled both Java7 and CrashPlan (3.2.1 – 1332824401321 (2012-03-27T05:00:01:321+0000)) by removing the packages in the Syno Package Center and then reinstalling. However, I see the same results. To be certain, I’ve uninstalled both, rebooted, reinstalled both, and rebooted – no change.
There are some exceptions in the logs – has anyone seen something like this before?
CDC:: Exception creating UPnP port mapping – java.io.IOException: Unable to receive a response from the UPNP device, ConnectionDiscoveryClient[started = true, listenPort = 4242, routerIp = 192.168.1.1, testId = 0, success = false, externalAddress = null, externalPort = -1, externalType = Unknown, status = ConnectionTestStatusEvent[running = true, success = false, remoteAddress = null, externalPort = 12167, type = UPnP], uPnP = UPnP[localAddress = 192.168.1.117, gateway = net.sbbi.upnp.impls.InternetGatewayDevice@b88ec9], natPMP = null, owner = Peer@21506941[516400612077207925@0.0.0.0:4242], lastFour = 7925, worker = ConnectionDiscoveryClient$Worker@2689292[ threadName = CDCWorker, stopped = false, running = true, thread.isDaemon = true, thread.isAlive = true, thread = Thread[W1125204_CDCWorker,5,main]]]
[04.05.12 12:44:34.032 INFO W1125204_CDCWorker p42.common.net.ConnectionDiscoveryClient] CDC:: Exception creating NAT-PMP port mapping – java.net.PortUnreachableException: ICMP Port Unreachable, ConnectionDiscoveryClient[started = true, listenPort = 4242, routerIp = 192.168.1.1, testId = 0, success = false, externalAddress = null, externalPort = -1, externalType = Unknown, status = ConnectionTestStatusEvent[running = true, success = false, remoteAddress = null, externalPort = 12167, type = NatPMP], uPnP = UPnP[localAddress = 192.168.1.117, gateway = net.sbbi.upnp.impls.InternetGatewayDevice@b88ec9], natPMP = com.code42.net.NatPMP@5bcff3, owner = Peer@21506941[516400612077207925@0.0.0.0:4242], lastFour = 7925, worker = ConnectionDiscoveryClient$Worker@2689292[ threadName = CDCWorker, stopped = false, running = true, thread.isDaemon = true, thread.isAlive = true, thread = Thread[W1125204_CDCWorker,5,main]]]
[04.05.12 12:43:03.434 WARN BWQ-Security::-0_524 de42.messaging.security.SecurityProvider] SP:: GeneralSecurityException: finalizeExchange, remote client likely has an invalid PbK. Closing session. Session[id=524959391798526325, closed=false, isLocal=true, lat=2012-04-05T12:43:00:987, lrt=2012-04-05T12:43:00:987, lwt=2012-04-05T12:43:00:902, #pending=0, enqueued=false, local=192.168.1.117:4242, remote=192.168.1.117:44261, usingProtoHeaders=true, usingEncryptedHeaders=false], javax.crypto.BadPaddingException: Data must start with zero
FWIW, this problem appears to have resolved itself after leaving the system alone for a few days.
Note, I had the same problem again recently. I had changed the email address on my CrashPlan account, which effectively changes the username for the account.
On my NAS there was a /var/services/homes/crashplan/.crashplan/.identity which still had the old information. Every time I restarted CrashPlan and reconnected the client, I had to re-enter my credentials and re-do the adoption. After that, it would get stuck on “Connecting to backup location”, with the same crypto exceptions in the log.
After I deleted /var/services/homes/crashplan/.crashplan/.identity and restarted CrashPlan, it’s all fine. It’s now using /var/lib/crashplan/.identity, which already had the correct data in it (I didn’t have to adopt again). I guess my residual /var/services/homes/crashplan/.crashplan/.identity was overriding the valid one, and was never getting updated.
/var/lib/crashplan generally only gets created when you manually start CrashPlan in the shell running as root, because the crashplan daemon user has no write permission to that folder. My start-stop-status script removes that folder every time you start CrashPlan in Package Center specifically to avoid this problem (see line 026). The issue with using /var/lib/crashplan for the config is that the config will get created there by root if it’s ever launched manually (lots of my readers tinker with this) and subsequently the crashplan daemon user cannot edit that file, meaning you have to enter credentials each time you launch the GUI. Since CrashPlan will attempt to parse the identity file in /var/lib/crashplan first, start-stop-status destroys it before launching CP to prevent that happening, and to force it to use the one in /var/services/homes/crashplan.
So logically what you described should not ever be able to happen, unless you’re not using the latest package.
Lesson learned (from patters’ reply below. Don’t start/stop CrashPlan on the command line – use the Package Manager or patters’ start-stop-status script!
My problem was not actually resolved until I did this:
* stop CrashPlan, on command line
* stop CrashPlan, via package manager
* update CrashPlan to the latest (shame on me for posting without first doing this!)
* Delete /var/lib/crashplan/.identity (not needed, the script will do this)
* start CrashPlan via package manager
* profit :)
Got Crashplan up and running on my DS412+ using your packages and instructions. Just wanted to say THANK YOU. You should absolutely make the donate button more prominent. GREAT work!
Thanks!!! I now have crashplan working on a DS110J and is backing up my MacBook and is backuping itself to a remote linux server.
Great work on creating this package.
Thanks Patters for all your work you are a star :)
I’m running DSM 4 on a DS 1010+
I thought I would share some of my findings that helped me along. I used FireFox to download the Java package as Chrome modified it (bad Chrome:). I had to create a public folder and give rights to my local user so that I could see and write to it to save the different Java packages.
Once I had installed everything I couldn’t connect to the headless install running on the NAS server and had already installed it all manually before I came across your site. Boy was I happy to find your site :) After upgrading from DSM 3.X to DSM 4 it all just stopped working and reinstalling didn’t work :(
I did remember having used the trick from here: http://www.liquidstate.net/blog/technology/crashplan-remote-gui/
to connect to the Crashplan running on my server from my PC and doing this using Putty to open an SSH tunnel just worked straight away just using the port forwarding and not changing the IP.
Also installed Servio on my DS1010+ and had never heard of it but its great so many thanks. Switched off all the basic media server, photo station etc stuff aswelll.
First off, thanks for the AWESOME package. This was 100x easier than manually installing Crashplan on my Synology box!
Add me to the group of people with an Intel based 1511+ that can’t get the change to the serviceHost entry in conf/my.service.xml to stick. Every time CrashplanEngine starts, it overwrites my.service.xml with a default copy. The serviceHost entry is not too bad, as it just means I have to create an SSH tunnel – but, this also means that my account info, backup password, paths, and other Crashplan settings are also overwritten every time the service restarts. This means I have to log back in, adopt the prior backup, and then wait about an hour for the catalog and block data to sync (for about 1TB of data backed up online).
I’ve tried all the proposed options in this thread, with no luck. If you have any other ideas, I’m more than happy to try them out and report back.
So, perhaps something changed in DSM4… When I go to the package manager and click the “Stop” button for the Crashplan package (stop, not uninstall), the /usr/local/etc/rc.d/Crashplan.sh script is deleted and when I click “Run” in the package manager, it is recreated along with a bunch of files in /volume1/@appstore/CrashPlan … including my.service.xml.
I’ll digging…
Ok, I was wrong… the Crashplan.sh file vanishes when you stop the service, but that appears to be as designed (based on the Synology 3rd-Party Apps Developer Guide – page 33).
After diffing the conf folder stopped, started, signed in, stopped, started … the my.service.xml file is replaced when Crashplan starts. The Crashplan log seems to indicate that it did this:
——————————————————————————————————
BEGIN Loading Configuration
Loading from default: /volume1/@appstore/CrashPlan/conf/default.service.xml
Loading from my xml file=conf/my.service.xml
Loading ServiceConfig, newInstall=false, version=3, configDateMs=1334208669362, installVersion=1332824401321
OS = Linux
Initializing backup paths last modified to now. lastModified=1
AuthorityLocation@31212095[ location=central.crashplan.com:443, hideAddress=false ]
END Loading Configuration
DELETED file=conf/service.model
DELETED file=conf/service.login
FAILED to delete file=/volume1/@appstore/CrashPlan/conf/import_key
FAILED to delete file=conf/service.copier
CACHE DELETED cacheDir=/volume1/@appstore/CrashPlan/cache
BEGIN Loading Configuration
CpsFoldersMigrate is not necessary. /volume1/@appstore/CrashPlan/conf/my.service.xml file does not exists.
Loading from default: /volume1/@appstore/CrashPlan/conf/default.service.xml
Loading ServiceConfig, newInstall=true, version=3, configDateMs=null, installVersion=1332824401321
OS = Linux
Initializing backup paths last modified to now. lastModified=1
AuthorityLocation@30620267[ location=central.crashplan.com:443, hideAddress=false ]
END Loading Configuration
——————————————————————————————————
Walking through the above, it appears to load defaults, then my.service.xml, then delete my login credentials, then load defaults and save them back to my.service.xml. It appears that Crashplan decides to delete my.service.xml right before it tries to clear the login info and cache. I tried changing the log4j config file (service.log.properties) to output DEBUG+ (instead of INFO+), but there were no additional lines printed.
I’ll email Crashplan to see if they have any advice.
Thanks for the log. This is what happens when the file ~/.crashplan/.identity is missing on startup. I suspect that perhaps you missed out a step in the instructions… do you have the User Homes Service enabled in the User control panel in DSM?
I think enabling it post-install is not enough. I think you may need to uninstall CrashPlan, enable it, then re-install.
User Homes provides a home folder for each user, and without it all users inherit the root user’s home folder which they don’t have permission to write to. So the .identity file can never be created. Please let me know if this solves it!
Wow, a simple uninstall/reinstall of the package fixed it… My settings are no longer wiped out. I feel a pretty dumb for not having tried that earlier!
I enabled user homes before I installed, but I checked the /var/services/homes/crashplan folder, which existed and had the proper permissions, but it was missing the .crashplan subfolder. After the uninstall/reinstall the .crashplan subfolder and .identity files are there.
Thanks again for the awesome package!
Hmm. I wonder if all the people with this issue also have large backup selections like yours.
I don’t *think* it is related to the size of my backup set, as I can simply sign-in, but not adopt, then stop the service and restart it and my settings are gone. Without adopting the prior backup, the my.service.xml is still fairly small and doesn’t contain any of the path info that is there once I manually configure or adopt the prior backup.
Since this seems to be Crashplan resetting the my.service.xml file, I sent Crashplan Support my log files via email last night. Hopefully I’ll hear from them today. If they give me anything meaningful I will share it on here.
Hi all
For some reason my system stopped backing up yesterday. Since 2Pm it is stuck in “Synchronizing”. In the service.log.0 I have the following:
[04.12.12 07:03:59.734 INFO MQ-UI-0 com.backup42.service.ui.UIController ] UserActionRequest: CommandMessage[force.idle]
[04.12.12 07:03:59.734 INFO MQ-UI-0 com.backup42.common.command.CliExecutor ] RUN COMMAND: force.idle
[04.12.12 07:03:59.735 INFO MQ-UI-0 backup42.service.backup.BackupController] UI:: FORCE IDLE… highBandwidth=0 B/s, idleThrottleRate=100
[04.12.12 07:04:03.434 INFO MQ-UI-1 com.backup42.service.ui.UIController ] UserActionRequest: CommandMessage[auto.idle]
[04.12.12 07:04:03.434 INFO MQ-UI-1 com.backup42.common.command.CliExecutor ] RUN COMMAND: auto.idle
[04.12.12 07:04:03.435 INFO MQ-UI-1 backup42.service.backup.BackupController] UI:: AUTO IDLE… lowBandwidth=0 B/s, activeThrottleRate=100
[04.12.12 07:04:08.283 INFO MQ-UI-0 com.backup42.service.ui.UIController ] UserActionRequest: CommandMessage[force.idle]
[04.12.12 07:04:08.284 INFO MQ-UI-0 com.backup42.common.command.CliExecutor ] RUN COMMAND: force.idle
[04.12.12 07:04:08.284 INFO MQ-UI-0 backup42.service.backup.BackupController] UI:: FORCE IDLE… highBandwidth=0 B/s, idleThrottleRate=100
[04.12.12 07:04:08.938 INFO MQ-UI-1 com.backup42.service.ui.UIController ] UserActionRequest: CommandMessage[auto.idle]
[04.12.12 07:04:08.939 INFO MQ-UI-1 com.backup42.common.command.CliExecutor ] RUN COMMAND: auto.idle
[04.12.12 07:04:08.939 INFO MQ-UI-1 backup42.service.backup.BackupController] UI:: AUTO IDLE… lowBandwidth=0 B/s, activeThrottleRate=100
There are over 38000 files to back up, only about half have been uploaded to CrashPlan Central. But the sytem is sitting idle.
My setup is still DS411 / CP -005 package / Java 7
Thanks
You could try increasing the Java heap size:
The problem is that a DS411 only has 256MB of RAM. I think you could be asking too much of it…
Hi patters,
Thanks for this. Actually the DS411 has 512MB and the heap size was set at 384MB. It started working without me changing anything (?).
One thing I did notice though: when I had this problem I uninstalled & reinstalled, and /var/lib/crashplan/.identity lost it’s owner as shown below
root@DiskStation /var/lib/crashplan> ll
total 12
drwxrwxrwx 2 1029 root 4096 2012-03-27 21:48 .
drwxr-xr-x 5 root root 4096 2012-03-25 21:22 ..
-rw——- 1 1029 users 2506 2012-04-11 22:42 .identity
A simple chown fixed this, but something might be able to be done in the install package.
In any case, thank you for all your help.
David
Good point about the one in /var/lib. I had meant to add that – in fact there are several improvements that I’ve got in store for a new release, so I’ll add that too. Namely:
. Daylight Savings Time support for Java
. No longer assuming the primary storage volume is /volume1
. A more obvious invitation to read the package blog post notes, and mention of user homes service
. and now chown-ing /var/lib/crashplan after installs and upgrades
Patters,
Another thank you from me.
I’ve had some issues with Time Machine recently and was getting a little nervous about relying on it (other than my occasional imaging with carbon copy cloner). Time Machine has said twice recently it needed to do a completely fresh backup meaning all my previous backups were lost.
I’ve now installed your crashplan package and it’s working nicely. I may disable Time Machine the next time it either tells me it can’t find the synology or it decides to do a totally fresh backup.
Mobes
Installed the package, seemingly no install problems.
When the package starts, the engine runs under the “crashplan” user as expected:
> ps
…
10731 crashpla 329m S N /volume1/@appstore/java7/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx192M -Djava.net.preferIPv4Stac
…
However, the engine is able to read and write (back and restore) to ANY folder on my diskstation, even though I have set up the “crashplan” user’s permissions so that it is restricted to just one Synology share.
I can only assume that somehow the engine has root access, which is pretty disturbing.
Any ideas?
Does no one else have this problem??
When you open the CrashPlan GUI and select folders for backup, you’ll notice that any folder on your DSM can be viewed and ultimately selected for backup, regardless of the permissions of the “crashplan” user.
Further if you attempt to restore data, you are able to restore the data to any folder on your DSM.
Is it really just me? Am I missing something?
Hmmm, interesting observation – I had completely overlooked this dealing with all the other minor complications. I have no idea how it does this, since you can see from running ps, or top, that it’s definitely running as ‘crashplan’. I guess maybe the JNI library which CrashPlan uses allows root access to the file system.
Thanks for confirming patters.. great if you could look into this at some point. I don’t feel great knowing that the CrashPlan engine has opened up an unrestricted door into my trusty DSM. Not sure others will like it either.
Cheers, Dave
I’ve investigated a little more just now. There’s nothing about this on the CrashPlan forum, but there are threads with people complaining of the reverse problem – CP not being able to access files when running as other account than root. This strongly suggests that CP is fine, but that this is probably syno-specific.
The user is created during the install by the binary synouser (have a look at the postinst script above). It has no particular privileges. If I su to that user, I can see all files on my syno – even ones in folders that the DSM User control panel tells me should be off limits.
su crashplan -s /bin/shThis is pretty odd, but I guess it’s because the security on the NAS is share-based (AFP, SMB etc.) rather than filesystem based. I’m not a habitual Linux user but it looks to me like that user has read privileges on all files and folders by default. But CrashPlan is invoked using su, and the syno is configured to deny a shell logon to anyone not in the DSM Administrators group, so I don’t think this is too unsafe.
Running DSM4.0 on 411+II …. and coming from a manual install that worked. I’ve followed the uninstall reciepe … and installed java (manually downloaded toolchain and java).
The package installs without any problems – but starting it, just gives me this message “Wait a few seconds, then stop and restart the package to allow desktop client connections.”
Since its not running – I cannot stop it :-)
I’ve tried uninstall / install – with same result.
I’ve also tried rebooting the 411+II – to no avail.
I would love to adopt to this solution, since it is so much easier to maintain … the old process had lots of manual steps.
Anyone know what I should do / try ?
Just tried uninstalling CP and Java. Doing a manual cleanup of CP leftovers (just removed directories named crashplan) and then rebooting the NAS.
Reinstalling without any problems.
But I cannot run the package – same message as mentioned above.
I will try and see if I can locate a log of some sort – that might shed some light on this.
Could my problems be related to the fact that my NAS is setup with volume2 as primary (and only)?
volume1 do exist – but seems to be for the system only.
I’m a novice in the linux world – so I tend to “leave it alone” if it works. And my NAS i running perfectly with other “services” …
On your system, does the folder /volume1/@tmp exist? Or do you only have /volume2/@tmp? This will be useful to know for the next version of the installer scripts.
Sorry for late answer – been on workshop for a couple of days.
I have a /volume2/@tmp directory … and I’ve tried the symlink suggestion earlier in the thread. But since I’m only a Linux novice .. I’m not sure what the exact command should be. Should I create symlink for entire /volume1 or only for /@tmp?
Hope you have a bit more time for me patters :-)
more information:
I’ve deleted the remains of /volume1 entirely … so now I only have /volume2 …
But a total uninstall / install of java and cp still doesn’t do the trick.
Can’t connect to http://pcloadletter.comlu.com , anyone else having the same problem?
I am also having the same issue. I will also note that I did just update to DSM 4.0-2219.
Tested just now as fine on my DSM 4.0-2198. Is it still broken for your 2219? Perhaps I’ll need to tweak something.
I’ve just done a uninstall / install of java and cp – and no problem getting through. Installation runs smooth. I just have problems running cp :-)
Can’t connect too since I upgraded to DSM 4.0-2219 on my DS412+
Dont’t know why, but it works now !
I wasnt able to get it up running after a upgrade to the latest version of DSM 4
As a try I did uninstall Crashplan at my Diskstation. Did reboot my DS and now I dont have any of you packages in my list of apps availble to install….
Hope you’re able to fix it!
add http://pcloadletter.comlu.com as “other source” :-)
yeah I have that already!
But now the packages is back…..
Good to hear …. hope it works out for you :-)
Its up running again.
I had to uninstall and then reinstall Crashplan. Restart. Edit: conf/ui.properties. Reboot. And then adapt.
I installed your package on my DS412+ and it works fine except the real-time file watcher. I get the following errors in service.log.0
[04.19.12 22:33:57.795 WARN main com.code42.backup.path.BackupSetsManager] BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12; BackupSetsManager[ scannerRunning = false, scanInProgress = false, fileQueueRunning = false, fileCheckInProgress = false, errorRescan=false ], com.code42.exception.DebugException: BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12; BackupSetsManager[ scannerRunning = false, scanInProgress = false, fileQueueRunning = false, fileCheckInProgress = false, errorRescan=false ]
com.code42.exception.DebugException: BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12; BackupSetsManager[ scannerRunning = false, scanInProgress = false, fileQueueRunning = false, fileCheckInProgress = false, errorRescan=false ]
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:407)
at com.code42.backup.path.BackupSetsManager.setUp(BackupSetsManager.java:128)
at com.code42.backup.BackupManager.setUp(BackupManager.java:140)
at com.backup42.service.backup.BackupController.setUp(BackupController.java:415)
at com.backup42.service.CPService.start(CPService.java:472)
at com.backup42.service.CPService.main(CPService.java:1622)
Caused by: java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:40)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:392)
… 5 more
[04.19.12 22:33:57.796 INFO main backup42.service.backup.BackupController] Realtime file watcher is NOT AVAILABLE – osCode=Linux
[04.19.12 22:33:58.050 WARN W29441291_ScanWrkr com.code42.backup.path.BackupSetsManager] BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12; BackupSetsManager[ scannerRunning = true, scanInProgress = false, fileQueueRunning = false, fileCheckInProgress = false, errorRescan=false ], com.code42.exception.DebugException: BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12; BackupSetsManager[ scannerRunning = true, scanInProgress = false, fileQueueRunning = false, fileCheckInProgress = false, errorRescan=false ]
com.code42.exception.DebugException: BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12; BackupSetsManager[ scannerRunning = true, scanInProgress = false, fileQueueRunning = false, fileCheckInProgress = false, errorRescan=false ]
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:407)
at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(BackupSetsManager.java:330)
at com.code42.backup.path.BackupSetsManager.access$1600(BackupSetsManager.java:65)
at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(BackupSetsManager.java:1035)
at com.code42.utils.AWorker.run(AWorker.java:158)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Platform is not supported, glibc: 2.3.6, kernel: 2.6.32.12
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:40)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:392)
… 5 more
Did you go further on this topic ?
It’s a known unsolved issue unfortunately. I tried compiling for Intel the same bits that had to be added to the ARM version, but that didn’t work. Since I don’t have an Intel syno I can’t reasonably take it any further. The version of glibc on my ARM syno is 2.5, so perhaps the one that’s in DSM for Intel (2.36) is too old for the inotify support to work.