UPDATE – CrashPlan For Home (green branding) was retired by Code 42 Software on 22/08/2017. See migration notes below to find out how to transfer to CrashPlan for Small Business on Synology at the special discounted rate.
CrashPlan is a popular online backup solution which supports continuous syncing. With this your NAS can become even more resilient, particularly against the threat of ransomware.
There are now only two product versions:
- Small Business: CrashPlan PRO (blue branding). Unlimited cloud backup subscription, $10 per device per month. Reporting via Admin Console. No peer-to-peer backups
- Enterprise: CrashPlan PROe (black branding). Cloud backup subscription typically billed by storage usage, also available from third parties.
The instructions and notes on this page apply to both versions of the Synology package.
CrashPlan is a Java application which can be difficult to install on a NAS. Way back in January 2012 I decided to simplify it into a Synology package, since I had already created several others. It has been through many versions since that time, as the changelog below shows. Although it used to work on Synology products with ARM and PowerPC CPUs, it unfortunately became Intel-only in October 2016 due to Code 42 Software adding a reliance on some proprietary libraries.
Licence compliance is another challenge – Code 42’s EULA prohibits redistribution. I had to make the Synology package use the regular CrashPlan for Linux download (after the end user agrees to the Code 42 EULA). I then had to write my own script to extract this archive and mimic the Code 42 installer behaviour, but without the interactive prompts of the original.
Synology Package Installation
- In Synology DSM’s Package Center, click Settings and add my package repository:
- The repository will push its certificate automatically to the NAS, which is used to validate package integrity. Set the Trust Level to Synology Inc. and trusted publishers:
- Now browse the Community section in Package Center to install CrashPlan:
The repository only displays packages which are compatible with your specific model of NAS. If you don’t see CrashPlan in the list, then either your NAS model or your DSM version are not supported at this time. DSM 5.0 is the minimum supported version for this package, and an Intel CPU is required. - Since CrashPlan is a Java application, it needs a Java Runtime Environment (JRE) to function. It is recommended that you select to have the package install a dedicated Java 8 runtime. For licensing reasons I cannot include Java with this package, so you will need to agree to the licence terms and download it yourself from Oracle’s website. The package expects to find this .tar.gz file in a shared folder called ‘public’. If you go ahead and try to install the package without it, the error message will indicate precisely which Java file you need for your system type, and it will provide a TinyURL link to the appropriate Oracle download page.
- To install CrashPlan PRO you will first need to log into the Admin Console and download the Linux App from the App Download section and also place this in the ‘public’ shared folder on your NAS.
- If you have a multi-bay NAS, use the Shared Folder control panel to create the shared folder called public (it must be all lower case). On single bay models this is created by default. Assign it with Read/Write privileges for everyone.
- If you have trouble getting the Java or CrashPlan PRO app files recognised by this package, try downloading them with Firefox. It seems to be the only web browser that doesn’t try to uncompress the files, or rename them without warning. I also suggest that you leave the Java file and the public folder present once you have installed the package, so that you won’t need to fetch this again to install future updates to the CrashPlan package.
- CrashPlan is installed in headless mode – backup engine only. This will configured by a desktop client, but operates independently of it.
- The first time you start the CrashPlan package you will need to stop it and restart it before you can connect the client. This is because a config file that is only created on first run needs to be edited by one of my scripts. The engine is then configured to listen on all interfaces on the default port 4243.
CrashPlan Client Installation
- Once the CrashPlan engine is running on the NAS, you can manage it by installing CrashPlan on another computer, and by configuring it to connect to the NAS instance of the CrashPlan Engine.
- Make sure that you install the version of the CrashPlan client that matches the version running on the NAS. If the NAS version gets upgraded later, you will need to update your client computer too.
- The Linux CrashPlan PRO client must be downloaded from the Admin Console and placed in the ‘public’ folder on your NAS in order to successfully install the Synology package.
- By default the client is configured to connect to the CrashPlan engine running on the local computer. Run this command on your NAS from an SSH session:
echo `cat /var/lib/crashplan/.ui_info`
Note those are backticks not quotes. This will give you a port number (4243), followed by an authentication token, followed by the IP binding (0.0.0.0 means the server is listening for connections on all interfaces) e.g.:
4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0
port,--------------token-----------------,binding
Copy this token value and use this value to replace the token in the equivalent config file on the computer that you would like to run the CrashPlan client on – located here:
C:\ProgramData\CrashPlan\.ui_info (Windows)
“/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for all users)
“~/Library/Application Support/CrashPlan/.ui_info” (Mac OS X installed for single user)
/var/lib/crashplan/.ui_info (Linux)
You will not be able to connect the client unless the client token matches on the NAS token. On the client you also need to amend the IP address value after the token to match the Synology NAS IP address.
so using the example above, your computer’s CrashPlan client config file would be edited to:
4243,9ac9b642-ba26-4578-b705-124c6efc920b,192.168.1.100
assuming that the Synology NAS has the IP 192.168.1.100
If it still won’t connect, check that the ServicePort value is set to 4243 in the following files:
C:\ProgramData\CrashPlan\conf\ui_(username).properties (Windows)
“/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for all users)
“~/Library/Application Support/CrashPlan/ui.properties” (Mac OS X installed for single user)
/usr/local/crashplan/conf (Linux)
/var/lib/crashplan/.ui_info (Synology) – this value does change spontaneously if there’s a port conflict e.g. you started two versions of the package concurrently (CrashPlan and CrashPlan PRO) - As a result of the nightmarish complexity of recent product changes Code42 has now published a support article with more detail on running headless systems including config file locations on all supported operating systems, and for ‘all users’ versus single user installs etc.
- You should disable the CrashPlan service on your computer if you intend only to use the client. In Windows, open the Services section in Computer Management and stop the CrashPlan Backup Service. In the service Properties set the Startup Type to Manual. You can also disable the CrashPlan System Tray notification application by removing it from Task Manager > More Details > Start-up Tab (Windows 8/Windows 10) or the All Users Startup Start Menu folder (Windows 7).
To accomplish the same on Mac OS X, run the following commands one by one:sudo launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist sudo mv /Library/LaunchDaemons/com.crashplan.engine.plist /Library/LaunchDaemons/com.crashplan.engine.plist.bak
The CrashPlan menu bar application can be disabled in System Preferences > Users & Groups > Current User > Login Items
Migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO)
- Leave the regular green branded CrashPlan 4.8.3 Synology package installed.
- Go through the online migration using the link in the email notification you received from Code 42 on 22/08/2017. This seems to trigger the CrashPlan client to begin an update to 4.9 which will fail. It will also migrate your account onto a CrashPlan PRO server. The web page is likely to stall on the Migrating step, but no matter. The process is meant to take you to the store but it seems to be quite flakey. If you see the store page with a $0.00 amount in the basket, this has correctly referred you for the introductory offer. Apparently the $9.99 price thereafter shown on that screen is a mistake and the correct price of $2.50 is shown on a later screen in the process I think. Enter your credit card details and check out if you can. If not, continue.
- Log into the CrashPlan PRO Admin Console as per these instructions, and download the CrashPlan PRO 4.9 client for Linux, and the 4.9 client for your remote console computer. Ignore the red message in the bottom left of the Admin Console about registering, and do not sign up for the free trial. Preferably use Firefox for the Linux version download – most of the other web browsers will try to unpack the .tgz archive, which you do not want to happen.
- Configure the CrashPlan PRO 4.9 client on your computer to connect to your Syno as per the usual instructions on this blog post.
- Put the downloaded Linux CrashPlan PRO 4.9 client .tgz file in the ‘public’ shared folder on your NAS. The package will no longer download this automatically as it did in previous versions.
- From the Community section of DSM Package Center, install the CrashPlan PRO 4.9 package concurrently with your existing CrashPlan 4.8.3 Syno package.
- This will stop the CrashPlan package and automatically import its configuration. Notice that it will also backup your old CrashPlan .identity file and leave it in the ‘public’ shared folder, just in case something goes wrong.
- Start the CrashPlan PRO Synology package, and connect your CrashPlan PRO console from your computer.
- You should see your protected folders as usual. At first mine reported something like “insufficient device licences”, but the next time I started up it changed to “subscription expired”.
- Uninstall the CrashPlan 4.8.3 Synology package, this is no longer required.
- At this point if the store referral didn’t work in the second step, you need to sign into the Admin Console. While signed in, navigate to this link which I was given by Code 42 support. If it works, you should see a store page with some blue font text and a $0.00 basket value. If it didn’t work you will get bounced to the Consumer Next Steps webpage: “Important Changes to CrashPlan for Home” – the one with the video of the CEO explaining the situation. I had to do this a few times before it worked. Once the store referral link worked and I had confirmed my payment details my CrashPlan PRO client immediately started working. Enjoy!
Notes
- The package uses the intact CrashPlan installer directly from Code 42 Software, following acceptance of its EULA. I am complying with the directive that no one redistributes it.
- The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 512MB). This can be overridden in a persistent way if you are backing up large backup sets by editing /var/packages/CrashPlan/target/syno_package.vars. If you are considering buying a NAS purely to use CrashPlan and intend to back up more than a few hundred GB then I strongly advise buying one of the models with upgradeable RAM. Memory is very limited on the cheaper models. I have found that a 512MB heap was insufficient to back up more than 2TB of files on a Windows server and that was the situation many years ago. It kept restarting the backup engine every few minutes until I increased the heap to 1024MB. Many users of the package have found that they have to increase the heap size or CrashPlan will halt its activity. This can be mitigated by dividing your backup into several smaller backup sets which are scheduled to be protected at different times. Note that from package version 0041, using the dedicated JRE on a 64bit Intel NAS will allow a heap size greater than 4GB since the JRE is 64bit (requires DSM 6.0 in most cases).
- If you need to manage CrashPlan from a remote location, I suggest you do so using SSH tunnelling as per this support document.
- The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache. Upgrades can now take place without requiring a login from the client afterwards.
- If you remove the package completely and re-install it later, you can re-attach to previous backups. When you log in to the Desktop Client with your existing account after a re-install, you can select “adopt computer” to merge the records, and preserve your existing backups. I haven’t tested whether this also re-attaches links to friends’ CrashPlan computers and backup sets, though the latter does seem possible in the Friends section of the GUI. It’s probably a good idea to test that this survives a package reinstall before you start relying on it. Sometimes, particularly with CrashPlan PRO I think, the adopt option is not offered. In this case you can log into CrashPlan Central and retrieve your computer’s GUID. On the CrashPlan client, double-click on the logo in the top right and you’ll enter a command line mode. You can use the GUID command to change the system’s GUID to the one you just retrieved from your account.
- The log which is displayed in the package’s Log tab is actually the activity history. If you are trying to troubleshoot an issue you will need to use an SSH session to inspect these log files:
/var/packages/CrashPlan/target/log/engine_output.log
/var/packages/CrashPlan/target/log/engine_error.log
/var/packages/CrashPlan/target/log/app.log - When CrashPlan downloads and attempts to run an automatic update, the script will most likely fail and stop the package. This is typically caused by syntax differences with the Synology versions of certain Linux shell commands (like rm, mv, or ps). The startup script will attempt to apply the published upgrade the next time the package is started.
- Although CrashPlan’s activity can be scheduled within the application, in order to save RAM some users may wish to restrict running the CrashPlan engine to specific times of day using the Task Scheduler in DSM Control Panel:
Note that regardless of real-time backup, by default CrashPlan will scan the whole backup selection for changes at 3:00am. Include this time within your Task Scheduler time window or else CrashPlan will not capture file changes which occurred while it was inactive:
- If you decide to sign up for one of CrashPlan’s paid backup services as a result of my work on this, please consider donating using the PayPal button on the right of this page.
Package scripts
For information, here are the package scripts so you can see what it’s going to do. You can get more information about how packages work by reading the Synology 3rd Party Developer Guide.
installer.sh
#!/bin/sh
#--------CRASHPLAN installer script
#--------package maintained at pcloadletter.co.uk
DOWNLOAD_PATH="http://download2.code42.com/installs/linux/install/${SYNOPKG_PKGNAME}"
CP_EXTRACTED_FOLDER="crashplan-install"
OLD_JNA_NEEDED="false"
[ "${SYNOPKG_PKGNAME}" == "CrashPlan" ] && DOWNLOAD_FILE="CrashPlan_4.8.3_Linux.tgz"
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ] && DOWNLOAD_FILE="CrashPlanPRO_4.*_Linux.tgz"
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ]; then
CP_EXTRACTED_FOLDER="${SYNOPKG_PKGNAME}-install"
OLD_JNA_NEEDED="true"
[ "${WIZARD_VER_483}" == "true" ] && { CPPROE_VER="4.8.3"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_480}" == "true" ] && { CPPROE_VER="4.8.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_470}" == "true" ] && { CPPROE_VER="4.7.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_460}" == "true" ] && { CPPROE_VER="4.6.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_452}" == "true" ] && { CPPROE_VER="4.5.2"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_450}" == "true" ] && { CPPROE_VER="4.5.0"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_441}" == "true" ] && { CPPROE_VER="4.4.1"; CP_EXTRACTED_FOLDER="crashplan-install"; OLD_JNA_NEEDED="false"; }
[ "${WIZARD_VER_430}" == "true" ] && CPPROE_VER="4.3.0"
[ "${WIZARD_VER_420}" == "true" ] && CPPROE_VER="4.2.0"
[ "${WIZARD_VER_370}" == "true" ] && CPPROE_VER="3.7.0"
[ "${WIZARD_VER_364}" == "true" ] && CPPROE_VER="3.6.4"
[ "${WIZARD_VER_363}" == "true" ] && CPPROE_VER="3.6.3"
[ "${WIZARD_VER_3614}" == "true" ] && CPPROE_VER="3.6.1.4"
[ "${WIZARD_VER_353}" == "true" ] && CPPROE_VER="3.5.3"
[ "${WIZARD_VER_341}" == "true" ] && CPPROE_VER="3.4.1"
[ "${WIZARD_VER_33}" == "true" ] && CPPROE_VER="3.3"
DOWNLOAD_FILE="CrashPlanPROe_${CPPROE_VER}_Linux.tgz"
fi
DOWNLOAD_URL="${DOWNLOAD_PATH}/${DOWNLOAD_FILE}"
CPI_FILE="${SYNOPKG_PKGNAME}_*.cpi"
OPTDIR="${SYNOPKG_PKGDEST}"
VARS_FILE="${OPTDIR}/install.vars"
SYNO_CPU_ARCH="`uname -m`"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
[ "${SYNO_CPU_ARCH}" == "armv5tel" ] && SYNO_CPU_ARCH="armel"
[ "${SYNOPKG_DSM_ARCH}" == "armada375" ] && SYNO_CPU_ARCH="armv7l"
[ "${SYNOPKG_DSM_ARCH}" == "armada38x" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "comcerto2k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "alpine4k" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "monaco" ] && SYNO_CPU_ARCH="armhf"
[ "${SYNOPKG_DSM_ARCH}" == "rtd1296" ] && SYNO_CPU_ARCH="armhf"
NATIVE_BINS_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-${SYNO_CPU_ARCH}.tar.xz"
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
OLD_JNA_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-old-${SYNO_CPU_ARCH}.tar.xz"
OLD_JNA_FILE="`echo ${OLD_JNA_URL} | sed -r "s%^.*/(.*)%\1%"`"
INSTALL_FILES="${DOWNLOAD_URL} ${NATIVE_BINS_URL}"
[ "${OLD_JNA_NEEDED}" == "true" ] && INSTALL_FILES="${INSTALL_FILES} ${OLD_JNA_URL}"
TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
#the Manifest folder is where friends' backup data is stored
#we set it outside the app folder so it persists after a package uninstall
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
LOG_FILE="${SYNOPKG_PKGDEST}/log/history.log.0"
UPGRADE_FILES="syno_package.vars conf/my.service.xml conf/service.login conf/service.model"
UPGRADE_FOLDERS="log cache"
PUBLIC_FOLDER="`synoshare --get public | sed -r "/Path/!d;s/^.*\[(.*)\].*$/\1/"`"
#dedicated JRE section
if [ "${WIZARD_JRE_CP}" == "true" ]; then
DOWNLOAD_URL="http://tinyurl.com/javaembed"
EXTRACTED_FOLDER="ejdk1.8.0_151"
#detect systems capable of running 64bit JRE which can address more than 4GB of RAM
[ "${SYNOPKG_DSM_ARCH}" == "x64" ] && SYNO_CPU_ARCH="x64"
[ "`uname -m`" == "x86_64" ] && [ ${SYNOPKG_DSM_VERSION_MAJOR} -ge 6 ] && SYNO_CPU_ARCH="x64"
if [ "${SYNO_CPU_ARCH}" == "armel" ]; then
JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
elif [ "${SYNO_CPU_ARCH}" == "armv7l" ]; then
JAVA_BINARY="ejdk-8u151-linux-arm-sflt.tar.gz"
JAVA_BUILD="ARMv5/ARMv6/ARMv7 Linux - SoftFP ABI, Little Endian 2"
elif [ "${SYNO_CPU_ARCH}" == "armhf" ]; then
JAVA_BINARY="ejdk-8u151-linux-armv6-vfp-hflt.tar.gz"
JAVA_BUILD="ARMv6/ARMv7 Linux - VFP, HardFP ABI, Little Endian 1"
elif [ "${SYNO_CPU_ARCH}" == "ppc" ]; then
#Oracle have discontinued Java 8 for PowerPC after update 6
JAVA_BINARY="ejdk-8u6-fcs-b23-linux-ppc-e500v2-12_jun_2014.tar.gz"
JAVA_BUILD="Power Architecture Linux - Headless - e500v2 with double-precision SPE Floating Point Unit"
EXTRACTED_FOLDER="ejdk1.8.0_06"
DOWNLOAD_URL="http://tinyurl.com/java8ppc"
elif [ "${SYNO_CPU_ARCH}" == "i686" ]; then
JAVA_BINARY="ejdk-8u151-linux-i586.tar.gz"
JAVA_BUILD="x86 Linux Small Footprint - Headless"
elif [ "${SYNO_CPU_ARCH}" == "x64" ]; then
JAVA_BINARY="jre-8u151-linux-x64.tar.gz"
JAVA_BUILD="Linux x64"
EXTRACTED_FOLDER="jre1.8.0_151"
DOWNLOAD_URL="http://tinyurl.com/java8x64"
fi
fi
JAVA_BINARY=`echo ${JAVA_BINARY} | cut -f1 -d'.'`
source /etc/profile
pre_checks ()
{
#These checks are called from preinst and from preupgrade functions to prevent failures resulting in a partially upgraded package
if [ "${WIZARD_JRE_CP}" == "true" ]; then
synoshare -get public > /dev/null || (
echo "A shared folder called 'public' could not be found - note this name is case-sensitive. " >> $SYNOPKG_TEMP_LOGFILE
echo "Please create this using the Shared Folder DSM Control Panel and try again." >> $SYNOPKG_TEMP_LOGFILE
exit 1
)
JAVA_BINARY_FOUND=
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz ] && JAVA_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar ] && JAVA_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.tar ] && JAVA_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${JAVA_BINARY}.gz ] && JAVA_BINARY_FOUND=true
if [ -z ${JAVA_BINARY_FOUND} ]; then
echo "Java binary bundle not found. " >> $SYNOPKG_TEMP_LOGFILE
echo "I was expecting the file ${PUBLIC_FOLDER}/${JAVA_BINARY}.tar.gz. " >> $SYNOPKG_TEMP_LOGFILE
echo "Please agree to the Oracle licence at ${DOWNLOAD_URL}, then download the '${JAVA_BUILD}' package" >> $SYNOPKG_TEMP_LOGFILE
echo "and place it in the 'public' shared folder on your NAS. This download cannot be automated even if " >> $SYNOPKG_TEMP_LOGFILE
echo "displaying a package EULA could potentially cover the legal aspect, because files hosted on Oracle's " >> $SYNOPKG_TEMP_LOGFILE
echo "server are protected by a session cookie requiring a JavaScript enabled browser." >> $SYNOPKG_TEMP_LOGFILE
exit 1
fi
else
if [ -z ${JAVA_HOME} ]; then
echo "Java is not installed or not properly configured. JAVA_HOME is not defined. " >> $SYNOPKG_TEMP_LOGFILE
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
exit 1
fi
if [ ! -f ${JAVA_HOME}/bin/java ]; then
echo "Java is not installed or not properly configured. The Java binary could not be located. " >> $SYNOPKG_TEMP_LOGFILE
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5" >> $SYNOPKG_TEMP_LOGFILE
exit 1
fi
if [ "${WIZARD_JRE_SYS}" == "true" ]; then
JAVA_VER=`java -version 2>&1 | sed -r "/^.* version/!d;s/^.* version \"[0-9]\.([0-9]).*$/\1/"`
if [ ${JAVA_VER} -lt 8 ]; then
echo "This version of CrashPlan requires Java 8 or newer. Please update your Java package. "
exit 1
fi
fi
fi
}
preinst ()
{
pre_checks
cd ${TEMP_FOLDER}
for WGET_URL in ${INSTALL_FILES}
do
WGET_FILENAME="`echo ${WGET_URL} | sed -r "s%^.*/(.*)%\1%"`"
[ -f ${TEMP_FOLDER}/${WGET_FILENAME} ] && rm ${TEMP_FOLDER}/${WGET_FILENAME}
wget ${WGET_URL}
if [[ $? != 0 ]]; then
if [ -d ${PUBLIC_FOLDER} ] && [ -f ${PUBLIC_FOLDER}/${WGET_FILENAME} ]; then
cp ${PUBLIC_FOLDER}/${WGET_FILENAME} ${TEMP_FOLDER}
else
echo "There was a problem downloading ${WGET_FILENAME} from the official download link, " >> $SYNOPKG_TEMP_LOGFILE
echo "which was \"${WGET_URL}\" " >> $SYNOPKG_TEMP_LOGFILE
echo "Alternatively, you may download this file manually and place it in the 'public' shared folder. " >> $SYNOPKG_TEMP_LOGFILE
exit 1
fi
fi
done
exit 0
}
postinst ()
{
if [ "${WIZARD_JRE_CP}" == "true" ]; then
#extract Java (Web browsers love to interfere with .tar.gz files)
cd ${PUBLIC_FOLDER}
if [ -f ${JAVA_BINARY}.tar.gz ]; then
#Firefox seems to be the only browser that leaves it alone
tar xzf ${JAVA_BINARY}.tar.gz
elif [ -f ${JAVA_BINARY}.gz ]; then
#Chrome
tar xzf ${JAVA_BINARY}.gz
elif [ -f ${JAVA_BINARY}.tar ]; then
#Safari
tar xf ${JAVA_BINARY}.tar
elif [ -f ${JAVA_BINARY}.tar.tar ]; then
#Internet Explorer
tar xzf ${JAVA_BINARY}.tar.tar
fi
mv ${EXTRACTED_FOLDER} ${SYNOPKG_PKGDEST}/jre-syno
JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
[ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
#change owner of folder tree
chown -R root:root ${SYNOPKG_PKGDEST}
fi
#extract CPU-specific additional binaries
mkdir ${SYNOPKG_PKGDEST}/bin
cd ${SYNOPKG_PKGDEST}/bin
tar xJf ${TEMP_FOLDER}/${NATIVE_BINS_FILE} && rm ${TEMP_FOLDER}/${NATIVE_BINS_FILE}
[ "${OLD_JNA_NEEDED}" == "true" ] && tar xJf ${TEMP_FOLDER}/${OLD_JNA_FILE} && rm ${TEMP_FOLDER}/${OLD_JNA_FILE}
#extract main archive
cd ${TEMP_FOLDER}
tar xzf ${TEMP_FOLDER}/${DOWNLOAD_FILE} && rm ${TEMP_FOLDER}/${DOWNLOAD_FILE}
#extract cpio archive
cd ${SYNOPKG_PKGDEST}
cat "${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}"/${CPI_FILE} | gzip -d -c - | ${SYNOPKG_PKGDEST}/bin/cpio -i --no-preserve-owner
echo "#uncomment to expand Java max heap size beyond prescribed value (will survive upgrades)" > ${SYNOPKG_PKGDEST}/syno_package.vars
echo "#you probably only want more than the recommended 1024M if you're backing up extremely large volumes of files" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo "#USR_MAX_HEAP=1024M" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo >> ${SYNOPKG_PKGDEST}/syno_package.vars
cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/CrashPlanEngine ${OPTDIR}/bin
cp ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/scripts/run.conf ${OPTDIR}/bin
mkdir -p ${MANIFEST_FOLDER}/backupArchives
#save install variables which Crashplan expects its own installer script to create
echo TARGETDIR=${SYNOPKG_PKGDEST} > ${VARS_FILE}
echo BINSDIR=/bin >> ${VARS_FILE}
echo MANIFESTDIR=${MANIFEST_FOLDER}/backupArchives >> ${VARS_FILE}
#leave these ones out which should help upgrades from Code42 to work (based on examining an upgrade script)
#echo INITDIR=/etc/init.d >> ${VARS_FILE}
#echo RUNLVLDIR=/usr/syno/etc/rc.d >> ${VARS_FILE}
echo INSTALLDATE=`date +%Y%m%d` >> ${VARS_FILE}
[ "${WIZARD_JRE_CP}" == "true" ] && echo JAVACOMMON=${JRE_PATH}/bin/java >> ${VARS_FILE}
[ "${WIZARD_JRE_SYS}" == "true" ] && echo JAVACOMMON=\${JAVA_HOME}/bin/java >> ${VARS_FILE}
cat ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}/install.defaults >> ${VARS_FILE}
#remove temp files
rm -r ${TEMP_FOLDER}/${CP_EXTRACTED_FOLDER}
#add firewall config
/usr/syno/bin/servicetool --install-configure-file --package /var/packages/${SYNOPKG_PKGNAME}/scripts/${SYNOPKG_PKGNAME}.sc > /dev/null
#amend CrashPlanPROe client version
[ "${SYNOPKG_PKGNAME}" == "CrashPlanPROe" ] && sed -i -r "s/^version=\".*(-.*$)/version=\"${CPPROE_VER}\1/" /var/packages/${SYNOPKG_PKGNAME}/INFO
#are we transitioning an existing CrashPlan account to CrashPlan For Small Business?
if [ "${SYNOPKG_PKGNAME}" == "CrashPlanPRO" ]; then
if [ -e /var/packages/CrashPlan/scripts/start-stop-status ]; then
/var/packages/CrashPlan/scripts/start-stop-status stop
cp /var/lib/crashplan/.identity ${PUBLIC_FOLDER}/crashplan-identity.bak
cp -R /var/packages/CrashPlan/target/conf/ ${OPTDIR}/
fi
fi
exit 0
}
preuninst ()
{
`dirname $0`/stop-start-status stop
exit 0
}
postuninst ()
{
if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
source ${SYNOPKG_PKGDEST}/syno_package.vars
fi
[ -e ${OPTDIR}/lib/libffi.so.5 ] && rm ${OPTDIR}/lib/libffi.so.5
#delete symlink if it no longer resolves - PowerPC only
if [ ! -e /lib/libffi.so.5 ]; then
[ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
fi
#remove firewall config
if [ "${SYNOPKG_PKG_STATUS}" == "UNINSTALL" ]; then
/usr/syno/bin/servicetool --remove-configure-file --package ${SYNOPKG_PKGNAME}.sc > /dev/null
fi
exit 0
}
preupgrade ()
{
`dirname $0`/stop-start-status stop
pre_checks
#if identity exists back up config
if [ -f /var/lib/crashplan/.identity ]; then
mkdir -p ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
if [ -f ${OPTDIR}/${FILE_TO_MIGRATE} ]; then
cp ${OPTDIR}/${FILE_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE}
fi
done
for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
if [ -d ${OPTDIR}/${FOLDER_TO_MIGRATE} ]; then
mv ${OPTDIR}/${FOLDER_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig
fi
done
fi
exit 0
}
postupgrade ()
{
#use the migrated identity and config data from the previous version
if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf/my.service.xml ]; then
for FILE_TO_MIGRATE in ${UPGRADE_FILES}; do
if [ -f ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ]; then
mv ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FILE_TO_MIGRATE} ${OPTDIR}/${FILE_TO_MIGRATE}
fi
done
for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
if [ -d ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ]; then
mv ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/${FOLDER_TO_MIGRATE} ${OPTDIR}
fi
done
rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig/conf
rmdir ${SYNOPKG_PKGDEST}/../${SYNOPKG_PKGNAME}_data_mig
#make CrashPlan log entry
TIMESTAMP="`date "+%D %I:%M%p"`"
echo "I ${TIMESTAMP} Synology Package Center updated ${SYNOPKG_PKGNAME} to version ${SYNOPKG_PKGVER}" >> ${LOG_FILE}
fi
exit 0
}
start-stop-status.sh
#!/bin/sh
#--------CRASHPLAN start-stop-status script
#--------package maintained at pcloadletter.co.uk
TEMP_FOLDER="`find / -maxdepth 2 -path '/volume?/@tmp' | head -n 1`"
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/crashplan"
ENGINE_CFG="run.conf"
PKG_FOLDER="`dirname $0 | cut -f1-4 -d'/'`"
DNAME="`dirname $0 | cut -f4 -d'/'`"
OPTDIR="${PKG_FOLDER}/target"
PID_FILE="${OPTDIR}/${DNAME}.pid"
DLOG="${OPTDIR}/log/history.log.0"
CFG_PARAM="SRV_JAVA_OPTS"
JAVA_MIN_HEAP=`grep "^${CFG_PARAM}=" "${OPTDIR}/bin/${ENGINE_CFG}" | sed -r "s/^.*-Xms([0-9]+)[Mm] .*$/\1/"`
SYNO_CPU_ARCH="`uname -m`"
TIMESTAMP="`date "+%D %I:%M%p"`"
FULL_CP="${OPTDIR}/lib/com.backup42.desktop.jar:${OPTDIR}/lang"
source ${OPTDIR}/install.vars
source /etc/profile
source /root/.profile
start_daemon ()
{
#check persistent variables from syno_package.vars
USR_MAX_HEAP=0
if [ -f ${OPTDIR}/syno_package.vars ]; then
source ${OPTDIR}/syno_package.vars
fi
USR_MAX_HEAP=`echo $USR_MAX_HEAP | sed -e "s/[mM]//"`
#do we need to restore the identity file - has a DSM upgrade scrubbed /var/lib/crashplan?
if [ ! -e /var/lib/crashplan ]; then
mkdir /var/lib/crashplan
[ -e ${OPTDIR}/conf/var-backup/.identity ] && cp ${OPTDIR}/conf/var-backup/.identity /var/lib/crashplan/
fi
#fix up some of the binary paths and fix some command syntax for busybox
#moved this to start-stop-status.sh from installer.sh because Code42 push updates and these
#new scripts will need this treatment too
find ${OPTDIR}/ -name "*.sh" | while IFS="" read -r FILE_TO_EDIT; do
if [ -e ${FILE_TO_EDIT} ]; then
#this list of substitutions will probably need expanding as new CrashPlan updates are released
sed -i "s%^#!/bin/bash%#!$/bin/sh%" "${FILE_TO_EDIT}"
sed -i -r "s%(^\s*)(/bin/cpio |cpio ) %\1/${OPTDIR}/bin/cpio %" "${FILE_TO_EDIT}"
sed -i -r "s%(^\s*)(/bin/ps|ps) [^w][^\|]*\|%\1/bin/ps w \|%" "${FILE_TO_EDIT}"
sed -i -r "s%\`ps [^w][^\|]*\|%\`ps w \|%" "${FILE_TO_EDIT}"
sed -i -r "s%^ps [^w][^\|]*\|%ps w \|%" "${FILE_TO_EDIT}"
sed -i "s/rm -fv/rm -f/" "${FILE_TO_EDIT}"
sed -i "s/mv -fv/mv -f/" "${FILE_TO_EDIT}"
fi
done
#use this daemon init script rather than the unreliable Code42 stock one which greps the ps output
sed -i "s%^ENGINE_SCRIPT=.*$%ENGINE_SCRIPT=$0%" ${OPTDIR}/bin/restartLinux.sh
#any downloaded upgrade script will usually have failed despite the above changes
#so ignore the script and explicitly extract the new java code using the chrisnelson.ca method
#thanks to Jeff Bingham for tweaks
UPGRADE_JAR=`find ${OPTDIR}/upgrade -maxdepth 1 -name "*.jar" | tail -1`
if [ -n "${UPGRADE_JAR}" ]; then
rm ${OPTDIR}/*.pid > /dev/null
#make CrashPlan log entry
echo "I ${TIMESTAMP} Synology extracting upgrade from ${UPGRADE_JAR}" >> ${DLOG}
UPGRADE_VER=`echo ${SCRIPT_HOME} | sed -r "s/^.*\/([0-9_]+)\.[0-9]+/\1/"`
#DSM 6.0 no longer includes unzip, use 7z instead
unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -d ${OPTDIR}/lib/ || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "*.jar" -o${OPTDIR}/lib/ > /dev/null
unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -d ${OPTDIR} || 7z e -y ${OPTDIR}/upgrade/${UPGRADE_VER}.jar "lang/*" -o${OPTDIR} > /dev/null
mv ${UPGRADE_JAR} ${TEMP_FOLDER}/ > /dev/null
exec $0
fi
#updates may also overwrite our native binaries
[ -e ${OPTDIR}/bin/libffi.so.5 ] && cp -f ${OPTDIR}/bin/libffi.so.5 ${OPTDIR}/lib/
[ -e ${OPTDIR}/bin/libjtux.so ] && cp -f ${OPTDIR}/bin/libjtux.so ${OPTDIR}/
[ -e ${OPTDIR}/bin/jna-3.2.5.jar ] && cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib/
if [ -e ${OPTDIR}/bin/jna.jar ] && [ -e ${OPTDIR}/lib/jna.jar ]; then
cp -f ${OPTDIR}/bin/jna.jar ${OPTDIR}/lib/
fi
#create or repair libffi.so.5 symlink if a DSM upgrade has removed it - PowerPC only
if [ -e ${OPTDIR}/lib/libffi.so.5 ]; then
if [ ! -e /lib/libffi.so.5 ]; then
#if it doesn't exist, but is still a link then it's a broken link and should be deleted first
[ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
ln -s ${OPTDIR}/lib/libffi.so.5 /lib/libffi.so.5
fi
fi
#set appropriate Java max heap size
RAM=$((`free | grep Mem: | sed -e "s/^ *Mem: *\([0-9]*\).*$/\1/"`/1024))
if [ $RAM -le 128 ]; then
JAVA_MAX_HEAP=80
elif [ $RAM -le 256 ]; then
JAVA_MAX_HEAP=192
elif [ $RAM -le 512 ]; then
JAVA_MAX_HEAP=384
elif [ $RAM -le 1024 ]; then
JAVA_MAX_HEAP=512
elif [ $RAM -gt 1024 ]; then
JAVA_MAX_HEAP=1024
fi
if [ $USR_MAX_HEAP -gt $JAVA_MAX_HEAP ]; then
JAVA_MAX_HEAP=${USR_MAX_HEAP}
fi
if [ $JAVA_MAX_HEAP -lt $JAVA_MIN_HEAP ]; then
#can't have a max heap lower than min heap (ARM low RAM systems)
$JAVA_MAX_HEAP=$JAVA_MIN_HEAP
fi
sed -i -r "s/(^${CFG_PARAM}=.*) -Xmx[0-9]+[mM] (.*$)/\1 -Xmx${JAVA_MAX_HEAP}m \2/" "${OPTDIR}/bin/${ENGINE_CFG}"
#disable the use of the x86-optimized external Fast MD5 library if running on ARM and PPC CPUs
#seems to be the default behaviour now but that may change again
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
if [ "${SYNO_CPU_ARCH}" != "i686" ]; then
grep "^${CFG_PARAM}=.*c42\.native\.md5\.enabled" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
|| sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1 -Dc42.native.md5.enabled=false\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
fi
#move the Java temp directory from the default of /tmp
grep "^${CFG_PARAM}=.*Djava\.io\.tmpdir" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
|| sed -i -r "s%(^${CFG_PARAM}=\".*)\"$%\1 -Djava.io.tmpdir=${TEMP_FOLDER}\"%" "${OPTDIR}/bin/${ENGINE_CFG}"
#now edit the XML config file, which only exists after first run
if [ -f ${OPTDIR}/conf/my.service.xml ]; then
#allow direct connections from CrashPlan Desktop client on remote systems
#you must edit the value of serviceHost in conf/ui.properties on the client you connect with
#users report that this value is sometimes reset so now it's set every service startup
sed -i "s/<serviceHost>127\.0\.0\.1<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${OPTDIR}/conf/my.service.xml"
#default changed in CrashPlan 4.3
sed -i "s/<serviceHost>localhost<\/serviceHost>/<serviceHost>0\.0\.0\.0<\/serviceHost>/" "${OPTDIR}/conf/my.service.xml"
#since CrashPlan 4.4 another config file to allow remote console connections
sed -i "s/127\.0\.0\.1/0\.0\.0\.0/" /var/lib/crashplan/.ui_info
#this change is made only once in case you want to customize the friends' backup location
if [ "${MANIFEST_PATH_SET}" != "True" ]; then
#keep friends' backup data outside the application folder to make accidental deletion less likely
sed -i "s%<manifestPath>.*</manifestPath>%<manifestPath>${MANIFEST_FOLDER}/backupArchives/</manifestPath>%" "${OPTDIR}/conf/my.service.xml"
echo "MANIFEST_PATH_SET=True" >> ${OPTDIR}/syno_package.vars
fi
#since CrashPlan version 3.5.3 the value javaMemoryHeapMax also needs setting to match that used in bin/run.conf
sed -i -r "s%(<javaMemoryHeapMax>)[0-9]+[mM](</javaMemoryHeapMax>)%\1${JAVA_MAX_HEAP}m\2%" "${OPTDIR}/conf/my.service.xml"
#make sure CrashPlan is not binding to the IPv6 stack
grep "\-Djava\.net\.preferIPv4Stack=true" "${OPTDIR}/bin/${ENGINE_CFG}" > /dev/null \
|| sed -i -r "s/(^${CFG_PARAM}=\".*)\"$/\1 -Djava.net.preferIPv4Stack=true\"/" "${OPTDIR}/bin/${ENGINE_CFG}"
else
echo "Check the package log to ensure the package has started successfully, then stop and restart the package to allow desktop client connections." > "${SYNOPKG_TEMP_LOGFILE}"
fi
#increase the system-wide maximum number of open files from Synology default of 24466
[ `cat /proc/sys/fs/file-max` -lt 65536 ] && echo "65536" > /proc/sys/fs/file-max
#raise the maximum open file count from the Synology default of 1024 - thanks Casper K. for figuring this out
#http://support.code42.com/Administrator/3.6_And_4.0/Troubleshooting/Too_Many_Open_Files
ulimit -n 65536
#ensure that Code 42 have not amended install.vars to force the use of their own (Intel) JRE
if [ -e ${OPTDIR}/jre-syno ]; then
JRE_PATH="`find ${OPTDIR}/jre-syno/ -name jre`"
[ -z ${JRE_PATH} ] && JRE_PATH=${OPTDIR}/jre-syno
sed -i -r "s|^(JAVACOMMON=).*$|\1\${JRE_PATH}/bin/java|" ${OPTDIR}/install.vars
#if missing, set timezone and locale for dedicated JRE
if [ -z ${TZ} ]; then
SYNO_TZ=`cat /etc/synoinfo.conf | grep timezone | cut -f2 -d'"'`
#fix for DST time in DSM 5.2 thanks to MinimServer Syno package author
[ -e /usr/share/zoneinfo/Timezone/synotztable.json ] \
&& SYNO_TZ=`jq ".${SYNO_TZ} | .nameInTZDB" /usr/share/zoneinfo/Timezone/synotztable.json | sed -e "s/\"//g"` \
|| SYNO_TZ=`grep "^${SYNO_TZ}" /usr/share/zoneinfo/Timezone/tzname | sed -e "s/^.*= //"`
export TZ=${SYNO_TZ}
fi
[ -z ${LANG} ] && export LANG=en_US.utf8
export CLASSPATH=.:${OPTDIR}/jre-syno/lib
else
sed -i -r "s|^(JAVACOMMON=).*$|\1\${JAVA_HOME}/bin/java|" ${OPTDIR}/install.vars
fi
source ${OPTDIR}/bin/run.conf
source ${OPTDIR}/install.vars
cd ${OPTDIR}
$JAVACOMMON $SRV_JAVA_OPTS -classpath $FULL_CP com.backup42.service.CPService > ${OPTDIR}/log/engine_output.log 2> ${OPTDIR}/log/engine_error.log &
if [ $! -gt 0 ]; then
echo $! > $PID_FILE
renice 19 $! > /dev/null
if [ -z "${SYNOPKG_PKGDEST}" ]; then
#script was manually invoked, need this to show status change in Package Center
[ -e ${PKG_FOLDER}/enabled ] || touch ${PKG_FOLDER}/enabled
fi
else
echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" > "${SYNOPKG_TEMP_LOGFILE}"
echo "${DNAME} failed to start, check ${OPTDIR}/log/engine_error.log" >&2
exit 1
fi
}
stop_daemon ()
{
echo "I ${TIMESTAMP} Stopping ${DNAME}" >> ${DLOG}
kill `cat ${PID_FILE}`
wait_for_status 1 20 || kill -9 `cat ${PID_FILE}`
rm -f ${PID_FILE}
if [ -z ${SYNOPKG_PKGDEST} ]; then
#script was manually invoked, need this to show status change in Package Center
[ -e ${PKG_FOLDER}/enabled ] && rm ${PKG_FOLDER}/enabled
fi
#backup identity file in case DSM upgrade removes it
[ -e ${OPTDIR}/conf/var-backup ] || mkdir ${OPTDIR}/conf/var-backup
cp /var/lib/crashplan/.identity ${OPTDIR}/conf/var-backup/
}
daemon_status ()
{
if [ -f ${PID_FILE} ] && kill -0 `cat ${PID_FILE}` > /dev/null 2>&1; then
return
fi
rm -f ${PID_FILE}
return 1
}
wait_for_status ()
{
counter=$2
while [ ${counter} -gt 0 ]; do
daemon_status
[ $? -eq $1 ] && return
let counter=counter-1
sleep 1
done
return 1
}
case $1 in
start)
if daemon_status; then
echo ${DNAME} is already running with PID `cat ${PID_FILE}`
exit 0
else
echo Starting ${DNAME} ...
start_daemon
exit $?
fi
;;
stop)
if daemon_status; then
echo Stopping ${DNAME} ...
stop_daemon
exit $?
else
echo ${DNAME} is not running
exit 0
fi
;;
restart)
stop_daemon
start_daemon
exit $?
;;
status)
if daemon_status; then
echo ${DNAME} is running with PID `cat ${PID_FILE}`
exit 0
else
echo ${DNAME} is not running
exit 1
fi
;;
log)
echo "${DLOG}"
exit 0
;;
*)
echo "Usage: $0 {start|stop|status|restart}" >&2
exit 1
;;
esac
install_uifile & upgrade_uifile
[
{
"step_title": "Client Version Selection",
"items": [
{
"type": "singleselect",
"desc": "Please select the CrashPlanPROe client version that is appropriate for your backup destination server:",
"subitems": [
{
"key": "WIZARD_VER_483",
"desc": "4.8.3",
"defaultValue": true
}, {
"key": "WIZARD_VER_480",
"desc": "4.8.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_470",
"desc": "4.7.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_460",
"desc": "4.6.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_452",
"desc": "4.5.2",
"defaultValue": false
},
{
"key": "WIZARD_VER_450",
"desc": "4.5.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_441",
"desc": "4.4.1",
"defaultValue": false
},
{
"key": "WIZARD_VER_430",
"desc": "4.3.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_420",
"desc": "4.2.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_370",
"desc": "3.7.0",
"defaultValue": false
},
{
"key": "WIZARD_VER_364",
"desc": "3.6.4",
"defaultValue": false
},
{
"key": "WIZARD_VER_363",
"desc": "3.6.3",
"defaultValue": false
},
{
"key": "WIZARD_VER_3614",
"desc": "3.6.1.4",
"defaultValue": false
},
{
"key": "WIZARD_VER_353",
"desc": "3.5.3",
"defaultValue": false
},
{
"key": "WIZARD_VER_341",
"desc": "3.4.1",
"defaultValue": false
},
{
"key": "WIZARD_VER_33",
"desc": "3.3",
"defaultValue": false
}
]
}
]
},
{
"step_title": "Java Runtime Environment Selection",
"items": [
{
"type": "singleselect",
"desc": "Please select the Java version which you would like CrashPlan to use:",
"subitems": [
{
"key": "WIZARD_JRE_SYS",
"desc": "Default system Java version",
"defaultValue": false
},
{
"key": "WIZARD_JRE_CP",
"desc": "Dedicated installation of Java 8",
"defaultValue": true
}
]
}
]
}
]
Changelog:
- 0047 30/Oct/17 – Updated dedicated Java version to 8 update 151, added support for additional Intel CPUs in x18 Synology products.
- 0046 26/Aug/17 – Updated to CrashPlan PRO 4.9, added support for migration from CrashPlan For Home to CrashPlan For Small Business (CrashPlan PRO). Please read the Migration section on this page for instructions.
- 0045 02/Aug/17 – Updated to CrashPlan 4.8.3, updated dedicated Java version to 8 update 144
- 0044 21/Jan/17 – Updated dedicated Java version to 8 update 121
- 0043 07/Jan/17 – Updated dedicated Java version to 8 update 111, added support for Intel Broadwell and Grantley CPUs
- 0042 03/Oct/16 – Updated to CrashPlan 4.8.0, Java 8 is now required, added optional dedicated Java 8 Runtime instead of the default system one including 64bit Java support on 64 bit Intel CPUs to permit memory allocation larger than 4GB. Support for non-Intel platforms withdrawn owing to Code42’s reliance on proprietary native code library libc42archive.so
- 0041 20/Jul/16 – Improved auto-upgrade compatibility (hopefully), added option to have CrashPlan use a dedicated Java 7 Runtime instead of the default system one, including 64bit Java support on 64 bit Intel CPUs to permit memory allocation larger than 4GB
- 0040 25/May/16 – Added cpio to the path in the running context of start-stop-status.sh
- 0039 25/May/16 – Updated to CrashPlan 4.7.0, at each launch forced the use of the system JRE over the CrashPlan bundled Intel one, added Maven build of JNA 4.1.0 for ARMv7 systems consistent with the version bundled with CrashPlan
- 0038 27/Apr/16 – Updated to CrashPlan 4.6.0, and improved support for Code 42 pushed updates
- 0037 21/Jan/16 – Updated to CrashPlan 4.5.2
- 0036 14/Dec/15 – Updated to CrashPlan 4.5.0, separate firewall definitions for management client and for friends backup, added support for DS716+ and DS216play
- 0035 06/Nov/15 – Fixed the update to 4.4.1_59, new installs now listen for remote connections after second startup (was broken from 4.4), updated client install documentation with more file locations and added a link to a new Code42 support doc
EITHER completely remove and reinstall the package (which will require a rescan of the entire backup set) OR alternatively please delete all except for one of the failed upgrade numbered subfolders in /var/packages/CrashPlan/target/upgrade before upgrading. There will be one folder for each time CrashPlan tried and failed to start since Code42 pushed the update - 0034 04/Oct/15 – Updated to CrashPlan 4.4.1, bundled newer JNA native libraries to match those from Code42, PLEASE READ UPDATED BLOG POST INSTRUCTIONS FOR CLIENT INSTALL this version introduced yet another requirement for the client
- 0033 12/Aug/15 – Fixed version 0032 client connection issue for fresh installs
- 0032 12/Jul/15 – Updated to CrashPlan 4.3, PLEASE READ UPDATED BLOG POST INSTRUCTIONS FOR CLIENT INSTALL this version introduced an extra requirement, changed update repair to use the chrisnelson.ca method, forced CrashPlan to prefer IPv4 over IPv6 bindings, removed some legacy version migration scripting, updated main blog post documentation
- 0031 20/May/15 – Updated to CrashPlan 4.2, cross compiled a newer cpio binary for some architectures which were segfaulting while unpacking main CrashPlan archive, added port 4242 to the firewall definition (friend backups), package is now signed with repository private key
- 0030 16/Feb/15 – Fixed show-stopping issue with version 0029 for systems with more than one volume
- 0029 21/Jan/15 – Updated to CrashPlan version 3.7.0, improved detection of temp folder (prevent use of /var/@tmp), added support for Annapurna Alpine AL514 CPU (armhf) in DS2015xs, added support for Marvell Armada 375 CPU (armhf) in DS215j, abandoned practical efforts to try to support Code42’s upgrade scripts, abandoned inotify support (realtime backup) on PowerPC after many failed attempts with self-built and pre-built jtux and jna libraries, back-merged older libffi support for old PowerPC binaries after it was removed in 0028 re-write
- 0028 22/Oct/14 – Substantial re-write:
Updated to CrashPlan version 3.6.4
DSM 5.0 or newer is now required
libjnidispatch.so taken from Debian JNA 3.2.7 package with dependency on newer libffi.so.6 (included in DSM 5.0)
jna-3.2.5.jar emptied of irrelevant CPU architecture libs to reduce size
Increased default max heap size from 512MB to 1GB on systems with more than 1GB RAM
Intel CPUs no longer need the awkward glibc version-faking shim to enable inotify support (for real-time backup)
Switched to using root account – no more adding account permissions for backup, package upgrades will no longer break this
DSM Firewall application definition added
Tested with DSM Task Scheduler to allow backups between certain times of day only, saving RAM when not in use
Daemon init script now uses a proper PID file instead of Code42’s unreliable method of using grep on the output of ps
Daemon init script can be run from the command line
Removal of bash binary dependency now Code42’s CrashPlanEngine script is no longer used
Removal of nice binary dependency, using BusyBox equivalent renice
Unified ARMv5 and ARMv7 external binary package (armle)
Added support for Mindspeed Comcerto 2000 CPU (comcerto2k – armhf) in DS414j
Added support for Intel Atom C2538 (avoton) CPU in DS415+
Added support to choose which version of CrashPlan PROe client to download, since some servers may still require legacy versions
Switched to .tar.xz compression for native binaries to reduce web hosting footprint - 0027 20/Mar/14 – Fixed open file handle limit for very large backup sets (ulimit fix)
- 0026 16/Feb/14 – Updated all CrashPlan clients to version 3.6.3, improved handling of Java temp files
- 0025 30/Jan/14 – glibc version shim no longer used on Intel Synology models running DSM 5.0
- 0024 30/Jan/14 – Updated to CrashPlan PROe 3.6.1.4 and added support for PowerPC 2010 Synology models running DSM 5.0
- 0023 30/Jan/14 – Added support for Intel Atom Evansport and Armada XP CPUs in new DSx14 products
- 0022 10/Jun/13 – Updated all CrashPlan client versions to 3.5.3, compiled native binary dependencies to add support for Armada 370 CPU (DS213j), start-stop-status.sh now updates the new javaMemoryHeapMax value in my.service.xml to the value defined in syno_package.vars
- 0021 01/Mar/13 – Updated CrashPlan to version 3.5.2
- 0020 21/Jan/13 – Fixes for DSM 4.2
- 018 Updated CrashPlan PRO to version 3.4.1
- 017 Updated CrashPlan and CrashPlan PROe to version 3.4.1, and improved in-app update handling
- 016 Added support for Freescale QorIQ CPUs in some x13 series Synology models, and installer script now downloads native binaries separately to reduce repo hosting bandwidth, PowerQUICC PowerPC processors in previous Synology generations with older glibc versions are not supported
- 015 Added support for easy scheduling via cron – see updated Notes section
- 014 DSM 4.1 user profile permissions fix
- 013 implemented update handling for future automatic updates from Code 42, and incremented CrashPlanPRO client to release version 3.2.1
- 012 incremented CrashPlanPROe client to release version 3.3
- 011 minor fix to allow a wildcard on the cpio archive name inside the main installer package (to fix CP PROe client since Code 42 Software had amended the cpio file version to 3.2.1.2)
- 010 minor bug fix relating to daemon home directory path
- 009 rewrote the scripts to be even easier to maintain and unified as much as possible with my imminent CrashPlan PROe server package, fixed a timezone bug (tightened regex matching), moved the script-amending logic from installer.sh to start-stop-status.sh with it now applying to all .sh scripts each startup so perhaps updates from Code42 might work in future, if wget fails to fetch the installer from Code42 the installer will look for the file in the public shared folder
- 008 merged the 14 package scripts each (7 for ARM, 7 for Intel) for CP, CP PRO, & CP PROe – 42 scripts in total – down to just two! ARM & Intel are now supported by the same package, Intel synos now have working inotify support (Real-Time Backup) thanks to rwojo’s shim to pass the glibc version check, upgrade process now retains login, cache and log data (no more re-scanning), users can specify a persistent larger max heap size for very large backup sets
- 007 fixed a bug that broke CrashPlan if the Java folder moved (if you changed version)
- 006 installation now fails without User Home service enabled, fixed Daylight Saving Time support, automated replacing the ARM libffi.so symlink which is destroyed by DSM upgrades, stopped assuming the primary storage volume is /volume1, reset ownership on /var/lib/crashplan and the Friends backup location after installs and upgrades
- 005 added warning to restart daemon after 1st run, and improved upgrade process again
- 004 updated to CrashPlan 3.2.1 and improved package upgrade process, forced binding to 0.0.0.0 each startup
- 003 fixed ownership of /volume1/crashplan folder
- 002 updated to CrashPlan 3.2
- 001 30/Jan/12 – intial public release
PC LOAD LETTER 
Thanks for doing all this work and sharing your findings. This was a primary motivator in me also choosing to buy and set up a Synology device for my home file storage.
My setup and some things I’ve learned are documented here:
http://www.scottkoland.com/blog/my-home-file-server-solution-synology-and-crashplan/
Thanks, Scott
Patters,
Because of Code42’s licensing changes from 3.4.x to 3.5.x, I’m staying with 3.4 Server for the foreseeable future. When I look at the repository, the only PROe client I see is for 3.5.x. Is there any way the 3.4.x client can be made available
Patters is prohibited from distributing the CrashPlan package, so his install.sh script (see above) downloads it from the CP website for each install.
I tried a version number mentioned above without success (“http://download.crashplan.com/installs/linux/install/CrashPlanPROe_3.4.1_Linux.tgz”), so they may only be providing the latest version on their website.
I would start by requesting the install package in the required version from CP.
Thanks for the terrific work done in getting Crashplan to Synology devices.
I was using a Linux host as a NAS and had Crashplan+ running successfully on it, and it had backed up ~250GB from it to Crashplan cloud. A couple of days ago, I replaced the Linux host with a Synology DS413. Followed the instructions here exactly and got Crashplan running on it. I had previously copied all files from the Linux host to the Synology, so they were all present on the new NAS. I chose the Adopt option and after checking, Crashplan reported all the file sets were “missing”. So without deselecting the original files, I selected all the folders where the same files resided on the new NAS. It went off and started synchronisation. That finished in a few hours but I saw it reported that it needed to backup everything. Don’t know why it didn’t detect the files as ones that had already been backed up. So that’s months of backups it wants to do again. BTW, the original files are still selected (and still shown as missing, as I haven’t deselected them).
At the same time, it is now backing up the files anew and has uploaded around 2.5GB but on the Crashplan GUI, it shows zero files uploaded, even though it shows ~2.5GB data uploaded (which is many files). But the file count still shows zero.
Asked Syno support but the answer was in effect unsupported platform and Java version. The service log on the Syno is showing many instances of a couple of Java exceptions, the first is “Exception extracting glibc version, com.code42.jna.PlatformException: Exception in uname()” and the second is probably related to the first, “BSM:: Exception initializing WatcherDriver – e=java.io.IOException: Platform is not supported, glibc: unknown, kernel: unknown”.
Any idea what I could do here?
Hi, i have the same problem. What to do now?
http://pastebin.com/hQyreLun
John B>
I understand that Patters is not able to redistribute the CrashPlan package and his install script downloads it from the CP site. No problem there. The problem is that the PROe client on his repository will download the 3.5.x client. I need one that will download the 3.4.1 client. Here’s why. . .
v3.4 is licensed on a per-client basis. Which makes sense for an enterprise product. v3.5, however, is licensed on a *per-user* basis and allows up to 4 devices to be backed up per user. Now, I can think of no use case where an enterprise would want to combine a bunch of disparate machines under one CP user account. Why would I allow one of my users to have access to the backups of 3 of his co-workers? As a managed service provider, nearly every backup I do is backing up a single server at a single client. So the ability to backup more than 1 machine per user is pretty worthless to me. I can see the value of *per-user* licensing for CrashPlan’s “Green” or “Blue” product. But for the “Black” *Enterprise* product, it makes no sense to me. And in my opinion it sort of shows Code42 as being out of touch with how the “Black” product is actually used. At any rate, this is why many admins are sticking with PROe 3.4.x servers. Of course, the 3.5.x client won’t work with a 3.4.x server.
All that said. . .I was able to get what I needed. As I mentioned, the the PC Load Letter Synology repository has only the 3.5.x client for PROe. I did some poking around and found http://packages.pcloadletter.co.uk/downloads/old/ In there, I found crashplanproe3.4.1-merged-0020.spk. I downloaded that, did a manual install from my Synology box, and it worked just fine. It’s important to note that upon install, this package immediately offered to update to Patter’s 3.5.3 client. DO NOT UPGRADE if you are backing up to a 3.4.x server. (A 3.5 client can’t back up to a 3.4 server, remember :) )
I just wish it didn’t have to be so hard. So, Patters. . .here’s my request. Since I can’t be the only one who’s sticking with PROe Server 3.4.x. . .
• Please make the PROe client available for both 3.4.1 and 3.5.x in your repository.
• For the 3.4.1, please turn off updating so that it isn’t upgraded to 3.5.x by accident.
In any case, a big thanks to Patters for making this whole process go.
Mike Castaldi
Wild Frog Consulting
Is it possible to backup both the NAS and the local computer from the same CrashPlan GUI?
I seem to be only able to backup the Desktop + mounted Shared Folders (no headless) or reset the GUI to run the NAS only. Am I missing something? Fallback plan is to create a separate user (mac os) to manage the NAS CrashPlan, but that’s less optimal.
My backup is failing – apparently because of out of memory problems since my backup is large ~5Tb. Currently I have 1Gb but I’m searching for the expansion specifications for my 1010+ unit to bring it up to 3Gb and will buy more.
In the meantime if I understand the details above the engine dynamically allocates memory based on the backup but there is some potential to force this to persist by editing
>>>/volume1/@appstore/CrashPlan/syno_package.vars
But for the life of me I cannot find this directory on my Synology server. Is it hidden and hence I can’t see this or am I supposed to be finding this on my Mac that I edited the file on point to the synology server for backup?
Thanks,
@nvt1
You can find the folder when you ssh to your synology box. Remember to connect as root. Same password as admin account.
/Michal.
Thanks – I managed to ssh as root and opened the file with VI but now need to wait for the additional memory I ordered to show up and be installed before I can apply any useful edit. Assuming the additional 2Gb module shows up taking my 1010+ to 3Gb of memory what should I make the default memory be to give it the best chance of working given the 5Tb of files to backup
@nvt1
I also have/had problems with my ds212j with 256mb of memory. I have set the value to 1664mb the 1536mb value didnt work for me.
You can change the value to something higher than you have this will make the synology box swap on disk. I tried a value of 2048mb and the CP service would not start. The 1664mb value had my box starting to backup again but for some reason it is slow as h…
With the default value the CP service works but stalls at analyzing / sending the same file forever.
/michal
First of all, thank you for your brilliant work. I can’t say how grateful I am to be able to use Crashplan on my Synology.
I am using the smallest Synology configuratio there is – DS110J. Yes, the one with only one hard drive and only 128 MB RAM. However, your solution seems to work perfectly. I was able to backup over 500 GB over the net to the CrashPlan central.
What I don’t quite understand is why this only works for a few days/weeks. For some reason the Crashplan engine stops connecting to the central. The Synology package is working, but the client (installed on my laptop) cannot connect to it. So what I usually do is I stop the Crashplan service (package) on Synology admin panel, uninstall it, and install the newest package I find on your server. Then I restart it and try to connect to Synology with my Crashplan client. It usually works, but I need to “adopt” the machine over and over again. With 500 GB of data the synchronization takes almost a full day, but once that’s completed I have th backup running again.
I am just curious if there something I could do to avoid restarting/reinstalling/re-synchronizing over and over again…
Thanks a lot!
Pingback: Backup iPhone to Crashplan with Synology DS412+ | Random Reviews
I have developed a recent issue where I am unable to connect to the headless crashplan on my synology ds1512+. When I open crashplan on my mac, it just times out and can not connect. I have tried un-installing and re-installing the packages on the synology as well as on my Mac to no avail. Assistance would be greatly appreciated.
This is the Java package that I have been using is.
jdk-6u45-linux-i586-.bin
I also have increased the memory allocation to 1012.
Waiting for connection…
Alas the “waiting for connection” hiccup has hit me. I have crashplan installed and working on HP N54L microserver backing up to friend with exactly the same configuration. Its been working fine for weeks, till a few days ago.
Both on my side and my friend’s side, crashplan says waiting for connection. Yet checking the connection and ports with telnet, confirm the ip addresses and ports are open. The connection status is: disconnected, retrying < 1min.
I've tried everything, stopping/starting crashplan server, rebooting the machines, uninstalling and reinstalling crashplan server, uninstalling and reinstalling crashplan and java. Trying different ports…
Nothing has worked.
Please help….:(
exact same problem, was working fine before, changed nothing.
All ports are open :-(
Same thing for me as well… DS213j. CrashPlan Central connection still works fine, but my “friend” can no longer connect even though I have performed the same troubleshooting steps as above. Everything was working fine for the first couple of weeks and now: Waiting for connection…
Interesting: Now the backup from my “friend” is working again…. With no additional intervention from myself. So, it went for 9 days “waiting for connection…”, my troubleshooting steps had no positive effect, and now, after letting it sit for a couple more days it is connected and has completed my “friends” backup.
Hope this information is of use to someone!
Hi,
I use this Java package on my DS1512+ and Crashplan runs great:
ejre-1_6_0_38-fcs-b05-linux-i586-headless-13_nov_2012
Maybe you have the wrong Java Package?!
Regards
Thanks for your tip Adam,
How do i install that version of Java. Its a tar.gz format. I’ve got synology installed on HP N54L microserver. I’ve been using this Java version: jdk-6u45-linux-i586.bin
I figured it out (how to download Java version that is). Thanks.
Installed the suggest java release: ejre-1_6_0_38-fcs-b05-linux-i586-headless-13_nov_2012, still no joy :(
Any other ideas of help? Would be really appreciated
Hello, can I see somewhere on which Server I am connected on the CrashCentral?!
Is there a log, where I can see this?!
Thanks for your help.
Regards
I am having a similar problem – every time I open the local CrashPlan application that points to the Synology DS1010+ server. It shows it connected and I can select directories.
It is busy counting up the files and size and after about ~1min it pops up an Error message:
“Crashplan has been disconnected from the backup Engine” with an “OK” button
Click OK and the Crashplan client closes.
The log on the Synology server shows it is running (I have stopped and restarted it).
Is shows:
Time/Date Crashplan Started
Time/Date Backup Scheduled to always run
Time/Date {Default] Starting backup to Crashplan central. 5 files (383.90KB) to back up
Time/Date +2 mins Crashplan Started
Time/Date +2 mins Backup Scheduled to always run
Time/Date +2 mins {Default] scanning for files to backup
This repeats multiple times
I have Java installed on the Synology Server via the Package Center management console
IT reports Java 1.6.0_38
I upgraded the Synology Memeory to 3GB and manually edited the preference file
/volume1/@appstore/CrashPlan/syno_package.vars
To force memory allocation of 1536Mb
Crashplan central reports I am not backing up.
I’m running it on a HP N54L mircroserver bits configured with 8GB RAM.
CrashPlan ran perfectly for weeks and then just stopped. Simply can’t get it to start again. :(
Similar issue here on a 213+. Suggestions welcome
Resolved. Appears it was a memory issue, so I’ve increased (added to) the size of the swap file on the 213+ and increased the heapsize in syno_package.vars to 1024M.
dd if=/dev/zero of=/example_swap bs=1024 count=500000
mkswap /example_swap
swapon /example_swap
reference:
Hi,
waht means this?
Config already has a value for Java memory heap max; mx=512m ?!
In my /volume1/@appstore/CrashPlan/syno_package.vars is the Size on 2048?! What’s going wrong?!
Thanks for your assitance.
Okay I have found the failure. Now it works :)
And how did you resolve it?
Incase its any use to anyone, my crashplan has started to work again. No idea, what caused it to stop and why it restarted. No amount of restarts, reinstalls, messing around with permissions or ports did anything.
Interesting, same thing for me… see my reply above dated August 15, 2013.
At first I had reinstall CrashPlan on my DS1512+ after that I have edit the syno_package.vars but I think I have forget last time, to delete the # on the front of the line.
Now it use the 2048M ram :)
Pingback: RAM bővítés | NAS Blog
Pingback: Network Attached Sweetness, BitTorrent Sync and more | hallgeir.org
Problem “Too many open files”.
Hi patters,
I still have a problem with a 1813+ and the error “Too many open files”.
I tried the hints from that link:
but the error still exists. It looks like, changing the limit in the CrashPlanEngine-file (/volum1/@appstore/CrashPlanPROe/bin/CrashPlanEngine) doesn’t have any effect.
The log-file still shows an ulimit of 4096. I changed the value to 65536 in the CrashPlanEngine file.
Any hints about that?
Thanks in advance
Just an additional info/question:
I increased the open files limit in the CrashPlanEngine file to 131072 and in the /etc/sysctl.conf (fs.file-max=131072).
Is it correct, that the CrashPlanEngine is running with the privileges of the “crashplanproe”-user? So maybe I need to increase that value for that user? Where can I do that?
Thanks in advance
Sven
a correction: the link was wrong: I followed the tips from that link:
https://helpdesk.crashplan.com/entries/23997797-Troubleshooting-Too-many-open-files-
Hi Sven
After I spend some hours chasing this issue, I found a solution.
I added “ulimit -n 65000” to /var/packages/CrashPlan/scripts/start-stop-status.sh
If I cat limits on a crashplan process :
Max open files 65000 65000 files
This resolved my problem with “Too many open file”
Maybe you already solved this problem.
But now I am replying anyway, so others can google for a solution :)
Before I found this fix, I added “ulimit -n 65000” to /etc/profiles. It didn’t change anything, I haven’t tried to change .profile in the home dir, for my crashplan user. I don’t now if that can have any effect.
/Casper
Hi Casper,
where do You add this line to the script? If I add this line I get an error on executing the start-stop-status.sh script that setting this ulimit isn’t allowed (I am logged in as root).
I tried something:
I added the
ulimit -n 65536 to the .profile of the crashplanproe-user.
When I now execute “start-stop-status.sh start” as root, the “can’t connect to Backup destination” message disappears and everything is working fine…
BUT
As soon, as I close the ssh-connection, the package stops. I tried
“start-stop-status.sh start &”
“nohup & start-stop-status.sh start”
every time, I close the ssh-session, the CrashPlanPackage stopps.
Trying to execute the script from Web Konsole start the package, but brings back the error “can’t connect to Backup destination”.
Despite I have removed my change to the start-stop-status.sh-script-modification (ulimit -n 65536) I still get the error message, that this limit-change isn’t allowed. But the line is removed from the script.
The Default “start/stop”-execution from the package center results in the error “can’t connect to Backup destination”. The same after a standard reboot of the Synology….
Paters? Any Idea? Top shows, that the package is always running as the “crashplanproe”-user.
But I think this looks like a problem to connect to the local Backup archive (the online Backup is running fine).
The editing of the .profile of the crashplanproe-user seems to do the right thing, but this change is only “useable” via a running ssh-session (as root)… strange
DS1813+, 4GB RAM, DSM4.3-3810
CrashPlanPROe-package 3.6.1.4
Sven,
I have added that right after the first comments of the file and before anyother code, and I didn’t have any issues, my machine is still working on sync all data again. Apparently it will work perfectly, but I will let the community know, once it finishes and starts the regular backups.
Hi Flavio,
it is strange, that the start-stop-statush.sh script mentions the ulimit-line, which already was removed from the script. Currently CrashPlan is only working correct (without that line in the script, but with the modification of the crashplanproe/.profile-modification) if startet via an ssh session and not stopping that one..
Sven,
Probably your are facing a different thing than me because I’m running the Crashplan Home edition not the Pro edition.
When I was looking for solution to my issue, I step into this thread http://forum.synology.com/enu/viewtopic.php?f=90&t=46078
look at the last post from Mathieu, it may help you at least understand what might be happening.
By the way, I have not added the ulimit line on .profile.
I have only made the suggestion by Crashplan (that didn’t solve my issue) and Casper K. (that apparently solved).
Crashplan link: http://support.code42.com/Administrator/Latest/Troubleshooting/Too_Many_Open_Files
Have you tried this already?
Flavio
Hi Sven
I did the same as Flavio mentioned, I added the ulimit in the begining of the start-stop script.
My .profile in crashplan home dir, does have ulimit -n 65000, but I really don’t remember that I changed it, and I haven’t updated the Crashplan package.
I am using Crashplan Home edition
.
My suggestion is to check our file persmission on the start-stop script and the home dir, just to be sure, and check the system-wide limits here: cat /proc/sys/fs/file-max
If you haven’t done this already.
/Casper
Hi Casper,
Yes.. confirmed. today it finished all the sync and compact processes. and Yes it is now working normally with the ulimit set.
Thanks again,
Flavio
So,
DSM 4.3 is now Final. Can we update?! And Crashplan will still work?
Thanks for this amazing feature!
Adam, if you try, the rest of us will know if it will work ;-)
Patters is not contacted by Synology if there is an update, the knowledge of working packages is gathered by the users of these packages. Trial and error.
I did not try the 4.3 beta, no info from me in this.
CrashPlan+ is working on DSM 4.3 on my DS710+.
Hi,
thanks for the reply. This sounds good that it works on DSM 4.3
You have reinstall the Java Package, after you have update your DS?!
Regards
Yes I know but I don’t have an Test DS so I can’t try it ;-)
Maybe someone has two DS and can try it. I hope that someone will do this.
I didn’t have to reinstall Java. I didn’t have to do anything–I even left CP+ running while I upgraded DSM, and everything started right back up when the NAS rebooted. It was literally a two-click upgrade, one to download DSM 4.3 and one to upgrade.
Okay, because I read this here:
If you update DSM later, you will need to re-install this package or else UTF-8 and locale support will be broken by the update.
But this is maybe only important for Europe Members ;)
@Adam – it depends on what Java package you installed.
Synology provides a Java Manager from Oracle as a standard DSM package today, but this was not always the case, so Patters originally added UTF-8 support to a Java for Embedded package and provides this for download aswell.
A DSM upgrade removes his custom UTF-8 support, so you need to reinstall Java, if you are using Patters Java for Embedded package.
The official Synology/Oracle package does not seem to have this issue (instead it requires a hefty 230MB JDK on my DS411+II).
I guess that if you can guarantee the use of plain vanilla ASCII (A-Z, 0-9) character file names only that it doesn’t matter, but it does if you have documents containing characters like “áäãâå” etc.
I upgraded to DSM 4.3 yesterday. I didn’t do anything else apart from upgrading DSM and the upgraded Synology packages (eg photostation). I did not reinstall Java.
Crashplan started fine after the upgrade. I scheduled my backups overnight and I can confirmed that it ran ok.
Okay,
It’s maybe depends on which DS you run CrashPlan. I have an DS1512+.
But thanks for that! So maybe I will also Update my DS to 4.3
Hi, thanks for a great bit of software, but I have a small issue/question. I set up my new ds213+ using as per your and Scott H’s guide and ran my first test backup. All worked fine and dandy. However, I added some more files to the directory to be backed up and I expected it to be done pretty soon after. This didn’t happen and it was another 5 hours before it did another backup. Is this right?
Is there a config setting I need to adjust?
Cheers
Paul
Hi,
thank you very much! With your help and the help of other sites i got Crashplan working on a DS213J.
Now i see that there is an Update to DSM 4.3-3776. Is Crashplan running fine on it? Or do i have to update anything else after upgrading to DSM 4.3-3776 from DSM 4.2
Yes it works fine. After the DSM upgrade you should stop CrashPlan and remove and reinstall the Java package though, because DSM updates always break the locale and UTF-8 support. If you have non-US characters in your filenames this could be an issue.
Does the inbuilt Synology Java package suport UTF-8?
First of all, congratulations for the excellent work (package and guide)! I´ve been using CrashPlan for half an year now on my ds212 without any problems, and I´m very happy!
About the schedule, there´s no need to edit the crontab, you can use the system´s own Task Scheduler to start and stop the service using the “custom script” option. Works like a charm!
What exactly did you put in the Run: command field for your Start task? I put this… “/var/packages/CrashPlan/scripts/start-stop-status start” and while the script works if I run it manually, it does not appear to be running at the scheduled times. Any advice?
Hello,
Thank you for your great work. My setup is 1812+ synology backups up 3 pc over the internet using domain (dns) pointing to the local IP and 2 internal macs (router portforwards 4243 to the local IP).
Few questions I have: 1) I can easily connect to my synology over the internet and through the crashplan desktop app get assess to the root and all files in it, shouldn’t I get access (manage) crash plan on synology only if i tunnel it through ssh or vpn, as to local IP (192.168.X.X) can manage it and see all folders in it ? If not selecting on synology’s crashplan require password to access, its even easier to get access to all your files on synology
2) Isn’t very insecure with one password (crash plan’s login) to get full access to the root and a hacker can backup full synology to his own PC ?
3) is it possible if you have your login details established already for a second malicious crash plan login to establish connection and get full access to the root ?
4) Can I restrict the access to the root fully ? (as I am not backing up synology, only PCs to synology) ?
Thank you
I upgrade to DSM 4.3 on my DS1812+ (3GB ram) and now my CrashPlan backups are stuck with ‘Connecting to backup destination’. I did an update of both platter’s java and the crashplan client. Then I did an uninstall and reinstall of the java client. I fear I may need to uninstall and reinstall the crashplan client but I afraid of losing all my backup sets. I assume an uninstall will delete all my configuration information so is there a way for me to backup some of that and restore it after the re-install?
When you reinstall CrashPlan completely you can adopt an existing computer account in the initial configuration menus. Then it will run through all the files comparing the checksums – saving you the grief of backing it all up again. It may take a while but only changed files will be copied.
The message “Connecting to backup destination” in most cases is a problem of “reaching the open files limit”. Check the service.log.0 of CrashPlan and search for “many open files”.
If their are messages “Too many open files”, You need to adjust the open files limit of the Synology and the CrashPlan service. Just look a the comment a wrote here a few weeks ago.
Ive got this working fine I just want it to hibernate but I can access the crontab I just get permission denied. What do I need to do? Thanks Dave
I’ve just replaced my Synology with a DS213j, and it won’t start. Can anyone help me. I previously had it working on my DS211j, so reasonably sure I haven’t done anything too silly. (But never rule that out!)
The only thing in the engine_error.log is:
/volume1/@appstore/CrashPlan/bin/nice: /volume1/@appstore/java7/jre/bin/java: No such file or directory
Sussed it, it’s the wrong java package, followed instructions here:
http://forum.minimserver.com/showthread.php?tid=774
Confirmed server on NAS is running, installed Desktop client on Win64, changed the ui.properties file to point to the server address on the NAS, Now, when I start the Desktop client the login screen is asking for a username, password, AND the PROe Server address. What exactly is supposed to go in that field? I entered the IP:PORT for the CP server on my NAS (e.g. 192.168.1.6:4243), but every time is says “Unable to Connect, check your network”
Looking at the service.log on the NAS sever, this is what it says:
http://pastebin.com/zv7udxqG
Can you please explain what I’m encountering and how to resolve it?
Nevermind. I just now realized that there were different packages, and I installed the PRO E package instead of the vanilla CrashPlan. All is well now. Thanks for your efforts with this package – I used your affiliate link above!
I recently moved and when I turned my pc on at the new location the crashplan app disappeared from my ds213. I reinstalled it and now i cant connect to my crashplan central account without having to upload everything again. This is not really an option since it took me almost 3 months to upload. Is there a way to connect to my original backup?
You should be able to look up the GUID of your device that uploaded the data by logging into CrashPlan Central. Then using the client’s CLI mode you can reset the new installation’s GUID to match. I think I mentioned this in the notes on here.
Thank you so much for putting so much effort into this. I was able to install and run CrashPlan on my 413j with relative ease a few weeks ago.
It was running smoothly until yesterday when it suddenly stopped working. I didn’t change anything on my Diskstation (not manually). The package just stopped running. When I go for Action > Run it displays a loading animation and then returns to the package info and still says ‘stopped’. Any idea why the package suddenly stopped working and what I can do to get it running again?
In case anyone looking for a solution finds my comment:
It turns out my issue was linked to the Java update. Having downloaded and installed the new Java package I was able to get my backups working again.
First that you very much for this package. I really like the CrashPlan product and this package making it available on the Synology DiskStation is great.
I am concerned. I have a DS1512+ with 3GB of RAM running DSM 4.3. I used the Synology Java Manager to install Java and it reports that I am running version 1.6.0_45. Everything was working great until a week ago. It started to have issues with scanning a particular folder and never finishing. The solution to my problem was to increase the java heap size. I am currently backing up 244,407 files for a total of 1.2TB. As of a week ago my heap size was 1024MB. Apparently I reached the straw that broke the camel’s back by adding new photos to my archive. I have now increased to 1536MB and my backup is working again. So here is my concern: The folders I am currently backing up will continue to increase in size and I would like to add my time machine share to my backups which could be an additional 1.5TB.
Questions:
Is there any calculation that I can do to know what my heap size should be? What is the major determining factor to what this should be? File size? Number of files?
Did I solve my problem correctly or did I put a bandaid on another situation?
Are there negative impacts on system performance if I keep increasing the heap size?
Is there a maximum value for the heap size?
Thanks
Jamie
If you increase the heap size to approach or even exceed your NAS’s physical RAM size then the performance will suffer as you get lots of swapping to disk (virtual memory). I’m not sure of how to estimate the required size – it does seem that many small files requires more than many large files. The problem of course, is that Code 42 do not support running on headless NAS systems so we can’t get any proper help.
A good option is to break up your single backup into several backup sets. My experience is that every set can hold as much files as one backup. Meaning with 2 sets you can backup twice the amount of files before you run into the restarted scan problem ;-)
Thanks for the fantastic work! I just installed it and I think I have it running on my DS1513+:
Question: I would like to start/restart CrashPlan manually.
In http://forum.synology.com/wiki/index.php/CrashPlan_Headless_Client#Installation
it refers to:
/etc/init.d/crashplan start
However, I can’t seem to find this location. Would you happen to know in your package if this is located somewhere else
The Synology platform starts and stops packages in a different way. It’s best to use the Package Centre for manually stopping and starting packages.
Thank you, that’s very helpful to know! If I could follow up: if I use the Package Center to “stop” and start under the “Action” setting, will that do the same thing as restarting it manually?
Yep. See the section about cron in the notes. You would be able to script it yourself if needed, by using
/var/package/CrashPlan/scripts/start-stop-status start/var/package/CrashPlan/scripts/start-stop-status stop
Suddenly, I’m having problems connecting from my Mac’s CrashPlanPRO client to my DS1511+ NAS. This has worked in the past. Looking at the my.service.xml config file the Service Host is set to 127.0.0.1. It should be set to 0.0.0.0, so I reset it to that and restart the service, but it is then reset to 127.0.0.1 The start-stop-status script should be reseting this to 0.0.0.0, but does not seem to do it. Any ideas why?
samething here, only I just installed it on a 211j. cannot connect to the ds from my client, it times out.
netstat -atn gives me:
tcp 0 0 0.0.0.0:4242 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:4243 0.0.0.0:* LISTEN
is that correct?
Having the same problem after upgrading to 4.3 on my 1512+. I reinstalled Java 6 and now I can’t connect to the CrashPlan. The only errors or warnings I see in my service logs are:
[10.15.13 06:33:04.878 WARN main com.backup42.service.ComputerUniqueId ] Unable to store computer identity. null, com.code42.exception.DebugRuntimeException
com.code42.exception.DebugRuntimeException
at com.backup42.service.ComputerUniqueId.save(ComputerUniqueId.java:407)
at com.backup42.service.ComputerUniqueId.reset(ComputerUniqueId.java:317)
at com.backup42.service.CPService.deauthorize(CPService.java:1956)
at com.backup42.service.CPService.deauthorize(CPService.java:1908)
at com.backup42.service.CPService.loadModelCheckGuidAgainstModel(CPService.java:1512)
at com.backup42.service.CPService.loadModel(CPService.java:1464)
at com.backup42.service.CPService.start(CPService.java:394)
at com.backup42.service.CPService.main(CPService.java:1749)
[10.15.13 06:33:04.873 WARN main com.backup42.service.CPService ] FAILED to delete file=conf/service.login
[10.15.13 06:33:04.874 WARN main com.backup42.service.CPService ] FAILED to delete file=/volume1/@appstore/CrashPlan/conf/import_key
[10.15.13 06:33:04.874 WARN main com.backup42.service.CPService ] FAILED to delete file=conf/service.copier
[10.15.13 06:33:04.875 WARN main com.backup42.service.CPService ] FAILED to delete file=conf/service.pac
[10.15.13 06:33:14.146 WARN main com.backup42.service.ComputerUniqueId ] Unable to store computer identity. null, com.code42.exception.DebugRuntimeException
com.code42.exception.DebugRuntimeException
at com.backup42.service.ComputerUniqueId.save(ComputerUniqueId.java:407)
at com.backup42.service.ComputerUniqueId.setTransportKeyPair(ComputerUniqueId.java:286)
at com.backup42.service.CPService.initPeerControllers(CPService.java:563)
at com.backup42.service.CPService.start(CPService.java:443)
at com.backup42.service.CPService.main(CPService.java:1749)
my netstat looks the same as yours, and CrashPlan while looks like it’s running isn’t backing up or using any memory.
I’m pretty sure it’s supposed to be tcp 0 0 0.0.0.0:4243 0.0.0.0:* LISTEN
netstat -nat | grep “424” shows the following when I am not connected with my client:
tcp 0 0 0.0.0.0:4243 0.0.0.0:* LISTEN
and the following when I am connected:
tcp 0 0 0.0.0.0:4243 0.0.0.0:* LISTEN
tcp 0 0 192.168.0.118:4243 192.168.0.119:62359 ESTABLISHED
so there is a 4242 to many and a incorrect 4243… how to fix this for good?
ok, I tried to change the ipaddress from 127.0.0.1 to 0.0.0.0 for the service in my.service.xml, but when stopping at starting it again, it is changed back to 127.0.0.1. changes to ui.properties remain 0.0.0.0 but have no effect as netstat -atn agian shows;
tcp 0 0 127.0.0.1:4243 0.0.0.0:* LISTEN
anyone an Idea where the correct place is to set the 4243 IP?
I decided to uninstall and reinstall CrashPlan and adopt the old computer. That seemed to work for me. Clients can connect again and netstat looks fine:
tcp 0 0 0.0.0.0:4242 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:4243 0.0.0.0:* LISTEN
I’ve done that before, too, but would rather have it fixed, now that I know why the client won’t connect.
For me it was more than just the client connecting to the server. My server wasn’t backing up any more. I’d rather test uninstalling it and re-installing and having the backup start to work than just waiting for fixes for the client. If it were just the client I would probably agree with you, but my case it wasn’t backing up either. Now both are working.
I can’t argue your logic. It’s just frustrating to have to reinstall and adopt. I think I’ll follow your lead, though.
Hi guys,
Have some hints for Crashplan not backing up and the client ending when it cannot connect to the service running on the NAS. I am currently running a DS1512+.
1) BUY MORE MEMORY. This is a biggie. You need more memory for the unit it self, better caching and over all performance but really it is for Crasplan and the file /volume1/@appstore/CrashPlan\syno_packages.vars.
2) Putty is a good program to be able to go in and edit (vi sucks). Instead let me suggest WINSCP or another program that allows you to browse the file system.
So, I had the SAME problem most people are having with backups just stopping, the Crashplan client ending because it could not connect. So, like before I tried to use PUTTY and VI to edit the syno_packages.vars. I had no problem removing the hash (#) and saving but did not updated the number. The line looks like this:
#USR_MAX_HEAP=512M
After editing the hash was gone (#) but it looked like this:
USR_MAX_HEAP=512M
Not good, did not work. So,PUTTY again and VI, edit and :qs to save. But something strange happened. The file was read only. Not good. So I stopped Crashplan on the NAS, still no go. I rebooted and still the file was read only.
So, a while ago I had downloaded every single app from Portable Apps (don’t do it, it will take a full day and waste your life). Loading it up I found WinSCP. This is a GUI point and click Windows Explorer type program. You can browse the file system of the NAS (login in as you would with PUTTY using admin and the password you have setup to do the Web Admin).
There is an option to EDIT the file. SWEET I thought, so I went to edit it (I did not want to try and figure out how to make the file read/write using PUTTY and LINUX commands, I can get around but I am a Windows guy).
I made the change to the file to look like this ( /volume1/@appstore/CrashPlan\syno_packages.vars):
USR_MAX_HEAP=1024M
The BEST thing happened when I went to save, even though the file was read only, it asked me to enter in the ADMIN password, I did and it saved. I loaded the file back up to ensure the save took, and it did. Started the service on the NAS and loaded CrashPlan on my PC and it all works! Backing up like crazy again. I did this last night about 9 hours ago and it is still going.
Looking at the memory usage here is what I see:
Reserved: 66.7 MB
Used: 1.25 GB
Buffer: 175.9 MB
Cached: 1.38 GB
Free: 144.3 MB
Utilization: 42%
This is different than before I changed the USR_MAX_HEAP from 512 to 1024. I would say before there was:
Used: 850 MB
Free; 640
Buffer 200 MB
The big take away is try WinSCP as it does take away the complexity of using PUTTY and VI and makes it more Windows-ish for those that are looking for a more familiar setting to work in.
I hope this helps.
Shane, I’m also not possible to save the edited syno_packages.vars file with vi, even if I do a “save as” to another file. With strikes me is, if I go on folder up, I’m even not allowed to go back into the Crashplan folder (cd Crashplan does not work). I think it has something to do with ownership, since everything is owned by root, except the Crashplan folder.
How do you find the @appstore folder in WinSCP ? I’m logged on as admin, I checked the “Show hidden folders” preference and I still don’t see it. I do see all the @folders when I log in with Putty…
Thanks,Bert
Bit more info: I don’t seem to be able to log on as root remotely via sftp on WinSCP nor Filezilla. but I found a solution for editing via VI… It did not work when I was logged on as admin, it does work when I was logged on as root.
But I was not able to logon in the past with the root account via Putty (it gave “password incorrect” all the time), it does work now, after resetting the password of the admin account. I read that root always has the same pwd than admin…
Don’t know if these things make sense however… Set the max heap to 1024M and it is backup again, 512M wasn’t enough…
Patters, Please help me out as its driving me nuts… I have a 1512+, 3GB Ram, DSM 4.3. Im backing up 4.7tb of data and Crashplan keeps crashing out.
Code42 Support followed the normal route of its a headless install so not supported. They did provide a document about increasing the memory to Java, SRV_JAVA_OPTS): –Xmx3072m.
I update the run.conf file, but when I restart Crashplan it rewrites the old default values back.
What am I doing wrong?
Think I may have resolved the issue. I’ll come back an update if still having problems.
Thanks
Paul –
I have been having some difficulty suddenly keeping Crashplan up and running. So I was wondering what you determined was the cause of your problem – perhaps mine is similar.
I’ve been able to connect to Crashplan running headless on my Mac without any problems by editing the ui.properties file and uncommenting serviceHost, etc.
However, after I updated to Mavericks and updated java, I’ve been having problems. The CrashPlan icon seems to bounce around in the Doc, and nothing happens. Rarely it will connect, but mostly nothing happens. I’ve reinstalled CrashPlan and still having the same problem.
Anyone else notice this?
I have the same issue. I followed the instructions here:
https://support.code42.com/CrashPlan/Latest/Troubleshooting/Systems_Upgraded_to_Mac_OS_X_Mavericks_Require_Manual_Intervention
I did the optional step to install Java 7 and also had to re-install crashplan.
That worked for me too. I lost about an hour’s time because under the “Recommended Solution” there needs to be a step listed after #4 for “Reboot your Mac.” If you don’t reboot, you’ll try to start the newly installed CrashPlan, and still find the problem exists. A reboot cures that.
My DS412+ is currently going through a resync with Crashplan because I had to reinstall and then adopt my old backup archive. The issue I have is that the “analyzing” part is painfully slow running at only like 9 MBit/s at best! Usually Crashplan is able to max out my 10 MBit/s upload speed when sending data.
I have no idea why it is so slow. Last time it was analyzing pre uploaded data it went though it at speeds of about 200 MBit/s. Since this phase is not uploading any data it must be something with the Diskstation or the installation of Crashplan, but I don’t know why…
Any help is appreciated :-)
Hello!
After following all the steps, I have CrashPlan installed and running on my DS213j. I did some tests with a trial account and worked perfect for a few days by adding 1.6 Tb of data.
Now, switching to my real account and make the process of adopting computer is failing every few minutes, restart the service, etc..
The only mistake I see as that is:. /.. / CrashPlanEngine.pid: Permission denied
I put the user in the Administrators group CrashPlan, the same level as root but still the same.
Anyone else happens?
DSM shows a system warning “share [crashplan] was restored” after the package is unistalled.
I followed the instructions,
but I couldn’t connect my desktop client to the sinology crashplan client :(
so, I uninstalled the package.
and when rebooted the sinology,
I see an error: http://oi41.tinypic.com/nn8fti.jpg
So much simpler than the wiki instructions, thank you!
One question: Do you know why there are so many crash plan processes? When I run
ps | grep crash | wc -lI see 68 processes! I saw the same thing when I was running the dpkg-based install as documented in the wiki, and when I reported it to CrashPlan, they said it was because glibc and the Linux kernel are too old. CrashPlan requires “2.6.13 or newer 2.6 series kernel | Oracle (Sun) Java version 1.6, 1.7 | glibc 2.4+, cpio, Xorg, SWT1 GHZ+ x86-64 CPU | 1 GB+ memory | 250MB free drive space”. But maybe you know of a way to get it to behave properly with what DSM 4.3 includes? Or should I just not worry about it?
installed! :)
thanks for the easy installation.
when I check the package logs, I see “no data”.
is that normal?
Thanks
new version of this software, and new java version. still the same problem, listen on 127.0.0.1 port 4243, instead of 0.0.0.0 port 4243.
Looking at the startup script, I see a line for changing the value in the my.service.xml. That’s nice, but it does not work.
Looking at the logfile below,
this line
[11.12.13 21:28:09.056 INFO main root ] CpsFoldersMigrate is not necessary. /volume1/@appstore/CrashPlan/conf/my.service.xml file does not exists.
says that the config file does not exists, so somewhere along the startup process, it is deleted and replace with something else. I would like to know where the default values are set, so I can change the 127.0.0.1 there…..
below the logfile info.
[11.12.13 21:27:56.898 INFO main root ] Locale changed to English
[11.12.13 21:27:56.908 INFO main root ] *************************************************************
[11.12.13 21:27:56.908 INFO main root ] *************************************************************
[11.12.13 21:27:56.909 INFO main root ] STARTED CrashPlanService
[11.12.13 21:27:56.920 INFO main root ] CPVERSION = 3.5.3 – 1364274000353 (2013-03-26T05:00:00:353+0000)
[11.12.13 21:27:56.924 INFO main root ] LOCALE = English
[11.12.13 21:27:56.930 INFO main root ] ARGS = [ ]
[11.12.13 21:27:56.931 INFO main root ] *************************************************************
[11.12.13 21:27:58.027 INFO main root ] Adding shutdown hook.
[11.12.13 21:27:58.126 INFO main root ] BEGIN Loading Configuration
[11.12.13 21:27:59.325 INFO main root ] BEGIN Copy Custom
[11.12.13 21:27:59.327 INFO main root ] Directories: [.Custom, custom, /volume1/@appstore/CrashPlan/conf/.Custom, /volume1/@appstore/CrashPlan/conf/custom]
[11.12.13 21:27:59.328 INFO main root ] NOT waiting for custom skin to appear
[11.12.13 21:27:59.329 INFO main root ] NO customizations found.
[11.12.13 21:27:59.329 INFO main root ] END Copy Custom
[11.12.13 21:27:59.384 INFO main root ] Loading from default: /volume1/@appstore/CrashPlan/conf/default.service.xml
[11.12.13 21:28:00.721 INFO main root ] Loading from my xml file=conf/my.service.xml
[11.12.13 21:28:01.300 INFO main root ] Loading ServiceConfig, newInstall=false, version=4, configDateMs=null, installVersion=1364274000353
[11.12.13 21:28:01.302 INFO main root ] OS = Linux
[11.12.13 21:28:02.803 INFO main root ] AuthorityLocation@10164575[ location=central.crashplan.com:443, hideAddress=false ]
[11.12.13 21:28:02.813 INFO main root ] Config already has a value for Java memory heap max; mx=80m
[11.12.13 21:28:02.814 INFO main root ] END Loading Configuration
jtux Loaded.
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
FAILED to delete file=conf/service.pac
CACHE DELETED cacheDir=/volume1/@appstore/CrashPlan/cache
[11.12.13 21:28:09.050 INFO main root ] BEGIN Loading Configuration
[11.12.13 21:28:09.052 INFO main root ] BEGIN Copy Custom
[11.12.13 21:28:09.053 INFO main root ] Directories: [.Custom, custom, /volume1/@appstore/CrashPlan/conf/.Custom, /volume1/@appstore/CrashPlan/conf/custom]
[11.12.13 21:28:09.053 INFO main root ] NOT waiting for custom skin to appear
[11.12.13 21:28:09.054 INFO main root ] NO customizations found.
[11.12.13 21:28:09.055 INFO main root ] END Copy Custom
[11.12.13 21:28:09.056 INFO main root ] CpsFoldersMigrate is not necessary. /volume1/@appstore/CrashPlan/conf/my.service.xml file does not exists.
[11.12.13 21:28:09.057 INFO main root ] Loading from default: /volume1/@appstore/CrashPlan/conf/default.service.xml
Is there anyway to run crashplan as another user? I rsync a couple Linux boxes to my diskstation and the crashplan user does not have the right perms to go into the home directories that are copied over.
Any help would be greatly appreciated.
I’m a crashplan subscriber. I’m confused do we install the crashplan or crashplan PROe client?
Use CrashPlan. CrashPlan PRO is for when you are a company that runs a CrashPlan PRO server.