Note: This article is part of a series. See the Index for more information.
Self-promotion: I’ve recorded this series as a screencast for Pluralsight:
(http://www.pluralsight.com/courses/raspberry-pi-home-server)
If you have a Pluralsight subscription, please consider watching it. Thanks!
Updates: It is no longer necessary to replace the Java Runtime Engine since the newer installer doesn’t seem to include it anymore, so skip removing /usr/local/crashplan/jre, which doesn’t even exist, and don’t create the symbolic link.
There is a newer version of the standard widget toolkit (SWT) in the current installer, so after installing it, take a look in your /usr/lib/java folder to see what version you have. My most recent version was swt-gtk-3.8.2.jar, rather than the …3.8.0 from the original installation. Adjust the copy command accordingly.
Initially my service wouldn’t start, but after a reboot it worked just fine. If you run into trouble, reboot and try again.
IMPORTANT UPDATE 2017-10-07:
I’m leaving this here for posterity, but the simple fact is that CrashPlan is no longer a viable option on the Pi. It is no longer written in pure Java, some key libraries are only available for Linux running on x86 architectures, and Code42 has eliminated the free home-user product from their offerings meaning that you’ll have to pay for a subscription in order to keep using CrashPlan at all. This no longer fits with the “free if you do it yourself” theme of this blog series, so I am an throwing in the towel.
See “CrashPlan is dead”
IMPORTANT UPDATE 2016/10/02:
I’ve gotten a number of comments about CrashPlan not working lately. It looks like some recent update has possibly broken CrashPlan on the Raspberry Pi to an extent we’ve not seen before.
Code42 wrote a great backup program, but the Pi isn’t an officially supported platform, and never has been, so you can understand why they don’t really have any incentive to come rushing to our rescue. They never meant CrashPlan to run on ARM devices, and that’s what the Raspberry Pi is.
Some users have reported being able to get the engine running, but not the UI, and others have said that even the engine isn’t working anymore. My own CrashPi stopped working as well, and I haven’t had a chance to see if I can find a way around it. Until further notice, I can’t really recommend running CrashPlan on the Raspberry Pi. I’m open to suggestions if anyone knows a way to get it running and keep it that way, but I haven’t found one myself yet. I am looking into it, though.
Update 2016/05/17
If you tried recently to install CrashPlan and it failed, or wouldn’t stay running for very long, it looks like the most recent installer has fixed whatever was broken. The current download from Code42’s site should be version 4.7 or newer, and readers are reporting that all is well again.
If, like me, a previous auto-update broke your existing installation, then I suggest uninstalling CrashPlan like this (From memory, forgive me if I get something wrong)
cd /mnt/data/public/downloads/crashplan-install sudo ./uninstall -i /usr/local/crashplan
Then download and install the latest version from Code42. You’ll need to repeat all of the steps in this article, but as long as you point the backups to the same directory you were using before, CrashPlan should pick them up and continue using them, so you don’t have to start completely over. You will need to reinstall and re-patch the UI, and then sign in to your account again, just like the first time around.
Updated 2015/02/07:
Recently, Code42 (CrashPlan’s developer) updated their installation files, and the instructions in this article stopped working. Thanks to the work of several readers (see the comments), I’ve been able to revisit this article and update the instructions so that they work once again.
See the end of this article for additional troubleshooting information if you find that your installation mysteriously stops working one day.
Overview
One of the main jobs of a proper “home server” is to back up the other computers on the network. You could accomplish this through the file shares I covered earlier in the series, but I’d like to try something a little more ambitious.
There’s a great product out there called “CrashPlan” (www.code42.com/crashplan). The company has subscription offerings that will store your backups in their “cloud”, similar to other products like Carbonite (www.carbonite.com), but if you can supply your own storage, CrashPlan is free.
The free version of CrashPlan can back up to a local drive on the same computer, or to another computer that is also running CrashPlan. Your Raspberry Pi Home Server can be that “other computer”, and handle the backups for all of the computers in your house.
Note: It is possible to get CrashPlan to backup to a share on your local network, too, but it involves jumping through some symbolically-linked hoops, and won’t be covered here.
Acknowledgements
I didn’t figure all this stuff out on my own, not by a long shot. I am standing on the shoulders of other geeks here. In 2012, Jon Rogers wrote a blog post about getting CrashPlan running on the Raspberry Pi. That article is largely the basis for this one.
In February of 2013, Bion Ren posted an updated version of Jon’s instructions, replacing OpenJDK with Oracle’s Java 8 preview. He also called attention to a post by Torbjörn that solves a major configuration issue, and a comment by Brad Peterson that addresses a rather serious stability issue with regards to swap file use.
I am posting this because I wanted to gather together a complete, updated set of end-to-end instructions for adding CrashPlan to the Raspberry Pi Home Server I’ve been describing in this series. As I have pointed out before, I am by no means a Linux expert. I could not have done this without the work of those that went before me.
Before you start
CrashPlan was not written with tiny computers like the Raspberry Pi in mind. It expects to be running on a computer with more resources in general, and more memory in particular. When it doesn’t have enough memory, it will start paging to the swap file. Whether or not this will wear out your SD card is a rather contentious subject, and I’m not going to pretend that I know the answer to that one. One thing is for sure, though, SD card-based swap files are slow.
As a result, I cannot recommend running CrashPlan on a Raspberry Pi unless you have moved your swap file (and I recommend your root filesystem as well) onto a proper hard drive as covered in my “Adding a hard drive” post. If you skipped that article, this isn’t going to work for you. The SD card just doesn’t have enough space to hold backups. In order to serve as a useful CrashPlan backup destination, you’re going to have to have a big hard drive anyway, so you may as well take full advantage of it.
In addition, CrashPlan does some pretty heavy lifting in the background, compressing and pruning backups, and doing general housekeeping. This can use a lot of CPU, and make the rest of your server’s functions slow to respond. As I’m writing this, my own CrashPlan instance is using up about 60% of my CPU time compressing backups from my primary computer. CrashPlan is usually pretty good at getting out of the way when other programs need to think, at least on the desktop.
YMMV
Java
CrashPlan runs on Java, which means it can run on anything with a Java runtime. Current Raspbian images (2015-01-31 at the time of this update) already include the Java Runtime, version 8. You can check this by typing the following at the command line:
java –version
If it says “1.8.0” or above, you’re all set to go. If not, you may need to install the Java Runtime Engine (JRE) yourself. Unfortunately, I can’t find a simple JRE installer for the raspberry pi at this time, so you’ll just have to install the whole Java Development Kit (JDK). Only do this if you don’t already have JRE8, as checked in the last step.
sudo apt-get install oracle-java8-jdk
There is an additional piece you’ll need in order for CrashPlan to work. According to a user called Torbjörn on the CrashPlan forums, you’ll also need the Java Native Access (JNA) library. Install them both at once like this:
sudo apt-get install libjna-java
When the Java installation completes, you are ready to install CrashPlan itself.
Get the CrashPlan installer
Since there are new versions being released all the time, I can’t give you a simple url to “wget”. Go to http://www.code42.com/crashplan/thankyou/?os=linux, from a browser on the Pi itself, and the download should start automatically. I used the new “Web” browser that’s part of the Raspbian image, so the file ended up in /home/pi/Downloads. Depending on your browser, your downloads may go somewhere else. If you can’t figure out where they are going, just download the package from your primary computer, and copy it over on a flash drive.
When the download is complete, find the .tgz file and extract it. Since I was already in the desktop environment to run the browser, I took advantage of the modern amenities, right-clicked the file and picked “Extract here” from the context menu. Sometimes it’s nice to live in the future, if only for a moment.
If you want to do it from the command line, go to the folder where your .tgz file is:
cd /mnt/data/Downloads
…and type the following:
tar zxvf FILENAME.tgz
Install CrashPlan
Navigate to the folder where you just extracted the installer (Note: your folder may be different):
cd ~/Downloads/CrashPlan-install
Execute the installer from the command line.
sudo ./install.sh
The install script will prompt you for anything it needs, including accepting a really long EULA that you probably won’t really read (q exits the reader). You can accept most of the defaults and let the installer create any missing folders, but one directory you should probably change is the backup location.
Unless you are backing up something very very small, like another Raspberry Pi, the root partition is not going to be big enough to hold the files. Change the backup location to somewhere on the data partition. I set mine to “/mnt/data/CrashPlan”, and let the installer create the folder. You’ll get a summary and a confirmation prompt like this:
Double check all of your values, and then let the installer go. It’s a surprisingly fast installation. If there were no problems, you should see a confirmation like this:
At this point, you have CrashPlan installed, but it’s not very happy. Although the installer says the engine is installed and running, it’s actually not. You can check on the status of the CrashPlan service like this:
service crashplan status
The answer will probably say “CrashPlan Engine is stopped.”, and even if you try to start is manually, checking its status will still say “stopped”.
The trouble is that the installer downloaded it’s own private copy of the Java Runtime Engine, version 7 (JRE7). Normally, this would just be an irritating waste of storage space, having multiple copies of the JRE around, but the one CrashPlan installed isn’t even the right architecture. The CrashPlan installer has installed a JRE that assumes it’s on a desktop processor, specifically something i586-ish (Pentium, Core, etc.)
Don’t worry about it if you don’t know what that means. All it means to us is that we’re going to have to trick CrashPlan into running on the JRE that’s already on the Pi, instead of the one it installed itself. Thanks to Rainer Boehme and Matt for showing me this in the comments.
The first order of business is to blow away the useless x86 version of JRE7.
sudo rm -r /usr/local/crashplan/jre
Next, we’ll create a “symbolic link”, which is a kind of shortcut on your hard drive. Symbolic links make things in one place appear to be somewhere else, or even in multiple places. You can use them to keep one physical copy of a file, but have it appear in many different places. Here, we’re going to use one to make the raspberry pi-friendly JRE8 appear where CrashPlan put its raspberry-unfriendly JRE7.
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
Patch CrashPlan to work on the Pi
CrashPlan is now installed, but it’s not very happy. If you were to look in the /usr/local/crashplan/log/engine_error.log file right now, you’d see a complaint about the /usr/local/crashplan/libjtux.so file being the wrong version. Luckily for us, Jon Rogers already fixed that problem.
Return to the terminal, and go to the /usr/local/crashplan folder where you will find the file in question.
Remove the bad libjtux.so file, and replace it with the one that Jon Rogers patched.
cd /usr/local/crashplan sudo rm libjtux.so sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libjtux.so
There’s also something wrong with the libmd5.s0 file, so replace that one the same way.
sudo rm libmd5.so sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libmd5.so -O ./libmd5.so
These two files should allow the CrashPlan engine to start up.
Next, edit the CrashPlanEngine file.
sudo nano /usr/local/crashplan/bin/CrashPlanEngine
Find (ctrl-w) the line that starts with “FULL_CP=”, and add “/usr/share/java/jna.jar:” (don’t forget the colon) to the beginning of the string value so that the result looks like this:
Exit nano, saving the file (ctrl-x,y,enter)
Start CrashPlan
To check whether everything is working, try launching CrashPlan manually.
sudo service crashplan start sudo service crashplan status
If everything went well, you should get a message indicating that the CrashPlan service is running.
Configure CrashPlan to auto-start
Having a backup system like CrashPlan won’t do you much good if it doesn’t start back up again after your power goes out. Type the following command to automatically configure CrashPlan to auto-start after a reboot.
sudo update-rc.d crashplan defaults
To make sure that it worked, reboot the Raspberry Pi, log back in, and check the status of the service. It should be running.
sudo reboot … sudo service crashplan status
Patch the CrashPlan UI
At this point, you have a working CrashPlan server, but no way to communicate with it. You need to get a GUI talking to the CrashPlan engine so that you can configure backups, change preferences, and generally fiddle with the knobs.
LiquidState has a very detailed walkthrough of configuring CrashPlan to answer to a UI running on a different computer. If that’s how you want to do things, then go ahead, but it’s not that much harder to get the UI running on the Pi’s own X desktop.
If you were to try the CrashPlan icon that the installer has placed on your X desktop right now, it wouldn’t work because the version of the Standard Widget Toolkit (SWT) library that CrashPlan installed won’t work on the Raspberry Pi. You can double-click that icon all day and it will never get you anywhere until we fix this problem.
Install a compatible version of the SWT library like this:
sudo apt-get install libswt-gtk-4-java libswt-cairo-gtk-4-jni
Next, replace the SWT library that CrashPlan installed with the compatible one. You’ll notice that we’re totally lying about the filename. CrashPlan isn’t meant to run on ARM processors, and in 4.8 they started choosing between x86 and x64 versions of the libraries dynamically at runtime. We’re renaming the ARM-compatible version of the toolkit so that it appears to be the x86 file that CrashPlan will end up trying to run on the Pi.
sudo cp /usr/lib/java/swt-gtk-4.3.2.jar /usr/local/crashplan/lib/org.eclipse.swt.gtk.linux.x86.jar
Note: Thanks to Jeremy Nauta for identifying newer versions of these libraries being used by CrashPlan 4.8
The exact version of this file is subject to change, so if the command complains, use tab-completion to help find the correct filename. Type up to “/usr/lib/java/swt” and then hit the Tab key to fill in the rest. This file has changed more than once since this article was first published.
You can now run the CrashPlan UI directly from the shortcut the installer put on your X desktop. The first run can be pretty slow, so give it some time.
You’ll either need to connect to an existing CrashPlan account, or create a new one. It’s been so long since I signed up, that I honestly couldn’t walk you through the steps anymore, but all you’re going to need is what’s included in the free version.
Back up your stuff
Now that you have a CrashPlan server, it’s time to start backing things up. Install the CrashPlan software on the computer you want to back up, and open the UI. Sign in using the same account information you used above.
From here on, it’s just business as usual. Choose what you want to back up, and select “another computer” for the destination. If you signed in with the same account on the client and server, they should see each other in the list, and you can pick the Raspberry Pi as your backup location.
If your computers have trouble seeing each other, I’d suggest looking in the support section of the CrashPlan site. CrashPlan does a pretty good job of opening its own firewall holes via UPnP, but perhaps your router doesn’t support that, or maybe you’ve turned it off on purpose. Such networking issues are beyond the scope of this article. Your mileage may vary. Google is your friend.
Warning: The first time you back up another computer it will take a very long time, and it’s going to peg the Raspberry Pi’s CPU, just like when MiniDLNA was indexing your media. Don’t worry, you’re not going to hurt the Pi. Mine was at 100% CPU usage for more than a day, and the CPU temperature never rose above 64°C. As long as the temperature stays below 80°C, you have nothing to worry about. Subsequent backups will also run up the CPU, but not for nearly as long.
The CrashPi: Secure, off-site backups
Now we come to the real payoff, and the part that’s going to keep your stuff safe in the event of a fire or flood. When you use CrashPlan to back up to another computer, that other computer does not have to be on the same local network as the computer it’s backing up. It can be anywhere on the internet. It could be on the other side of town, or in a different state.
A Raspberry Pi is cheap enough that you could just Velcro one to the side of a big USB drive and leave the whole thing at a buddy’s house. If your buddy does the same, and parks a CrashPi (as I am now calling it) at your house, then you’ll both be protected in the event of a disaster… unless, of course, you live in the same apartment building. You should choose a location for your off-site backups that is far enough away that both sites are unlikely to fall victim to the same disaster.
To build a CrashPi, all you need to do is build another Raspberry Pi Home Server, leaving out all the parts that CrashPlan doesn’t need, which is actually most of them. Follow this subset of the Raspberry Pi Home Server blog series, and you’ll have made a CrashPi.
- Installing the OS:
Start with a small, cheap SD card. You only need 4GB. - Configuring the OS:
If you want SSH access to maintain the CrashPi remotely, your buddy will have to punch a hole in the firewall, or put the CrashPi in his/her DMZ. - Web Administration: (Optional)
This will let you check in on your CrashPi to perform maintenance, install updates, etc.
Your buddy will have to punch a hole in the firewall, or put the CrashPi in his/her DMZ. - This post:
Obviously
You may have noticed something CrashPlan calls a “backup code”. This is a unique code that identifies a specific CrashPlan installation. You can give this code to a friend to let them back things up to your server, even though you have different accounts. For instance, when the kids head off to college, you might want to let them use your Raspberry Pi Home Server as a backup destination. All they’ll need is that particular computer’s “backup code”, which you can get from “Friends” tab in the CrashPlan UI.
What’s next?
As far as core home server functionality goes, the Raspberry Pi is already doing a lot. It’s sharing files and media on the local network, downloading things for you, and backing up your computers, even over the internet when you’re away from home.
What more could you possibly want?
How about Virtual Private Networking (VPN) access to your home network when you’re away? Sound good? In the next post, we’ll set up OpenVPN so that you can have all the safety and security of your home network, even from the sketchiest of airport coffee shop networks.
Troubleshooting
I have a sneaking suspicion that this article is going to see more updates than most, so I’m starting a section here at the bottom to catch any updates.
CrashPlan UI has stopped working!
If you have already installed CrashPlan in the past, and find that the UI doesn’t work anymore after performing an apt-get update/upgrade, you’ll need to repeat the final step of the article once again to put things back to normal. Simply run the following commands to replace the SWT library that CrashPlan installs with one that is compatible with the Pi, and you should be up and running again.
sudo cp /usr/lib/java/swt-gtk-3.8.0.jar /usr/local/crashplan/lib/swt.jar
You may need to do this each time you do an apt-get update/upgrade, unfortunately. I haven’t quite figured out what causes the problem just yet, but since CrashPlan wasn’t installed through apt-get, that shouldn’t be it. Just remember this in case your UI stops working one day.
MelGrubb.ToBlog() 
Pingback: Raspberry Pi Home Server: Index | MelGrubb.ToBlog()
Pingback: Raspberry Pi Home Server: Part 9, Transmission | MelGrubb.ToBlog()
Hi Mel Grubb,
Thanks for the instructions. I’ve now got it working on a BananaPi! Details are here:
http://forum.lemaker.org/forum.php?mod=viewthread&tid=9557&page=1&extra=#pid46577
Cheers,
Chris.
Works very well! The biggest risk to private computers is actually not the fire, flooding or nuclear blast, but that it gets stolen when traveling or by burglary. So have your backup geographically separated.
Mel,
Have you tried using CrashPlan to backup the contents of the drive on the Pi to another location? I’m looking to replace my old desktop, which does DLNA and CrashPlan with a Pi. We currently backup all of the things we stream with DLNA to CrashPlan. How would that work if the Pi is hosting the files? I’ve also considered running DLNA on one Pi and CrashPlan on a separate one. Thoughts?
I have not, but there’s no reason why it shouldn’t work. CrashPlan instances are both a client and a server, so they can be backing up other computers’ stuff while they back themselves up to other computers. I did have some trouble with my own setup, which I initially thought was a problem with me asking too much of the Pi. As it turns out, the drives I used in my RAID are not server type drives, and they have a tendency to fall asleep and park the heads when they sit for a while. This makes the Pi sad, and it would lock up on me at least once every few days. I’m back to booting from the SD card again, since it’s cheaper than replacing my drives, and all my problems have gone away. Anyway, the Pi has no trouble keeping up, and I believe CrashPlan is pretty good at throttling back when other things are going on, like media streaming. You should be fine running everything on one Pi. Of course… if you’re looking for an excuse to buy more Pis, then by all means, go right ahead.
What a fantastic tutorial – clear and thorough explanation which “just worked”. I have set mine up with CrashPlanDesktop running with ssh X11 forwarding and the same instructions work no problem. I plan on getting the Pi to back up my NAS (~2TB) via an NFS mount I’ll be experimenting to see if I require local storage (SSD if i have to) as well for swapping as you also mentioned in your post, but this post helped me get to this point a lot sooner than I would have otherwise – thank you!
Great series of tutorials…sort of like “Kahn Academy” for linux/pi! I am having difficulty getting the Crashplan engine to start. It looks as though it starts ok, but when the status is checked is says the engine is stopped. Here are the errors I am getting from /usr/local/crashplan/log/engine_error.log:
/usr/local/crashplan/jre/bin/java: 1: /usr/local/crashplan/jre/bin/java: ^?ELF^A^A^A^B^C^A^P�^D^H4�: not found
/usr/local/crashplan/jre/bin/java: 2: /usr/local/crashplan/jre/bin/java: Syntax error: “(” unexpected
Any thoughts?
Craig
I’m not sure whether the error message made it into the comments intact, so this is just a guess, but there were several steps in the article just to get Java itself up and running. Make sure you look back through them, and make sure none of the steps were missed. Also, there’s some hand-editing of the CrashPlan file itself (I’m not at home with access to the real thing right now, so sorry about the lack of specifics)
Thanks for the response. The errors above are intact, but in four lines instead of two.. I double checked all the steps. I tried uninstalling and reinstalling Crashplan but got the same result/errors. As Crashplan is installing, it mentions something about Java:
“Download of the JVM found. We’ll try to use it, but if it’s only a partial
copy of the file then this will fail. If that happens please remove the file
and try again.
JRE Archive: jre-7u45-linux-i586.tgz
Java Installed.”
Then Crashplan finishes installing seemingly correctly. Obviously I am missing something…
The current CP installer seems to download a i586 version of Java which obviously doesn’t run on ARM.
I replaced the version of Java used by CP with the following commands:
sudo rm -r /usr/local/crashplan/jre
sudo ln -s /usr/lib/jvm/java-8-oracle /usr/local/crashplan/jre
This links CP to the Java version installed in the step “Get Java”.
I currently have the CP service running and the GUI also, connected to my CP account.
Hi,
I’m having the same problem, your solution makes sense, but isn’t working in this case. I’ve checked the folder the symlink points to and found it didn’t exist, so I’ve also tested it with
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm-vfp-hlft /usr/local/crashplan/jre
But this hasn’t solved the issue. Any suggestions gratefully received!
I’m not sure why CP is not working when linked o the JDK instead of the JRE, as the article suggests that is was working with the JDK (which should be just a superset of the JRE).
However, I have to admit I installed Java 8 with the instructions found here:
http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
I was under the impression that this is equal to the method described here, but it is not, as it additionally installs the Java 8 JRE.
So it might be worth a try to install JRE and JDK with these instructions and link to the JRE as described in my previous post.
I haven’t yet gotten to walking through the whole setup again, but I hope to this weekend. I will be trying a number of different approaches, including JRE8, and I’ll see what works in the simplest way. Thank you for all of your input. It will help provide a direction for me to start in.
Rainer, that worked for me, thanks for the quick fix!
Rainer, that also partially worked for me, I have CP running but it keeps getting stuck on “connecting to backup destination” although the RPI dot is green. What gives?
due to I installed Crashplan to the /mnt/data dir I had to perform sudo rm -r /mnt/data/CrashPlan/crashplan/jre. Maybe very obvious but if you follow it step by step then you will get to this problem.
I’m not understanding what you’re saying. Are you saying that you’ve followed the instructions, and ended up with a problem? Because the instructions do not say to install Crashplan itself to /mnt/data. I install all programs to the main filesystem, but configure them to store their data on the hard drive. If you installed all of Crashplan to /mnt/data, then you’d also need to adjust everything else that refers to the normal Crashplan install folder in order to compensate, including the symbolic link to jre8.
Thanks for this series, it has been a big help.
I ran into an issue on this step. It seems like the version of CrashPlan I downloaded, 3.7.0_linux, automatically downloads its own JRE. I think that is what Craig was seeing above as well. The install.sh script doesn’t seem to look at the OKJAVA variable at all any more.
Here’s what I did to get it working:
– Install Java 7 instead of 8, since that seems like what CrashPlan expects:
sudo apt-get install oracle-java7-jdk
– Don’t need to modify the install.sh to update OKJAVA, since that isn’t used.
– Install CrashPlan the same way you described.
– Update the libjtux.so and libd5.so the same way too
– Here’s the trick: Update the version of Java CrashPlan uses to the one I downloaded. There are probably a couple ways to do this. What I did was change the jre directory CrashPlan uses by creating a symbolic link to to the version of Java I downloaded (under /usr/lib/jvm/jdk-7-oracle-armhf):
sudo mv /usr/local/crashplan/jre /usr/local/crashplan/jre-installed
sudo ln -s /usr/lib/jvm/jdk-7-oracle-armhf/jre /usr/local/crashplan/jre
– Start up CrashPlan (sudo service crashplan start) and it seems to be running with no errors!
I hope this helps someone. Or at least points you in the right direction!
I originally did it with JRE7 as well, but from the research I did when writing the series, a lot of people saw higher resource usage with JRE7. I mentioned this in the “Get Java” section of the original post. This is the reason for the hacks necessary to make CrashPlan work with JRE8. Your mileage may vary, but this setup has worked well for me. If the current CrashPlan download no longer works, then I may have to revise the post. I will have to find time to walk through the installation again first, though. Thank you for the information.
I’ll try again with java 8. The big problem was that the latest CrashPlan installer always downloaded its own JRE which didn’t work with the pi architecture (I think it defaults to i586). So I needed to tell the installation to use a version I downloaded.
Hello Mat & Mel,
I left an earlier message as the above came through and in part the problem is resolved through Mats adjustments. CP now fires up and through the Remote Desktop can open the CP interface and navigate to the PI folders. My initial reason for using the pI was to use it as an interface / manager of backing up from my Syno NAS shares and couldn’t see the mapped drive on the CP file manager.
However I managed to mount the external NAS folder (https://rasspberrypi.wordpress.com/2012/09/04/mounting-and-automounting-windows-shares-on-raspberry-pi/) as a test and CP saw this link through the file manager.
Now waiting for PI to upload the data (approx. 500mb) at the moment it is slow and although connected to the CP server, ip addresses are seen for the PI:4242 and the ISP:4242 and NAT traversal PMP is ok, there doesn’t seem to be any data or file movement.
If you have any ideas as to why this is appreciated.
Thanks again for getting me to this point. Just a couple of more steps then I can ditch the CP for the syno package and use the PI to manage the uploads from my network shares.
Regards
Dieter Soerensen
My initial backup took forever as well. One way to check if anything is happening is the “top” command. This will show you a list of the top programs by cpu usage. You should be able to see whether CrashPlan is actually doing anything or not from there. I’m actually a Linux novice as well. The Pi is actually the first Linux computer I’ve ever had, although most of my college work was on UNIX machines, so it’s not like it was totally unfamiliar.
Hi Mel & Craig,
Firstly thankyou Mel for the great work here. As a noobie to Linux the instructions are crystal clear and the previous setups work fine. 🙂 It is a pleasure and fills me with hope to see this type of work & alternative in the WWW.
As a CP user with my Syno, after the recent upgrade to 3.7 from CP it has added to the long list of problems in setting the Syno/CP up – about 6mths and it is now resulting in me using my MBA at night to part upload the NAS content to CP.
The raspberry PI solution seemed ideal – Linux client, no Syno conflicts and on 24/7. But alas i have experienced the same problem as Craig has and the CP will not start.
Looking at the /usr/local/crashplan/logs I cannot see any error messages other than the 2x lines from Craigs post. I have uninstalled (dpkg) the oracle pkg 7 & 8 and manually removed (rm) the crashplan installation but after this 2nd install and following your instructions – it simply doesn’t work and comes up with message “crashplan stopped” after the service status command.
If you want to see I can upload the screen shots of the error files. Any help would be gratefully received. I am beginning to think i need to by a dedicated computer just to run the CP package in the background – seems a lot of effort and cost plus i really don’t want to use windows. The PI seemed perfect for this.
Thanks & regards
Dieter Soerensen
Hi Mel. I used your instructions to set up Crashplan on RPI two months ago. Unfortunately, the instructions do not work anymore, obviously something has changed in CP executables downloaded from their site. If you set up CP from scratch, you and up with the error Craig and Matt have described. The only solution is to do what Matt suggested and downgrade to JRE 7. With his suggestion, CP engine runs in the background.
However, there is new problem: CP UI does not work. When I start it, I see the following in the ui_output.log and have no idea what to do now. Any advice is appreciated.
[01.19.15 21:40:11.501 INFO main root ] *************************************************************
[01.19.15 21:40:11.520 INFO main root ] *************************************************************
[01.19.15 21:40:11.522 INFO main root ] STARTED CrashPlanDesktop
[01.19.15 21:40:11.596 INFO main root ] CPVERSION = 3.7.0 – 1388728800370 (2014-01-03T06:00:00:370+0000)
[01.19.15 21:40:11.620 INFO main root ] ARGS = [ ]
[01.19.15 21:40:11.734 INFO main root ] LOCALE = English (United States)
[01.19.15 21:40:11.736 INFO main root ] JVM = Java(TM) SE Runtime Environment (1.7.0_40-b43, 32-bit)
[01.19.15 21:40:11.737 INFO main root ] OS = Linux (3.12.35+, arm)
[01.19.15 21:40:11.738 INFO main root ] User = root, /root
[01.19.15 21:40:11.739 INFO main root ] swt.library.path = /tmp/.cpswt
[01.19.15 21:40:11.741 INFO main root ] *************************************************************
[01.19.15 21:40:11.751 INFO main root ] SWT library deleted: /tmp/.cpswt/libswt-gtk-4427.so
[01.19.15 21:40:11.792 INFO main root ] Loading lib/swt.jar, exists=true
[01.19.15 21:40:11.851 INFO main root ] [file:/usr/local/crashplan/lib/com.backup42.desktop.jar, file:/usr/local/crashplan/lang/, file:/usr/local/crashplan/skin/, file:/usr/local/crashplan/lib/swt.jar]
[01.19.15 21:40:14.119 ERROR main com.backup42.desktop.CPDesktop ] Failed to launch CPDesktop; java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
Can’t load library: /tmp/.cpswt/libswt-gtk-4427.so
Can’t load library: /tmp/.cpswt/libswt-gtk.so
no swt-gtk-4427 in java.library.path
no swt-gtk in java.library.path
/tmp/.cpswt/libswt-gtk-4427.so: /tmp/.cpswt/libswt-gtk-4427.so: cannot open shared object file: No such file or directory (Possible cause: can’t load IA 32-bit .so on a ARM-bit platform)
, java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
Can’t load library: /tmp/.cpswt/libswt-gtk-4427.so
Can’t load library: /tmp/.cpswt/libswt-gtk.so
no swt-gtk-4427 in java.library.path
no swt-gtk in java.library.path
/tmp/.cpswt/libswt-gtk-4427.so: /tmp/.cpswt/libswt-gtk-4427.so: cannot open shared object file: No such file or directory (Possible cause: can’t load IA 32-bit .so on a ARM-bit platform)
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
Can’t load library: /tmp/.cpswt/libswt-gtk-4427.so
Can’t load library: /tmp/.cpswt/libswt-gtk.so
no swt-gtk-4427 in java.library.path
no swt-gtk in java.library.path
/tmp/.cpswt/libswt-gtk-4427.so: /tmp/.cpswt/libswt-gtk-4427.so: cannot open shared object file: No such file or directory (Possible cause: can’t load IA 32-bit .so on a ARM-bit platform)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.C.(Unknown Source)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
at org.eclipse.swt.widgets.Display.(Unknown Source)
at com.backup42.desktop.CPDesktop.(CPDesktop.java:265)
at com.backup42.desktop.CPDesktop.main(CPDesktop.java:199)
[01.19.15 21:40:14.127 ERROR main root ] Failed to launch CPDesktop; java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
Can’t load library: /tmp/.cpswt/libswt-gtk-4427.so
Can’t load library: /tmp/.cpswt/libswt-gtk.so
no swt-gtk-4427 in java.library.path
no swt-gtk in java.library.path
/tmp/.cpswt/libswt-gtk-4427.so: /tmp/.cpswt/libswt-gtk-4427.so: cannot open shared object file: No such file or directory (Possible cause: can’t load IA 32-bit .so on a ARM-bit platform)
This is unfortunate, but I won’t have a chance to look into it until at least the weekend. A temporary solution would be to use the front-end from a different computer. I found several CrashPlan installation guides that did this. Do a qick google search, and you should be able to find it. You have to hack up the configuration on a normal desktop computer (Windows, Mac, etc.) and change the IP address of where the CP server lives to point to the Pi. I didn’t like this solution when I installed everything, so I looked into what it took to make the UI work on the Pi. That obviously doesn’t work anymore. I wonder whether it would be possible to force the installation of a specific version of CrashPlan, and then update it after the installation is complete. This whole article is going to need to be reworked, obviously. Thank you for the information.
Mel, great work, thanks a lot for your attention to RPI and Crashplan. I’ve tried to enable “headless” connection via ssh yesterday but it did not work (I have to look into it more carefully, it’s probably my fault). A friend of mine also uses RPI for a number of things including Crashplan and he told me just half an hour ago that he tried to run UI on RPI without success and log data is exactly the same as I posted above. This is a new development, from the last week, so I guess we will have to wait a bit for more Unix-skilled people to come up with solution, here or elsewhere. 🙂
We have a fix: for everybody experiencing issues with Crashplan UI and missing libswt-gtk-4427.so according to log I have posted, they have to repeat the last step from Mel’s tutorial:
sudo cp /usr/lib/java/swt-gtk-3.8.0.jar /usr/local/crashplan/lib/swt.jar
It seems that the new installation package for Linux issued in January and/or updates issued by code42 install Java that is not compatible with PI. So, to recap:
– to make the enginer work: create symbolic link in a way described by Matt
– to make UI work: repeat last step from Matt’s tutorial
I apologize, the last line should read:
“– to make UI work: repeat last step from * Mel’s tutorial *” Not “Matt’s”.
Hi – thanks for linking back to my old stuff. It’s been a while and I’ve just got a Raspberry Pi 2 B. I know my instructions are out of date so I used yours – the only thing that didn’t work perfectly first time was due to the download of the JRE – instructions as in the comments above. I stuck with Java 8 as it’s already in the Raspbian image now.
sudo mv /usr/local/crashplan/jre /usr/local/crashplan/jre-installed
sudo ln /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt/ /usr/local/crashplan/jre -s
I may now put an updated version on my blog again!
I’m currently updating this article, and unless I’m mistaken, it looks to me like all of that patching of libtux, etc. may no longer be necessary. I still have some testing to do, but I went straight from creating the jre symbolic link as suggested by Rainer Boehme and Matt to starting up the engine. I have no errors in my error log other than the ones CP put there when the installer tried to start it up before I could create the symbolic link. If this works out, things may have just gotten a lot simpler.
Too good to be true. You can get the CrashPlan engine working, but the UI will still complain about libtux.so. Oh well.
Hi,
Thanks alot for this mate, Got crashplan and everything else working on my raspberry pi working. Next up is the new Raspberry 🙂
Alex
Pingback: Raspberry Pi Home Server: Index | MelGrubb.ToBlog()
Thanks man!
You made my day! I was struggling with all JRE issues and I was .at a minute from quit.
If you ever come to Bogotá (Colombia), I’ll get you for a couple of beers!
Cheers and thanks again!
Mel: I love these tutorials. Some of this stuff, including CrashPlan is exactly what I was looking for. So, thank you very much for putting these together.
Quick question: I’ve tried a couple of times to get CrashPlan installed and working correctly. And, for the most part it is, but the one thing I have ran into both times I have tried, is my computer I am backing up is reporting that there is insufficient space to do the backup at 7.4GB. I have the Raspberry Pi configured with an exHDD (4TB), and I followed the previous tutorial so that it should now be booting off of it. I have CrashPlan configured to do it’s backups to /mnt/data/Backups, which should be the 4TB-16GB. Any ideas?
Try using “df -h” to make sure that the Pi is really seeing all the space where you think it should. I haven’t mounted a drive over 3Tb, personally, so there could be some limit I’m unaware of, or perhaps it just didn’t get partitioned the way you intended. Beyond that, go look in the folders on that drive and make sure CrashPlan is really putting the files where you told it to.
I had to replace a bad HDD, and finally circled back around to it. I struggled with dd and the resize. Ultimately I ended up using rsync to clone the drive and finally have everything up & running. Thanks again for these tutorials. I definitely could not have accomplished this without your help.
I’m looking to buy a PI specifically for CrashPlan use. I’d like to use it offsite connected to a WIFI network using one of those wifi usb dongs. Any reason this wouldn’t work? Of course I would pre-seed the backup on the local machine to avoid having to backup 1.5 TB over internet/wifi
I haven’t done an off-site instance yet, myself, but it should work just fine. I mentioned this in the article and called it a CrashPi. I plan to do one of these,I just have no suitable off-site location to house one yet. The only problem I see might be with the firewall where you place it, but I think CrashPlan is supposed to be pretty good at negotiating it’s way through.
Thank you for your (astonishingly fast) reply 🙂
I did read about the CrashPi in your article. I guess the operative concept that I was asking about was the part where the Pi is using one of those WIFI dongles as a network connection. I’m not familiar with their performance (well of course not… I’m not even familiar with a raspberri PI LOL) and was wondering if there might be issues that I don’t know about that would be obvious to you or another reader 🙂
I tested the wifi network/crashplan with my Macbookpro – connected the mbpro to the wifi network at this offsite location, installed crashplan on the mbpro, started a job from my home computer. it connected and started backing up…. which suggests that provided that the PI+wifi dongle performs in a reasonably similar manner this should be technically feasible.
Ah, I was focusing the wrong part of the question. It should work fine. Just make sure you pick something that will work with the Pi. Somewhere there’s a semi-official list of which ones work and which ones don’t. I have a Tenda w311m, and it works out of the box (after configuring the network of course). The nice thing about backups is that they can trickle along in the background, so unless you’re really churning your drive contents it should keep up.
Hello Mel, thank you so much for your walkthrough.
I haven’t tried it yet, and I´m looking forward to, but I was wondering about the expectations I should have about the Pi performance regarding the size of the backup data selected and the amount of files.
I already have CP running in my Mac. The data set is around 1,5 TB with almost a million files in it.
On the mac I need to give the CP process near 3 GB of RAM to work properly.
Is it realistic to expect the Pi to handle such a job? I´m not that worried about the speed since I plan to let the Pi run all the time given its small energy usage.
What Pi are you using? The new 2 model?
Thank you!
Sorry for the late reply. Busy weekend. You can expect the Pi to be pretty much crushed during the initial backup, much like when minidlna starts indexing a sizeable collection. Once the backup set is caught up, however, the traffic drops off, and in my experience the Pi performs admirably. Of course, if you’re backing up a huge system with a lot of churn your mileage is going to vary. For my simple home needs, the pi is keeping up just fine. ________________________________
Help, I’m eternally stuck at “connecting to backup destination”. My computer can see the RPI but it just stays like that. Should the permissions on the ext4 drive to which the RPI connects have specific chown, chmod settings? Any help would be greatly appreciated.
I purposely avoided ext4 for the external drive to get around problems just like this. Using Webmin to set up the share helps a lot, but I have not set up shares from anything ext4. I’m seeing a trend with questions about it, though, so maybe it’s time for me to figure out out and add it to the series. In the meantime, what you’re after is a public share. “chmod -R 777 /path/” will do it, but make the security experts scream.
Tried that but to no avail. What format do you use?
I’ve used NTFS because it lets me plug the drive directly into a Windows computer when I want to move large amounts of stuff around. As a side effect, it works very well permissions-wise with the samba shares. ________________________________
Tried that but to no avail. What format do you use?
This is driving me nuts, I spent countless hours trying to get CP to start backing up, I rebuilt the service from scratch, nothing works. CP on the RPI sees the other computers on both local and distant networks so that is not the issue, it just gets stuck at “connecting to backup destination” and nothing I tried seems to work. It did work briefly for 30 minutes early in the morning two days ago. I hadn’t configured anything preceding this so I’m wondering if the culprit is the EXT4 formatting? I changed permissions with both chmod and chown, I changed drives, I even tried out this solution: https://randomwindowstips.wordpress.com/2013/02/25/crashplan-pro-for-linux-stuck-at-waiting-for-backup-or-connecting-to-backup-destination/
which seems to describe exactly the problem I am experiencing but to no avail.
I was considering, as you suggested, the NTFS format except that I’m using Mac OS on most of my hardware which cannot write to NTFS. Im at a loss, what do you suggest I try as a next step?
Try following the steps at https://www.thomas-krenn.com/en/wiki/Simple_Samba_Shares_in_Debian. It’s the most straight-forward guide I’ve seen for creating open ext4 shares. You’re not talking about the share itself here, but maybe opening it up like this would help solve the problem if it’s permission based. I thought Macs could read ntfs natively. I could be wrong, but I know I’ve handed an external drive of mine to a Mac user plenty of times, and they didn’t seem to have a problem.
NTFS on Mac can read but not write. Thanks for the suggestions, I will try the steps let you know.
Ok, I figured it out, it was a rights issue, I had to sudo su before installing CP. All good now!
Just running the installer as pi through sudo wouldn’t work for you? I hope this isn’t another new wrinkle in the process. I’ll run it through myself and see what happens for me. ________________________________
Doing the installation through root was the main difference with your procedure. I also created a 1gb swap file on the HD to avoid killing the SD card. I guess you didn’t need that since you are running everything from the HD.
BTW I also have Plex media server running on my RPI2 !!!
Nice. I want to compare that with mini dlna, but haven’t gotten to it yet. ________________________________
I have the same problem and command “sudo su -” didn’t help me.
I tried to use “-Djava.io.tmpdir=/var/crashplan” , but it did not produce any results.
In /usr/local/crashplan/log/engine_error.log I get:
Exception in thread “W18096701_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(JNAInotifyFileWatcherDriver.java:21)
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(BackupSetsManager.java:393)
at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(BackupSetsManager.java:331)
at com.code42.backup.path.BackupSetsManager.access$1600(BackupSetsManager.java:66)
at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(BackupSetsManager.java:1073)
at com.code42.utils.AWorker.run(AWorker.java:158)
at java.lang.Thread.run(Thread.java:744)
After a while, crashplan stopped autostarting, even after I reran the command in the article.
So I did a # echo “sudo service crashplan start >> /etc/rc.local”
to remedy the situation 🙂
A
How would I go about uninstalling crashplan because i believe it installed wrong as it is not working
“apt-get remove (package name)” uninstalls packages, but leaves their configuration files behind. Since you suspect something may have gone wrong, you probably want to start over clean, though, in which case “apt-get purge (package name)” is probably what you’re looking for.
thankyou
thankyou
These directions were amazing. Now I’m running Crashplan on my Raspberry Pi 2. Thank you!
Just in case somebody else runs into the same problem. I had a problem where the Crashplan engine is running fine on the Raspberry Pi, but the front end wouldn’t connect remotely. The service.log reported:
[04.20.15 17:59:08.360 WARN MQ-Peer-0 de42.messaging.security.SecurityProvider] SP:: Exception: initializingExchange w/ PbK, closing session=Sessi
com.code42.exception.DebugException: SP:: Exception: initializingExchange w/ PbK, closing session=Session[id=685861225933832449, closed=false, isLocal=false, la
at com.code42.messaging.security.SecurityProvider.handleException(SecurityProvider.java:847)
at com.code42.messaging.security.SecurityProvider.handlePublicKeyResponse(SecurityProvider.java:493)
at com.code42.messaging.security.SecurityProvider$ProtoMessageReceiver.receiveMessage(SecurityProvider.java:1199)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.code42.messaging.MessageReceiverProxy.receiveMessage(MessageReceiverProxy.java:136)
at com.code42.messaging.Session.receiveMessage(Session.java:299)
at com.code42.messaging.nio.MessageQueue$MessageWorker.handle(MessageQueue.java:145)
at com.code42.messaging.nio.MessageQueue$MessageWorker.handle(MessageQueue.java:81)
at com.code42.queue.QueueWorker.run(QueueWorker.java:60)
Caused by: java.security.ProviderException: setSeed() failed
at sun.security.provider.NativePRNG$RandomIO.implSetSeed(NativePRNG.java:458)
at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:329)
at sun.security.provider.NativePRNG.engineSetSeed(NativePRNG.java:212)
at java.security.SecureRandom.setSeed(SecureRandom.java:416)
at com.code42.messaging.security.SecurityProvider.getRandomBytes(SecurityProvider.java:876)
at com.code42.messaging.security.SecurityProvider.initializeExchange(SecurityProvider.java:614)
at com.code42.messaging.security.SecurityProvider.handlePublicKeyResponse(SecurityProvider.java:489)
… 9 more
Caused by: java.io.IOException: Invalid argument
After some googling I found that it was because the random number generator couldn’t be seeded and to solve it, I added ‘ -Djava.security.egd=/dev/random”‘ to the SRV_JAVA_OPTS in bin/run.conf.
Hi!
Thankyou very much for this tutorial now my raspberry pi server works perfectly with crashplan.
Thanks again!
Hello,
I managed to get Crashplan working on the Raspberry Pi using your tutorial.
Today, it just stopped working. I suspected that it may have updated and re-patched jtux and md5, to no avail. I do not believe it is caused by a JRE of the wrong architecture because it actually manages to write to a log file before dying. It starts, then around 2 minutes later just quits for no good reason.
The CrashPlan log files are at https://drive.google.com/uc?export=download&id=0B4K3K2b1-TCdUUhRSXRRWGotUjQ
If you have any ideas to what could have happened, or a potential fix, please reply!
Thanks for everything.
I think this is probably a better question for the CrashPlan forums (https://helpdesk.code42.com/forums). The only thing of interest I can see is in the engine_output.log, where it seems to be saying it can’t connect to localhost port 4242 and 4243. Not being able to connect to yourself seems like a bit of a problem, if you ask me, but that’s about all I can tell. I’m by no means a CrashPlan expert. I just wanted a cohesive set of instructions in one place rather than scattered all over the web in 20 different styles. I just installed CrashPlan on a new server about a week ago, and it all came up just fine for me. Perhaps if CrashPlan itself were updated, it may have overwritten the patched files, but nothing else should have touched them since they are local copies. There is the symbolic link to the JRE, so if that were updated, perhaps you’ve uncovered an incompatibility with the newer version in which case I can expect to see a lot of similar comments in the near future. I’ll be building a new server from scratch here in a few weeks after a personal project wraps up (stay tuned for news), so I’ll know for sure if everything still works at that time.
Thanks for this very helpful guide. Especially the point about having to replace the locally installed JRE version with the 1.8 system version. This was holding my install back.
Just to confirm this method works with Crashplan 4.3.0 the latest version on Raspberry Pi B+.
It looks like Crashplan 4.3.0 has changed some bits of code and the way you connect to a headless client has changed.
The current Raspbian releases have 1.8 already.
Something very strange happens on my RPI w/ CP setup: After a while of backing up correctly, CP redirects my backups to the SD card instead of the USB HD. I’m wondering if this is happening because the HD goes to sleep?
Any ideas?
If there are no reboots involved, I would say that the drive going to sleep is the next best culprit, but that still shouldn’t make the drive disappear, it should still be there but just be sluggish on the first request while it wakes up. You might try looking to see if there is any kind of configuration utility for the drive that would let you disable the sleep feature. I have seen my backups go to the wrong place when the drive failed to mount properly, but once everything was set up, it all seems to have stayed up for me.
Thanks Mel, I actually reformatted the drive to ext4 and the problem just went away. I guess it was wrongly formatted to start with.
You might also want to make sure that the “rootdelay=5” is added to cmdline.txt to make sure the USB drive has enough time to be discovered before anything tries to use it.
I’ve recently run into the following engine_error.log entry when trying to start the CP engine (NOT the UI, which was reported earlier in this blog to having a similar problem). I think this all started when CP updated to version 4.4.1 from 4.3.3.
Exception in thread “main” java.lang.NoClassDefFoundError: com/backup42/service/CPService
Caused by: java.lang.ClassNotFoundException: com.backup42.service.CPService
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
Could not find the main class: com.backup42.service.CPService. Program will exit.
Exception in thread “main” java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
Can’t load library: /tmp/.cpswt/libswt-gtk-4427.so
Can’t load library: /tmp/.cpswt/libswt-gtk.so
no swt-gtk-4427 in java.library.path
no swt-gtk in java.library.path
/tmp/.cpswt/libswt-gtk-4427.so: /tmp/.cpswt/libswt-gtk-4427.so: cannot open shared object file: No such file or directory (Possible cause: can’t load IA 32-bit .so on a ARM-bit platform)
I’ve linked /usr/local/crashplan/jre to the oracle 8 jre directory, but this doesn’t seem to work. I’m a java newbie so I have no clue where ths libswt-gtk-4427.so lib is supposed to be – and why it is even needed for the engine part – I run (or did!) headless so I don’t try to use the CP UI on the RPI.
Any help would be appreiciated!
Well, I’m not sure why the engine would care about swt, but that certainly seems to be what it’s complaining about. Linking the java directory was only one of the steps, though. Double-check the steps in the UI section, where swt gets installed. Even if you’re running headless, you’ll need the UI to get things set up. An alternative is to connect the UI from a different computer, and there are plenty of tutorials out there that go this route. Either way, you’ll need to connect the UI so that you can configure CrashPlan, or retrieve that instance’s “friend code” if needed. Still, you should be able to run the engine before ever touching the UI. I’m going to be rebuilding my server under Jessie soon, so I’ll have a chance to check into this.
I found that /tmp/.cpswt/libswt-gtk-4427.so exists, so I did a readelf -a on it. While I ‘m not an expert in this area, it appears to be a 80386 compiled lib:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2’s complement, little endian
Version: 1 (current)
OS/ABI: UNIX – System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Intel 80386
This agrees with the actual error (wrong machine type) reported.
What I don’t know is exactly how this version got there, and why it’s not an arm based version. I believe I’ve followed the steps properly (given this was an existing configuration to begin with.) I could have my java installation corrupted in some way, as I have/had different java versions on my RPI. CP 4.4.1 appears to need 1.7 or greater, while previous releases could run on 1.6 which is what I had originally. I did have some problems installing new versions and getting them recognized as the version to use. However, they all were downloaded from the RPI repositories, so I’m surprised that there would be an incompatibility problem.
Today, I’m going to revert back to a previous image where 4.3.3 is OK, so I can at least run a local backup once. Then I’ll uninstall CP and java completely and start over. I’ve been trying to avoid that, but looks like that’s the best way to go for now.
Thanks for your great blog!!
I just dawned on me that /tmp/.cpswt/libswt-gtk-4427.so is installed by CP, hence it not being arm based. So maybe we need a arm version, like the other two libs from Jon Rogers. I have not idea how to go about doing that. But I suspect a fresh re-install will only get me back to the same place (wrong /libswt-gtk-4427.so). BTW, isn’t /tmp an odd place to install a lib file?
Also makes me wonder whether anyone else is having this problem once their CP updates to 4.4.x. Am I just the first to run into this, or am I still doing something wrong?
No one else having this problem with 4.4.1 or higher?
Hi,
Update on the CrashPlan 4.4.1 + Raspbian Jessie issue:
I recently bought a Raspberry Pi 2 Model B to take care of backing up my NAS to the cloud. Using these thorough and great instructions the backup seems to run nicely as we speak but some errors occurred during installation and startup. I skipped the Java replacement part of this guide since the older version JRE7 has been removed from installation files.
1) http://s3.postimg.org/yh1vjgq5v/cp441_1.png
Installer couldn’t move some files to their designated destinations but this seems to have zero effect on functionality.
2) http://s10.postimg.org/5ckg5ji7d/cp441_2.png
Starting the engine gives no errors but status is still ‘inactive’. However on command ‘sudo service –status-all’ CrashPlan is on the list of running services. I wasn’t able to stop the service (well, why should I).
Local desktop UI won’t start but remote control on Mac works perfectly.
I’ll keep you up to date on the progress of the backup.
I have had a report of the engine not wanting to run without SWT, which makes no sense to me because that’s clearly a UI piece. Perhaps they’ve rearranged things in recent versions. I don’t really know. I’m hoping to get to do a clear Jessie install beginning to end sometime soon, and update the blog posts (and hopefully some of the PluralSight video as well). Things have been a bit busy around the house recently, though. It’s on my list, and hopefully this week or this weekend I’ll be able to run through the whole thing again to double check that it all still works. If you do find out anything interesting, please share. It might help someone else out until I can make the updates.
I’ll be monitoring the backup process intensively. So far everything’s OK. CPU usage is around 20-30 %.
If something comes up I’ll post it here.
It looks like I have it working. The only real changes were to skip anything to do with replacing the old JRE with 1.8. It looks like the installer no longer tries to install its own. I still needed to replace libtux and libmd5, edit the CrashPlanEngine file to insert “/usr/share/java/jna/jar”, and install SWT. The version of SWT is now 3.8.2, so that changed the copy command a bit. Other than that, I’ve been able to start up CrashPlan, and to manage it from the desktop.
Thanks!
Exactly the same errors for me on Raspbian Jessie + CP 4.4.1 running on RPi 1 B.
The instructions still apply, though – and everything seems to work OK, as long as you manually start the CrashPlanEngine on the Pi, and control it remotely from another machine: https://support.code42.com/CrashPlan/4/Configuring/Using_CrashPlan_On_A_Headless_Computer
Thanks so much! Your instructions helped me set this up for the first time, and just now the UI broke again. This instruction was the key one to get it going again:
sudo cp /usr/lib/java/swt-gtk-3.8.0.jar /usr/local/crashplan/lib/swt.jar
You may find that newer downloads have a different version number. I just did one this morning and it was 3.8.2
Thanks for the guide but I am having what seems to be a unique problem (unless I missed something in these comments). I am running a RPI 2 Model B and CrashPlan seems to be install fine but then I cannot seem to accomplish anything else.
sudo service crashplan start gives me: Failed to start crashplan.service: Unit crashplan.service failed to load: No such file or directory.
Any suggestions?
I just ran through this last weekend, and posted updates where things have changed due to the new Raspbian release. Make sure to read the updates at the top of the post. Other than changes I posted there, everything still worked for me.
Yes, if I understand correctly, I don’t need to do anything pertaining to Java. I installed and updated the files mentioned in post but no change. I guess no one else has had this particular error. I wish I could figure out what I am missing.
I have the same problem running RPI 1. I tried to uninstall and install. Now I got an error during install, but it says installation is complete. Here is the printout of the reinstall:
Unpacking /./CrashPlan_4.4.1.cpi …
101180 blocks
mv: cannot stat â/usr/local/crashplan/electron-ia32â: No such file or directory
â/usr/local/crashplan/app.asarâ -> â/usr/local/crashplan/electron/resourcesâ
mv: cannot move â/usr/local/crashplan/app.asarâ to â/usr/local/crashplan/electron/resourcesâ: No such file or directory
chmod: cannot access â/usr/local/crashplan/electron/crashplanâ: No such file or directory
Your Linux system is currently configured to watch 8192 files in real time.
We recommend using a larger value; see the CrashPlan support site for details
Starting CrashPlan Engine … Using standard startup
OK
CrashPlan has been installed and the Service has been started automatically.
They’re is an option to completely purge apt-get packages during uninstallation. I don’t have the syntax on me right now because I’m not at home, but do a quick search for “apt get uninstall purge”, and it should be easy to find. That SHOULD completely remove everything so you can start again from a clean slate. I’d throw in a reboot as well for good measure, too. Hopefully that fixes it for you.
I ran into those same errors on Ubuntu and Debian and reached out to support and they mentioned it was related to a component of CrashPlan 5, which hasn’t rolled out to home users yet.
“That is part of our web server for CP5 clients, which isn’t in production for CrashPlan Home just yet, hence the errors.”
Just thought you might want to know. CrashPlan seemed to work out ok.
That’s puzzling. If it hasn’t rolled out yet, then how did you end up with that version?
Very puzzling indeed. I can only guess that they use a universal installer for crashplan but I haven’t really messed with the PRO editions, so that’s only a guess. At least it isn’t a ground-breaking error.
So I just ran into this error tonight. My old SD card died, tried a full reinstall. This held me up.
It seems a simple reboot fixes the problem. The newer Crashplan is smarter during the install. Crashplan actually starts up correctly on reboot, no needing to edit any startup files anymore.
Prior to the reboot, I kept getting the error you mentioned. But I found I was able to start it simply through /usr/local/crashplan/bin/CrashPlanEngine start. (In fact, if you look at /etc/rc3.d/crashplan/S01crashplan, you see that’s what it runs when you do service crashplan start). After the reboot, everything is clean.
Overall, a much cleaner experience this time. Raspian comes with Java 1.8. So as the updator said “It is no longer necessary to replace the Java Runtime Engine since the newer installer doesn’t seem to include it anymore, so skip removing /usr/local/crashplan/jre, which doesn’t even exist, and don’t create the symbolic link.” The other instructions are still necessary.
I run a headless client option, so I didn’t need to update the widget toolkit (SWT). Though I did find with the headless client option, the engine had to run for a a few minutes successfully before that .ui_info file finally appeared in /var/lib/crashplan.
Also Mel Grubb, thanks for the shout out for my swap file contribution from years past. I appreciate it. 🙂
Thank you guys! Thanks to Mel’s excellent tutorial I have two CrashPis running for a while now to backup all my family’s data. I was wondering why the recent update broke the UI but coming back to the blog and reading about the solution made me fix it immediately. 🙂
I’m glad the update helped. I may rebuild my own CrashPi soon on Jessie just for the experience. I’ll be making a separate blog post about that when it happens.
Hi Mel,
Another thanks for a great tutorial. I managed to setup my RPi backup server over the weekend :-). One question though…
I planned to let the Pi backup the local network, and then backup the Pi to the Cloud. When I try to backup the backups however, I’m not able to select all the files. Just selecting the Backup directory gives me a very small backup, with only a limited amount of files. Do you have any ideas?
Would the strategy I foresee work anyway?
Thanks!
I wouldn’t try to back up the backups. For one thing, those files are almost definitely in use at the time you’re trying to back them up. With CrashPlan, you can easily select multiple backup locations for the same data. Select both your local and remote destinations for the computers you want to back up, and then you’ll have your two copies. It will be far easier to restore, too. CrashPlan keeps track of what came from where pretty well.
OK, thanks! I guess this gives me another Pi to configure….
Pingback: CrashPi – An off-Site backup for the whole family | MelGrubb.ToBlog()
I have tried multiple times to get this running but I cannot seem to get the UI to start. My response to: sudo service crashplan status is different than what seems to show in this post. Here is my results to sudo service crashplan status:
crashplan.service – LSB: CrashPlan Engine
Loaded: loaded (/etc/init.d/crashplan)
Active: active (exited) since Sun 2015-12-27 21:25:58 EST; 1h 41min ago
Process: 479 ExecStart=/etc/init.d/crashplan start (code=exited, status=0/SUCCESS)
Dec 27 21:25:56 PCRPHS crashplan[479]: /usr/local/crashplan/bin/CrashPlanEngine: l…ry
Dec 27 21:25:58 PCRPHS crashplan[479]: Starting CrashPlan Engine … Using standar…up
Dec 27 21:25:58 PCRPHS crashplan[479]: OK
Dec 27 21:25:58 PCRPHS systemd[1]: Started LSB: CrashPlan Engine.
Dec 27 23:00:58 PCRPHS systemd[1]: Started LSB: CrashPlan Engine.
Hint: Some lines were ellipsized, use -l to show in full.
Does this give any indication of a problem? I replaced the files as instructed in this post to get the UI working but the interface still will not start.
Can you do and report:
uname -a
Also, if you followed the GUI instructions above, and it’s not working, consider looking into headless clients. It takes a bit of work to get all the details exactly right, but when you do, you won’t need to have a monitor always hooked up to the pi. Just a network connection.
uname -a
Linux PCRPHS 4.1.13-v7+ #826 SMP PREEMPT Fri Nov 13 20:19:03 GMT 2015 armv7l GNU/Linux
The lines you quote look like success to me. They show the engine starting up. As for the GUI, I’ll be going through the steps again in the next day or so, and will see what I find. Try looking at crashplan’s log files and see what’s there.
I went through the steps just 3 days ago. The GUI part worked for me. But if I recalll, there’s enough changes dealing with steps that aren’t needed that a full run through of the steps couldn’t hurt.
I seem to be having a similar problem. What’s curious is that my output from ‘service crashplan status’ looks pretty much the same as Paul’s. Crashplan service is also shown as running when I do ‘service –status-all’. However, I can’t find any sign of the process running through either ps or htop.
I had this working before on Wheezy (with Crashplan V4.4.1), and the crashplan/java process would be prominent on (and at the top of) the htop list, but now that I’m trying to do this jessie, I’m getting this puzzling outcome.
uname: Linux minimus 4.1.18-v7+ #846 SMP Thu Feb 25 14:22:53 GMT 2016 armv7l GNU/Linux
I’m (trying to) install crashplan V4.5.2, which seems to be the latest version on the crashplan website. Curiously, given the updates at the top of the article, the installer has been downloading the JRE, so I have been following all the steps in the article. (In fact I’ve tried uninstalling and going through the process a couple of times, in case I’ve missed something. I’ve also tried installing crashplan V4.4.1 with the same result.)
I’ve not yet tried accessing it headlessly from another computer, so I could try that, but I’m not optimistic….
Does anyone have any thoughts? Am I missing something?
Ah. I figured it out. Instead of
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt /usr/local/crashplan/jre
I had to use sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
as it appears that the folder name has changed for the current version of the jdk.
I found an easier way to setup ‘headless’ UI access to the CP server – easier than using an SSH port-tunnel as described by Code42. Basically, it entails making the ‘server’ expose its UI port (4243) to the LAN instead of only to localhost. Then, just script the fetch of the current UI key data, and run the UI on your desktop to access the engine on the server. Following is my own writeup on how (which I keep for when I forget), which is not extremely detailed, but does include a sample script that makes it a one-word command to open the UI connected to the remote engine.
Hope it’s helpful to someone.
==============================
How to access a headless instance of CrashPlan
On the ‘server’ (where CrashPlanEngine runs):
alter $CRASHPLAN/conf/my.service.xml
change line:
127.0.0.1
to
0.0.0.0
to permit remote UI connections.
(restart CrashPlanEngine to cause this to take effect)
On the client (where CrashPlanDesktop runs):
Save current copy of /var/lib/crashplan/.ui_info
Retrieve a current copy of same file from ‘server’ (it changes with every engine restart)
Alter it:
replace key from target host’s file of the same name
replace 127.0.0.1 with target IP or hostname
… Use the desktop client …
Replace local copy of /var/lib/crashplan/.ui_info
Here’s a shell script for automating the on-demand connection setup on the desktop:
—————–
#!/bin/sh
cd /var/lib/crashplan
# save a copy of the local .ui_info
sudo cp /var/lib/crashplan/.ui_info /var/lib/crashplan/.ui_info.local
# fetch a copy of engine’s .ui_info file – we need its key
sudo scp -i ~/.ssh/id_rsa serverhost:/var/lib/crashplan/.ui_info /var/lib/crashplan/.ui_info.server
# compose a custom version of the .ui_info file, using the detail for server
echo -n `cut -d , -f 1-2 /var/lib/crashplan/.ui_info.server`,server.>/tmp/.ui_info
sudo cp /tmp/.ui_info /var/lib/crashplan
# this starts the GUI and returns immediately
/usr/local/bin/CrashPlanDesktop
# give the desktop client time to start, and read our custom .ui_info file
sleep 15
# then replace the local version of .ui_info
sudo cp /var/lib/crashplan/.ui_info.local /var/lib/crashplan/.ui_info
# this script exits. The desktop UI may still be running at this point, but we don’t care, it’s connected.
BTW, the server side config change needs to only happen once, or perhaps only after an update to the server code.
FYI, today’s update to 4.6.0 screws things up big time. To get it to working condition again you have to remove the jre-folder from /usr/local/crashplan and create the symbolic link again. After that, UI needs its normal post-update swt.jar replacement operation.
Personally I think that this fully automated update process sucks. At least a notification prior to start would be nice. I think I’m going to give some feedback to Code42.
Hi Mel,
Thanks for the great course on PluralSight and this blog, really useful stuff. I managed to get my service running quite easily, but the UI was some other stuf… Finally managed to get it started by updating libjtux.so. Though the service starts OK with the existing version, .ui_info does not get created and the UI cannot start.
Look through the recent comments, and see if anything helps. Out of all the sections of this series, CrashPlan and OpenVpn are the two that seem to break the most. CrashPlan in particular has a habit of changing file locations almost every time they release a new version. I’m currently working on an updated set of posts, but it might be a week or two until they are up.
I managed to get it working by downloading the modified version of libjtux.so, I just wanted to share the info, but I think I was not clear
Hi Mel – excellent series – thank you for such clear instructions.. I can’t get the GUI up – I’m using Jessie and have followed the process to the letter but the GUI fails to open. Decided to try headless mode but the my.service.xml file in the conf folder doesn’t exist. Service status looks the same as Paul’s above
Any help or direction would be great !!
I did this not too long ago and things still worked, but I’ll check again this weekend. CrashPlan and OpenVPN seen to be the most troublesome parts of the series to keep up to date.
Due to a very recent update…
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt /usr/local/crashplan/jre
should now be
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
Thanks Ryan – that did it !
Also realised there appears some spurious characters in an earlier segment of sample code:
sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libmd5.so –O ./libmd5.so – the part starting with the -O does not appear in the screenshot and appears to generate some errors.
Try typing it instead of copy/paste. From what you quoted, it looks like WordPress may have changed the hyphen into an em dash. I thought I’d fixed all of those. The -O specifies the output file. In this case, since the file name isn’t changing, you can get away without it, but a lot of times you need to change the name of the file as it will appear locally, so the -O is very much required.
My Crashplan service on my RPi B was working fine for many months, but now won’t run after the March 25 update. I’ve tried replacing the new SWT library as you suggested in your Troubleshooting paragraph and Ryan Brownell’s link change above, but no luck. Any suggestions?
My CrashPi stopped working as well after the update. You need to re-make the symbolic link that points to the Java Runtime Engine.
First, shut down CrashPlan with “sudo service crashplan stop”
Then, remove the existing symbolic link with sudo rm /usr/local/crashplan/jre (Better make sure you have a backup, but I think I got that right)
Next, create the new symbolic link with “sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre”
Finally, restart CrashPlan with “sudo service crashplan restart”
Check the logs for errors, and let me know if there’s something more specific there that needs attention.
I’ve created the new link but Crashplan still stops immediately. The engine_error.log has this:
/usr/local/crashplan/jre/bin/java: 1: /usr/local/crashplan/jre/bin/java: ELF„4: not found
/usr/local/crashplan/jre/bin/java: 2: /usr/local/crashplan/jre/bin/java: Syntax error: “(” unexpected
There appears to be some non-ASCII characters in the first line after “java:” and before “not found”.
An engine_output.log was created but empty.
My java version is:
java version “1.8.0”
Java (TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) Client VM (build 25.0-b70, mixed mode)
That’s what I was seeing last weekend too, and I don’t recall doing anything other than re-aiming the symbolic link. You have to make sure you get rid of the old one first, or you just end up making a new one inside the old one. After removing the old link, there shouldn’t be anything with the name “jre” inside the /usr/local/crashplan folder. Once it’s clear, then create the new symbolic link, and that should be all that’s needed. I know a couple others ran into this as well recently. Maybe if they’re listening, and took better notes than me, they can chime in, but I’m pretty sure this is all I did last weekend to get things up and running again.
FWIW, I also simply removed the jre link and relinked. I did NOT need to link the arm32 version (which I didn’t have anyway) as suggested by Ryan.
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt /usr/local/crashplan/jre
worked fine. Not sure why some of us need the arm32 version and others work OK with the arm version.
Seems to be fixed, the service is running. I hadn’t properly cleaned out the old jre. Thanks for the help.
Yup. That’s exactly what happened to me.
All great updates, but I still cannot seem to get the gui running. Service seems to be running successfully after making the above updates.
You need to do the swt.jar replacement change again to get the GUi up:
sudo cp /usr/lib/java/swt-gtk-3.8.0.jar /usr/local/crashplan/lib/swt.jar
Most likely 3.8.2 if you’re doing it now.
Well, I just went through installing CrashPlan tonight as part of an update to the series, and it worked for me. The only updates specific to the GUI are the installation and copying of the new SWT (make sure the version number is right. It was 3.8.2 for me tonight). Look in the CrashPlan logs folder, and see if there are any hints in the log file for the UI. I’m pretty sure it has its own separate log file, although I don’t have the name handy off the top of my head.
Mine is still 3.8.0, and that worked. So I guess the difference isn’t critical
FWIW, Sometime during Apr 14-15, my Raspberry PI CrashPlan changed from using listening ports 4242/4243 to 4260/4261. My PC-based CrashPlan systems are still using 4242/4243. All are running 4.6.0. I noticed this because I use a scheduled task on my PC to poll the Raspberry Pi CrashPlan service by temporarily connecting to the listening port to make sure it is still running, as a sanity check, since my system occasionally would throw a JAVA exception and stop.
I thought I’d mention this in case anyone is (still) manipulating port info for remote access and is having access problems.
Interesting. Did you experience this on a fresh installation, or an upgrade to an existing system?
Well, it just happened on a running system. I had already upgraded to 4.6.0 at the beginning of April, but that was the last I did anything explicit with it. 4.6.0 was running fine. Then around Apr 14-15, my sanity monitor started to report no response on port 4242. When I looked into why it was failing, I noticed the ports had changed (i.e., my.service.xml had the new ports). Not sure what triggered that..
Today, my ports changed again on my RPI, this time to 4272/4273. Not sure why this is happening to my RPI CrashPlan. My PC instances are still at their original 4242/4243.
I have heard reports of ports changing, but so far it hasn’t happened to me, or at least not that I’ve noticed. My router has UPnP enabled, so it could be that CrashPlan is just taking care of it itself. If anyone has information about this, I’d like to incorporate an answer into the post.
I received an email from Code42 which stated that I have an unsupported operating system running on one of my computers using CrashPlan. Since I only use CrashPlan on Mac (supported version) and Raspberry Pi, I think the problem is with the latter one. My kernel and glibc are both within the supported version range so I really don’t know what is causing this. However the fact and the worst scenario is that on May 16 the update to 4.7 won’t install and everything stops working.
Has anyone using CrashPlan on Raspberry Pi got the same message?
Yep, I received the same message, and, as far as I can tell, my RPI meets the requirements as well. Not sure why CrashPlan thinks it doesn’t, unless it’s based on something other than kernel and glibc versions.
I got the same message all right. Fortunately we have some time to figure out how it will affect us.
My brother who runs his Crashplan on a normal Linux server got the message too. If I had to wager a guess, everyone running it on Linux got the message.
Thanks for the information. It’s quite inconsiderate to send a warning to all Linux users since the oldest supported kernel and glibc versions are very old. I think I will contact Code42 support to confirm that there aren’t any other software packages that need to be updated.
In all likelihood, it’s because Raspbian just isn’t on their list, even though it’s just another Debian variant. I haven’t had a chance to check what version got installed last time I rebuilt the crashpi, but it should be recent enough that I don’t think we need to worry. I’ll be checking it this weekend to be sure.
Anyone have any additional info on Linux/Raspberry Pi support? We could loose the ability to run CrashPlan on the Raspberry Pi in 4 days ;(
I’ve submitted a support request to Code42 asking for more info, but have not yet heard back.
As far as I can tell, we’re seeing this because Raspberry Pis have ARM processors. It’s not our kernel version, or the fact that we’re running an offshoot of Debian, it’s that we’re ARM-based, and that’s not supported. Since there’s no official word yet, we don’t really know what will happen. The current download from the CrashPlan site is v4.6, which should be what I currently have installed on my CrashPi. My best (only) plan at this point is to wait for the deadline and see what happens. I’m hoping that future updates just work, and everything is fine. Failing that, I’m hoping that reinstalling CrashPlan over itself in-place will do the trick. In the worst case, I’ll have to totally re-write the instructions from scratch.
I think the manual reload will have to be done, as I suspect they won’t even allow an auto-download/install to happen for those systems they detected are “not compatible”. If that’s the case, then we’ll probably be destined to keep an eye out for updates and apply future ones ourselves. But that would be way better than having this all go away!
In any case, thanks again for your great blog!
Just received this from Code42. Looks promising!
———————-
Thank you for contacting Code42 support.
We sent out an email blast warning of our impending update to users that we believed would not be supported on the new version, but the criteria that we set for the email meant that some customers that were running valid configurations did get included by accident.
I’ve reviewed your account and do not currently see anything that indicates you will run into any trouble when 4.7 is pushed.
What you need to know:
4.7 is a security update aimed at improving the protection of our CrashPlan application to help protect our customers.
After the update, clients that are unable to upgrade and are still running 4.6 or below will still be able to back up using Peer-to-Peer to a 4.7 client, but any computer running on a 4.7 client will be unable to back up to a client running 4.6 or older.
Any Windows machine must be running with a kernel of 6.0 or higher (Vista and newer).
Any Mac machine must be running OS X 10.7 or higher.
Any Linux computer with a kernel of 2.6.32 or later and running glibc 2.9 or later should be upgraded successfully.
This applies to any Friend that is backing up to your computer, or any Friend that you are backing up to.
The only thing that I see that may cause any issues is that I’m assuming the Linux machine is a Raspberry Pi, as it says -rpi, and those are not officially supported. Otherwise you should be good to go.
I apologize if this email caused you any inconvenience.
Please let me know if you have any questions.
Best regards,
Jacob Mee
Customer Champion
Thanks for sharing that support email. Code42 has been exceptionally compassionate when it comes to officially unsupported configurations. I don’t see why technical issues would prevent CrashPlan from working after the update as long as one’s system meets the (ridiculous) requirements. However I’m anxiously waiting for the deadline since nothing is certain in IT. Let’s hope for the best.
Great tutorials.
I seem to be having some issues with my installation at the moment.
Everything seems to work fine when I first boot the RPI but hours/days later the Crashplan interface on my laptop doesn’t seem to have the green bubble lit for the RPI.
A reboot solves the problem.
Any ideas as to what the long term solution is?
It’s hard to say. It may not even be CrashPlan that’s to blame. I found that transmission was the biggest destabilizing influence on my own server and speed running it. The more you do with the Pi at the same time, the harder it is to keep it happy. If you don’t use it a ton, like me, then it stays stable for far longer. You could try looking at the output from Top, and see what’s hogging the processor or memory.
Thanks
I’m currently only using it for crashplan (currently just testing before deploying offsite).
I had a quick top when running backup and the only tasks consuming were java and mount.ntfs. When not processing top looks very mundane.
I normally hibernate my laptop rather than rebooting, so maybe I’ll investigate that as the only issue appears to be with the laptop app not finding the RPI crashplan. At the very worst I guess I’ll have to schedule a reboot once a week. I presume that would be something to do with crontab.
Anyways, hopefully the problem will be with laptop hibernation.
Anyone experiencing problems after a possible update recently (file time stamps changed)? I can’t get the UI running anymore. Went through the instructions again and made all the replacements. Engine seems to be running though.
This fix worked wonderfully in the last months, but for some reason crashplan stopped working recently. It seems, ChrashPlan has updated the application. Although going through the whole instructions again, I could not get it to run (CrashPlan service starts, but stops after some seconds)
Might there be a java version issue? Any ideas?
There have been updates, and there’s one on the horizon right now (4.7, due to hit tomorrow) that we don’t know what to make of yet. Users who are running CrashPlan on Pis got an email a while back saying that we were on an unsupported operating system, and that everything was going to stop working on May 1th (tomorrow at this point). As it turns out, it’s not so much our OS, but our architecture that’s unsupported, but as we’ve heard (check the most recent comments), folks at Code 42 seem to indicate that we should be just fine as the 4.7 upgrade restriction has to do with computers connecting to their cloud backup, and this article was about self-hosting your own backup. The unfortunate thing is that when I hit their site to download a new installer, I still get 4.6, so I’m in a holding pattern at the moment, waiting to see what happens tomorrow.
Just to keep readers updated, my own CrashPlan instance has also stopped working. The UI won’t work because the engine doesn’t stay up. I’m looking into it, and hope to have some kind of clue soon.
FWIW, mine is still running (at least for now): UI and Engine, at 4.6.0.
I was auto updated to 4.7 on May 9th, as show in the logs. I had to replace libjtux.so and libmd5.so according to your instructions, now I’m succesfully backing up to Crashplan Central again.
Didn’t try GUI yet.
I found one problem with the most recent upgrade script. Line 3 of upgrade.properties has a syntax that doesn’t work on the pi. Getting rid of the /bin/bash part makes the script run, but it still fails. According to the logs, it doesn’t find what it’s looking for when it goes to move the new .jar files into position, and the fact that the /usr/bin/crashplan/lib folder is empty seems to back this up. I’m trying a few more things, and then I’m going to have to give a complete reinstall a try.
It certainly seems that the update came a week too early. For me replacing .so files didn’t have any effect. The process starts and then dies shortly after. As soon as they publish 4.7 as manual installation package I will give a reinstall a try.
There was an update on April 22nd, and that’s the one that seems to have broken things.
Yes, that one broke everything too. Replacement fixes worked back then but now I can’t figure out what’s the problem.
I’m at work now, so I don’t have it in front of me, but the last look I gave it had some errors in the engine_error.log file that I haven’t seen before. Parts of apache are complaining about trying to retrieve a file related to upnp from my router. What that has to do with CrashPlan is a mystery to me, but it’s in CrashPlan’s log file. The weirder thing is that whenever I try to look into the problem by checking the service status, it comes back up briefly. It doesn’t last long, but it wakes up for a few minutes. I’m really hoping they haven’t completely broken it. This is the one job that I count on the most. Even the file shares are only an occasional thing for me.
Hello, for me the update to version 4.7 was applied today automatically. After I replaced the two .so files and added the FULL_CP string, everything seems to be normal again. My MacBook is currently backing up to my Raspi CrashPlan 4.7. Just to let you know… Cheers.
I didn’t think the CrashPlan software would auto-update on Pi. Am I mistaken?
Or did you do something to invoke the update?
Before uninstalling and reinstalling the other night, I had evidence of three auto updates in my CrashPlan folder, so it looks like it does auto update on the Pi. This isn’t through apt-get or anything. It has its own mechanism.
Thanks Mel ~ out of curiosity what did you see that made you think it was updated? I ask not because I doubt you, but because I want to check the same thing on mine.
In the main CrashPlan directory, there’s an “update” (or maybe “updates”) directory. It will contain a .jar and a sub-directory for each update that has been applied. They have names made of numbers. Can’t miss ’em.
Yes, I also fix it like Thomas said; 1. .so files; 2. FULL_CP string; 3. replace java link pointing toward /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt/
Yes, this does the trick.
This also did the trick. Though I needed a reboot afterward.
A reinstall and going through this guide again = everything is working.
Same for me: Crashplan is working after reinstall, but only when using the new java link posted by “music” (without the 32 after “arm”). You might change this in your instructions.
Mine has the 32 in the name. Looks like another job for tab completion.
My RPI system finally auto-upgraded to 4.7.0. Did what “music” says to get the engine running again, and did the swt.jar re-link to get the us running. Didn’t have to do a manual reinstall.
Thanks to everyone who worked to get the 4.7 upgrade plan in place! Would have had no clue otherwise on what to do myself 🙂
Thanks, worked like a charm!
Thanks a lot for the help on 4.7-upgrade 🙂 Detailed description of the steps (from “music”):
1. Log on to Pi using ssh
2. replace two .so-files:
cd /usr/local/crashplan
sudo rm libjtux.so
sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libjtux.so
sudo rm libmd5.so
sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libmd5.so –O ./libmd5.so
3. Update the config file of CrashPlan:
sudo nano /usr/local/crashplan/bin/CrashPlanEngine
Find the row starting with”FULL_CP=” and add “/usr/share/java/jna.jar:” before. It should look like this:
FULL_CP=”/usr/share/java/jna.jar:$TARGETDIR/lib/com.backup42.desktop.jar:$TARGETDIR/lang”
Save & close.
4. Uppdate the symbolic java link:
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt/ /usr/local/crashplan/jre
5. Reboot the Pi:
sudo reboot
6. Log on to Pi using ssh and check status of CrashPlan:
sudo service crashplan status
Thanks Joel
Pingback: n8henrie.com | Installing CrashPlan on the Raspberry Pi (Raspbian Jessie)
Thank you very much for the tutorial! It has been incredibly helpful for installing and running Crashplan on my own Raspberry Pi 3.
I do have a question, I tried reaching out to Crashplan about this problem, but being that Raspberry Pi is technically not a supported product, they pretty much shrugged and wished me luck on it.
I’ve been getting the dreaded “Crashplan has been disconnected from the backup engine.” After about a month of successful cloud backup, it seems my raspberry pi 3 has ceased to work. I’ve reinstalled the program, I’ve rebooted my pi… nothing seems to be working here.
Would anybody have any ideas?
The first place to go is the CrashPlan log files. The engine_error.log to start with (I think that’s the name… working from memory). See what it’s complaining about.
The error I’m getting is according to the engine_error.log:
Java HotSpot(TM) Client VM warning: INFO: os::commit_memory(0x222c0000, 100007936, 0) failed; error=’Cannot allocate memory’ (errno=12)
That doesn’t sound familiar, but I’ll have to check in on my own CrashPi and see whether a recent auto-update has broken anything. It lives in my detached garage, and doesn’t get the greatest WiFi signal, so sometimes I lose the connection and can’t reach it, which is the case right now. I’m going to pull it back into the house and see if I can figure out what it’s upset about. Probably not until the weekend, though. If I see the same error, then I guess I know what my Saturday will be spent troubleshooting.
Crashplan is the only program I’m running right now on the pi3. The Code 42 people said that Pis don’t have the ram to do any backup above a couple hundred gig. Not sure how true is that.
I found this post after having read most of the stuff you refer to in the article. Nice write-up!
Unlike most of the readers though, I am installing Crashplan on the Cubietruck with stock Debian instead of a prebuilt image. I mostly followed the steps as you’ve outlined them with a few notable differences (this is from memory, so I may be forgetting some):
– I downloaded and installed the JDK straight from Oracle’s site. By the way, the Update note at the top of the article wasn’t my experience. The Crashplan installer did install the i586 jre which I had to replace with a softlink.
– I didn’t add JNA to the path. Granted, I haven’t tested thouroughly yet so that may still prove to be needed.
– I chose to rebuild libjtux.so from source.
– Based on a few articles I read, I also tried without the md5 library and as I suspected it worked. It appears to be optional and I think that when absent Crashplan uses the standard Java API which has apparently been improved in recent versions. Again, I haven’t tested all that thoroughly so I can’t be certain.
What bothers me though is that Crashplan installs a number of other libraries which necessarily cannot be used on an ARM platform. Consequently, I moved them all to a backup directory and simply replaced libjtux.so as mentionned above.
So why isn’t Crashplan complaining about the others? I don’t have it in front of me at the moment, but there were about half a dozen of them. Do we have any indication from Code42 that Crashplan can be expected to function normally without them?
Cheers,
Paul
I found this post after having read most of the stuff you refer to in the article. Nice write-up!
Unlike most of the readers though, I am installing Crashplan on the Cubietruck with stock Debian instead of a prebuilt image. I mostly followed the steps as you’ve outlined them with a few notable differences (this is from memory, so I may be forgetting some):
– I downloaded and installed the JDK straight from Oracle’s site. By the way, the Update note at the top of the article wasn’t my experience. The Crashplan installer did install the i586 jre which I had to replace with a softlink.
– I didn’t add JNA to the path. Granted, I haven’t tested thouroughly yet so that may still prove to be needed.
– I chose to rebuild libjtux.so from source.
– Based on a few articles I read, I also tried without the md5 library and as I suspected it worked. It appears to be optional and I think that when absent Crashplan uses the standard Java API which has apparently been improved in recent versions. Again, I haven’t tested all that thoroughly so I can’t be certain.
What bothers me though is that Crashplan installs a number of other libraries which necessarily cannot be used on an ARM platform. Consequently, I moved them all to a backup directory and simply replaced libjtux.so as mentionned above.
So why isn’t Crashplan complaining about the others? I don’t have it in front of me at the moment, but there were about half a dozen of them. Do we have any indication from Code42 that Crashplan can be expected to function normally without them?
Cheers,
Pab
I haven’t tried installing on anything other than the Pi, so I can’t really say, but what you say makes sense. If some of the libraries are only there to improve on the stock jre libraries, then it would work without them. I wouldn’t trust it without someone from Code42 telling me that’s the case, though. Also, check the error logs and see whether it’s actually happy, or complaining about something.
I installed CrashPlan yesterday and this guide was great! I did find one inaccuracy in that you do need to delete the JRE directory and put a symbolic link because CXrashPlan is shipping the JRE with CrashPlan still. The other thing is that the setup procedure described here may need to be repeated because CrashPlan will periodically update their software without asking you and all the changes that you made after running “install.sh” will disappear and you have to do it over again. The reason I know this is that today my CrashPlan stopped working all of a sudden. I looked at the timestamp on all the files in the /usr/local/crashplan directory and they were all today’s date @3pm. Since I know that I installed CrashPlan YESTERDAY I knew something was up… Called CrashPlan and they told me that their software will automatically update itself when they push an update. So FYI! My solution to this is to write a “repair.sh” script that will run on boot and repair the installation (i.e. just re-copy the files) so all I need to do if CrashPlan stops working is to reboot the PI. Hope this helps someone and maybe Mel might update his blog.
It’s odd, but I’ve found the presence of the JRE folder to be inconsistent. Sometimes it’s there, sometimes it’s not. I think it’s one of those things that changes when they release new versions of CrashPlan. Maybe they haven’t made up their mind. I like the idea of the repair script. I avoided putting scripts up on the blog because it’s supposed to be about learning what’s actually going on. I think adding a script at the end of the article might be a great idea, though. It would have to include everything, just the replacement of x86 binaries, creation of symbolic links, etc.
Anyone having difficulties with 4.7.0? I have been on this version for some time now, but suddenly lost connectivity a few days ago. I figured the version had been update (which tends to break this install), so I redownloaded and reinstalled (twice). All goes well with the installation, but when I get to the logon screen (in the gui) and click to logon it gives a message that CrashPlan is updating. Maybe they haven’t updated the linux download to the most recent version of their software? It’s been a few days with no connectivity for me…
Please ignore this comment…I figured out what I was doing wrong…
I just did a spot check, and mine is still up and running, so I guess it’s not a recent update. This one WAS rebuilt a couple weeks ago, though. I somehow corrupted my OS partition. Not sure how, since this one runs on a UPS and know how to shut itself down politely.
I followed your tutorial a couple of months ago and had Crashplan up and running on my Pi…it was working great! But just a couple of days ago I noticed that it had stopped and the Crashplan desktop app couldn’t connect to the Crashplan engine. I un-installed and re-installed Crashplan and fixed all the needed files. The CP engine starts, but then stops about 30 sec later. If you restart it, it does the same thing. Any fix? Net.wisdom says that this is related to auto-updating, but fixing that is beyond my skills at the moment.
Thanks for all your work!
The first thing to do is check the logs. Auto-updates break CrashPlan a lot, but you say you did a reinstall. As long as you hit all the steps (including replacing .so files and creating symbolic links), it should be working again. See what it’s unhappy about, and see where that leads.
Did a re-install from scratch, making sure I updated all the needed libraries. It now seems to be running fine, and the GUI is working too. I think I may have missed updating one of the Java libraries on my first reinstall go-around.
Thanks for the encouragement!
My system needed no more than normal file replacements and config file changes when the update to 4.7.0 installed itself. I guess every system is an individual case. Someone needs to do more tweaking than others.
The repair script sparky2708 suggested a few comments back would be a great improvement. However my skills are limited so if someone would be so nice and write one I would really appreciate it (I think I’m not the only one). Repairing CrashPlan on every update takes time and effort.
Hi all. If i do a re-install from scratch, do i need to restart all backups from the beginning? or will they automatically attach? My crashplan keeps crashing and theres nothing in the logs. 😦
Hi guys, my crashplan stopped working again, re-installed and still didnt work! Had a look at the logs and the jre folder didnt exist. I then looked through my original documentation that i took and it seems the jre has moved back to the original:
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
My current advice is to use tab completion to make sure you get the right filename. It seems to be subject to change.
If you reinstall CrashPlan, but configure it to point to the same folder to store the backups, it will pick up the old files and adopt then.
Thanks for a great tutorial! One thing I found missing here is that Raspbian Jessie seems to want to use systemd for starting CrashPlan on boot. At least I couldn’t get it to work as described above. Check out Nathan Henrie or for not only a pre-made crashplan.service file, but also a complete CrashPlan installation Bash script specifically written to install CrashPlan on Raspberry Pi with Raspbian Jessie. Using his crashplan.service file and script I was able to get CP to start at boot time. Maybe the same reason that Samba doesn’t restart on my machine?
Sorry that took so long to approve. That one slipped past me somehow. I’ll definitely check out the install script. I had started on writing my own, but I’m hardly a Bash guru.
Hi Mel
I have had Crashplan working. I then had the HDD die on me, the one that had my backups stored on it. Long story short is now I am having trouble getting the CrashplanDesktop to startup. I have followed the instructions in detail but I have no idea why the Desktop GUI has the small running circle for about 30 seconds and then fails.
i have done these steps
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
sudo rm libjtux.so
sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libjtux.so
sudo rm libmd5.so
sudo wget http://www.jonrogers.co.uk/wp-content/uploads/2012/05/libmd5.so -O ./libmd5.so
sudo nano /usr/local/crashplan/bin/CrashPlanEngine
to add
/usr/share/java/jna.jar:
sudo update-rc.d crashplan defaults
Rebooted numerous times along the way
and still the desktop icon does not start.
What other info do I need to look at to figure out what is going wrong?
Thanks
Ted
It sounds like you need to re-patch the UI, not the engine. Search my blog [ost for “swt-gtk-3.8.2.jar”, and you should find the relevant section
Hi Mel
Thanks very much for the speedy reply. I do appreciate it.
I redid everything from a new image. I am still not getting success. I do not know if this would help, but here is the contents of the ui_error.log from /usr/local/crashplan/log
/usr/local/crashplan/bin/CrashPlanDesktop: line 16: /usr/local/crashplan/jre/bin/java: cannot execute binary file: Exec format error
You are truly superhuman and I am sure that this blog keeps you far busier than it should.
Thank you so much
Ted
It seems that something went wrong during:
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
So crashplan is still using the JRE included with crashplan, which is not a linux executable (in my case it was the windows version, which is obviously wrong).
Check that /usr/local/crashplan/jre is a softlink to an ARM JRE.
If you run
/usr/local/crashplan/jre/bin/java -version
it should show something like
java version “1.8.0_77”
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) Client VM (build 25.77-b03, mixed mode)
I second what Rainer said. I would use tab completion to make sure you have the source filename exactly right. I still don’t exactly know why, but it seems that some people don’t end up with the “32” in the filename. type up to “jdk-oracle”, and then hit Tab to make sure you get the name of the file as it appears on your system.
Thanks for the heavy lift! I just saw the my Banana Pi Pro Crashplan server was not running.
I did a blog post & youtube video on the project. http://rich-blog.blogspot.com/2016/01/crashplan-server-on-banana-pi-pro.html
Thanks Rainer and Mel
For some reason the symbolic link did not work. When I asked for the version by /usr/local/crashplan/jre/bin/java -version
I got a negative response. I then checked the version in /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/bin and got the correct response. So I then did this
sudo rm -r /usr/local/crashplan/jre
Then I redid the symbolic link
sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre
Then I checked the version and got
java version “1.8.0_65”
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
Then rebooted and used the menu => applications => crashplan to launch, not the CrashPlan Icon on the desktop (that may work too but I didn’t do it that way.
Thanks again
Ted
Hello Mel,
I run into an error when I try to run crashplan after it successfully installs. After typing “service crashplan status”, I receive the following output:
/mnt/data/public/downloads/crashplan-install $ service crashplan status
● crashplan.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
If I type “sudo service crashplan start”, I get this message:
Failed to start crashplan.service: Unit crashplan.service failed to load: No such file or directory.
I’m pretty sure that the installer installed everything correctly, because the last few lines of the installation are
To start the Desktop UI:
/usr/local/bin/CrashPlanDesktop
Installation is complete. Thank you for installing Code42 CrashPlan.
I had this exact same error when I tried installing Plex in a previous module, but I decided to skip installing it and deciding to run MiniDLNA instead because my Pi only has an ARMv6 processor anyway and wouldn’t be able to handle Plex media server.
I’m really enjoying the Pluralsight course modules. I plan on using qBittorrent and PIA (Private Internet Access) instead of Transmission and OpenVPN, respectively, but I’ll use the programs you recommended to begin with and see if I can install additional packages as necessary to try switching to the applications I’m already familiar with.
Thank you for this course!
Sincerely,
Hamir
Yes, unfortunately CrashPlan now auto-updates on a pretty regular basis, and every time they do so, it breaks everybody. The solution that seems to be working best for everybody at the moment is to re-perform all of the patching steps, replacing the .so files, rebuilding the symbolic links, etc. You just have to do it again every time you notice that it has stopped working. Personally, I don’t think a backup solution that may or may not be there on any given day isn’t a very good solution. I’m pretty close to putting a big banner at the top of this article saying that because of the updates, the whole thing is no longer trustworthy. It would be nice if Code42 would just officially support ARM-based machines, but I realize there’s not really any profit in it for them, so I’m not holding my breath.
Hello Mel
I have crashplan up and running but when I want to start the GUI from my laptop I can’t find /var/lib/crashplan/.ui-info on my raspberry.
Running latest Jessie and chrasplan 4.7
Thanks
Ingvar
I’m not sure what you mean exactly. There are tutorials out there for running the GUI from from a different machine, but my instructions are for running the GUI directly on the Pi itself.
Pingback: Managed WordPress Hosting Bogota – Buy wordpress hosting
Hi, get anybody the UI running with 4.8.0?
My ui_error.log said “Could not load SWT library”, but I copied the swt.jar…
No, I managed to recover after earlier Crashplan forced updates borked the installation, but 4.8 seems to be a more comprehensive wipeout!
With Mel’s excellent instructions the engine can be made to work.
As you say, the UI/Desktop fails with an error as follows:
Exception in thread “main” java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
Can’t load library: /tmp/.cpswt/libswt-gtk-4427.so
Can’t load library: /tmp/.cpswt/libswt-gtk.so
no swt-gtk-4427 in java.library.path
no swt-gtk in java.library.path
/tmp/.cpswt/libswt-gtk-4427.so: /tmp/.cpswt/libswt-gtk-4427.so: cannot open shared object file: No such file or directory (Possible cause: can’t load IA 32-bit .so on a ARM-bit platform)
Crashplan seems to be unpacking an Intel architecture version of libswt-gtk.so into a dynamically-created directory /tmp/.cpswt. I can’t see where it’s getting it from or figure out how to prevent it. So I’m currently stumped as to getting the Desktop working natively on RPi.
As an alternative I tried following instructions to run headless, and use a linux-on-intel installation of Crashplan to control the RPi engine. That failed too. The desktop starts and connects to the RPi engine, but then the crashplan engine on RPi logged an error when I tried to authenticate:
Oct 02, 2016 1:52:22 PM com.google.common.util.concurrent.ServiceManager$ServiceListener failed
SEVERE: Service AuthorizedStorageService [FAILED] has failed in the STARTING state.
java.lang.UnsatisfiedLinkError: Unable to load library ‘c42archive’: Native library (linux-arm/libc42archive.so) not found in resource path ([file:/usr/local/crashplan/lib/com.backup42.desktop.jar, file:/usr/local/crashplan/lang/])
I’m stumped and pretty fed up with Code42’s careless disregard for ARM architecture. I know it’s not officially supported but how much effort would it really be for them to ship ARM versions of the few libraries concerned?
I cannot either start the engine… I mean, it starts, but it stops after a while with no errors logged.
I do not really know how to move on.
Without rebuilding to confirm, I’m going to have to guess that the most recent CP update has broken things in an entirely new way. If you took a backup just after getting things working (which I highly recommend), I would try restoring that, and I’d predict that once it stops working, you’d find that it has downloaded updates. I’m beginning to wonder whether it’s possible to set up a firewall rule to stop CP from auto-updating. That might do the trick.
Yes, same for me… Tried the headless client from Windows and Ubuntu, but in service log i found this:
[10.02.16 16:08:21.014 INFO MQ-UI-1 ackup42.service.ui.UIInfoUtility] Loaded address=0.0.0.0, port=4243, and token from location=/var/lib/crashplan/.ui_info
[10.02.16 16:08:21.015 INFO MQ-UI-1 backup42.service.ui.UIController] Received status request message with invalid token.
But the token is the right one, I checked it more times…
Going back to 4.7.0 can only help a short time… I think I need an other backup system in the next time… 😦
Yes, unfortunately CrashPlan is becoming increasingly difficult to work with. You can try the headless route, or you can stop running it on the Pi altogether, and using the Pi as nothing more than a network drive. You can create symbolic links in Windows, and use them to fool CrashPlan on your desktop computer into backing up to the Pi that way. I’ve done it before, but don’t have the exact instructions in front of me at the moment. The basic idea is to share the backups folder from the Pi, then create a symbolic link on Windows (or Mac) so that //RPHS/Backups appears to be at something like C:/Backups. When you run CrashPlan on your desktop, it normally won’t allow you to select network locations for a backup, but it WILL let you pick the symbolically linked folder, which is the same thing. Your backups will still end up on the Pi that way. This is great for desktops that are always connected to your home network, but laptops may not appreciate the symbolic link disappearing when you’re not at home, so I can’t really recommend it for anything portable. It would be nice if the folks at Code42 realized what a large number of people would like to run CP on non-Intel hardware, but since we’re using it to sidestep their subscription service, I can see where they’re not really motivated to do anything about it.
I’m among probably hundreds if not thousands of RPi Crashplan users who have received an email from Crashplan today telling them that their computer has not connected to the backup service for three days. Does anybody yet have a way of getting the Crashplan process back up and running on the Pi? I’ve tried replacing the libjtux.so and libmd5.so files as I have become accustomed to doing every time there’s an update, but alas this time no dice. I think I’m already running Java 8 (my symbolic link is to /usr/lib/jvm/jdk-8-oracle-arm-vfp-hflt).
I’d really appreciate any pointers that anybody has about how to get back up and running! Thanks.
Normally, I’d say re-patching the CP Engine and UI by re-copying the .so files and such. That no longer seems to be working. As of now, it looks like the latest CP update has killed all the CrashPis out there. I don’t yet have a solution, unfortunately. I’m going to try a from-scratch installation and see what happens, but I suspect it will work fine up until that first update applies itself, and then it’ll die again. Keep an eye on the comments section in case anyone figures it out. I’ll definitely update the post to point out the solution if so. My current though is to find a way to block CPs update process so that it’ll just stay put at the version that gets installed.
I managed to get 4.8.0 to start (but not run). In other words, the service is running and I had to do the JRE replacement, as well as the two files from the internet. I didn’t have to edit CrashPlanEngine at all.
In order to get the GUI patched, the copy command looks like this:
sudo cp /usr/lib/java/swt-gtk-3.8.2.jar /usr/local/crashplan/lib/org.eclipse.swt.gtk.linux.x86.jar
Now the service is staying up, the GUI is starting, but I can’t sign in.
So far, seeing in log/service.log.0 this line as the first indication of failures
ERROR 12836_AUTH-2 backup42.service.peer.Authorizer] AUTH:: Failed to authorize, authorized services failed to start., java.lang.IllegalStateException: Failed to start authorized services.
INFO 12836_AUTH-2 backup42.service.peer.Authorizer] AUTH:: Error = CPErrors.Global.SYSTEM : []
The UI will display “System error: If problem persists re-install CrashPlan”
Any suggestions are welcome!
After some digging, found this thread: https://crashplan.setepontos.com/forums/topic/sep-29-another-update-pushed-and-app-stopped-working/
At the comment #791 the user “imanzano” writes that we need, probably, a replacement for the file “libc42archive.so”. It, if I understood it correctly, is not compatible with ARM architecture. It must have been compiled to x86 or x64. I hope someone can help us what to do now…
And BTW I’m stuck at the same libc42* error. Waiting for someone to figure something out.
I followed this site and get chrashplan to run again https://n8henrie.com/2016/06/installing-crashplan-on-the-raspberry-pi-raspbian-jessie/
Installing it and getting it to work isn’t the hard part. It’s surviving the updates that’s the trick. I can get a CashPi up and running in no time, but it’ll always die a week later. Those updates were easy to deal with at first, but they’ve become more and more destructive, and cause the whole system to be untrustworthy over time.
Has anyone managed to get 4.8 going at all with this ” Failed to start authorized services.
at com.backup42.service.ClientServiceManager.authorize”?
Read this somewhere — how about symlinking the /usr/local/crashplan/upgrade/ directory to /dev/null or maybe just changing all the scripts in there to do nothing. Maybe that will stop the upgrade. I’ll try it with mine and see if I remain on 4.7
I thought I tried this, but it still managed to upgrade itself somehow. Maybe I missed something. Let us know how it goes.
We know that 4.7 works but breaks when it upgrades to 4.8. I’d be super happy to stick with 4.7 and disable the upgrades.
How to symlink directory to file?
I believe you’re looking for something like this:
sudo ln -s /usr/local/crashplan/upgrade /dev/null
Note: you may need a trailing slash after “upgrade”. Can anyone verify?
sudo ln -s /dev/null /usr/local/crashplan/upgrade
No trailing slash.
I started writing an upgrade script for installing crashplan on the raspberry pi (because doing the alterations by hand is very cumbersome) so for now the script is for installing CrashPlan 4.7 on the raspberry PI. It is based on https://n8henrie.com/2016/06/installing-crashplan-on-the-raspberry-pi-raspbian-jessie/ but it has the fixes for the GUI and I can add a solution for the upgrading problem if I find out how to solve that (trying the pointing to /dev/null for now). You can find the scripts on my github: http://github.com/sparky2708/Setup-CrashPlan-On-Raspberry-PI. IT’S STILL A WORK IN PROGRESS… I can update it to 4.8 later once someone has a method that works.
so I’ve been on 4.7 since 10/3 by re-pointing the “/usr/local/crashplan/upgrade” folder to /dev/null. I don’t know if this is too early to tell whether the upgrade is disabled but it’s been over a week and I’m still on the previous version of crashplan as of last night.
My system is still on 4.7, so it may be that CP just hasn’t gotten around to us yet. In any case, I just symlinked my upgrade dir to /dev/null as well.
But I’m wondering if delaying an upgrade will just delay the inevitable, especially if 4.8+ or later are not compatible with previous versions, as was the case fairly recently.
I had thought of trying that, or firewalling the code 42 site, but I had heard that the symlink route didn’t “take” for the others who tried it. If yours stays up, please let me know.
I also symlinked the upgrade dir to /dev/null and a couiple of days ago. So far 4.7 is still running and my backups are running.
Honestly, crash plan is starting to get on my nerves. Just went to the web restore and I get “error connecting to the backup server”. In other words, if I would have needed to restore something right now, i’d be screwed.
Has anyone tried idrive? They seem to support ARM architectures: https://www.idrive.com/cmd_steps
And appear cheaper than crashplan (well, i have less than 1TB need).
I’ve never tried using the “web restore” with my own CP server before, especially since the goal was to be running my own little CrashPlan universe independent of Code42. I would imagine there’s some firewall wrangling involved. I dug this up (https://support.code42.com/Administrator/3/Troubleshooting/Web_Restore_Troubleshooting_Tips), and it does look like certain ports would need to be opened in order for web restore to be able to pull stuff from your server. I may give this a try as well.
I too have grown weary of Crashplan having to be tweaked every time there is an update. This last one seems to be the final blow. I am currently giving rclone and Backblaze B2 a try…depending on the amount of data you need to backup, it could be a cheaper alternative. I have about 700GB and it is less than $5/month. It will take some (cronjob) configuring to setup snapshots, etc., but uploading is WAY faster for me. (I have 20mbps upload service and it seems to utilize most of that) Crashplan does not offer refunds for unused service anymore…which is a bit of a bummer.. 😦
Just wanted to update that as of today I am still on 4.7. Am keeping my fingers crossed this works as a permanent solution.
I’m going to make a post detailing two approaches to the CrashPlan update problem.
1) The /dev/null route, which seems to be working for you, despite what I’d heard from others.
2) A symlink from Windows to make the Pi’s backup folder appear local so that CrashPlan will agree to use it. This effectively eliminates CrashPlan on the Raspberry Pi, reducing the number of “moving parts” in the system.
Regarding 2): I have always set up a mount in /etc/fstab to bring the various network file shares I wish to be backed-up, under a single Linux directory. Crashplan doesn’t have any problem traversing filesystems… it sees all as if they were local files.
I was speaking specifically about Windows users. The Windows version of CrashPlan won’t let you choose a network location to store your backups, so you need to map a share to a folder or drive letter in order to trick CrashPlan into using it.
As per many comments, I lost the will to keep Crashplan running in Raspberry Pi, though I do find Crashplan an effective backup solution and didn’t want to give it up. I switched hardware instead, and bought an Up Board (http://www.up-board.org/) to replace our Pi general purpose server. It’s a low-power Intel Atom based single board computer, physically similar to Raspberry Pi, though rather a lot more expensive. Of course that means it runs Intel architecture versions of Linux (Debian, Ubuntu and others). Crashplan works fine on it. Ironically though, I have found that it is still running 4.7 after several weeks. I am wondering if perhaps Code 42 pulled the 4.8 release for Linux??
Shows listing for $90 before tax. At fist glance, at this price point I’d go for something like this: https://www.amazon.com/gp/product/B018FVOHCW/ (PowerLead Ptox P1030) that already comes in a case, with wifi, etc.
I am also in my second week of 4.7 running using the /dev/null technique.
I’m glad to hear that it’s still working. I’m definitely going to write this up, but with a huge caveat that, like everything else with CrashPlan, it may suddenly stop working one day without warning. I had looked into this approach before, and found that a number of people were saying it didn’t work for them. As for me, I just mapped a share on the server to a drive letter on Windows and let CrashPlan on Windows do all the work. It’s certainly fewer moving parts, but you lose that ability to serve as someone’s “backup buddy” when your main computer is off.
I found on CrashPlan’s support pages that the Windows OS will only allow it to use a network folder as a backup location if it’s installed just for the user and not for everyone. I uninstalled and reinstalled that way and my mapped network folders showed up. I couldn’t get symlinks to work when CrashPlan was installed for everyone. Thanks for all this Mel.
Yeah, that’s one of the approaches, but I think it only recently started supporting that. You used to have to do a lot of much nastier tricks to back up to a network location.
Just a note to say that linking the update folder to /dev/null is working for me (running for 10 days). I had to reinstall the remote GUI because it was stuck trying to update itself, but after that no problems. So the GUI is running 4.8 but the service on the raspberry pi is running 4.7.
I’ve also linked the update folder to /dev/null, and my Raspberry Pi is still on 4.7, taking backups from my Windows PCs running 4.8. So far so good, although I’m still worried that this solution is short-lived, as CP will, at some future point, require everything to upgrade to the same release (like 5.0) and that will finally blow away the RPIs
Just to add another data point. My CP was still working up until 27th of Oct. I did not try anything to disable updates.
Must have gotten the update after I shutdown the Pi to upgrade to a 3 TB harddrive.
I liked CrashPlan and will maybe change to Intel hardware instead. I was really just after a backup solution for my NAS. I fear I will have to reupload 1 TB of data though (i.e. 3.8 month of continuous upload).
Thanks Mel for your instructions, they have worked well.
Blocking the updates seems to be working for some folks so far. I had heard that it only worked temporarily, but a few commenters have kept theirs up and running for weeks now. I’m going to do a write-up on a couple different workarounds for the CrashPlan problems.
Mine is still up and running now almost a month now..
FWIW, I noticed today when bringing up the CP GUI (on the RPI), that it “hung” with an “updating” message on the splash screen. I killed the Desktop service, and launched the GUI again and if came up OK that time, except the CP screen showed a message that it failed to upgrade, and it would try again after an hour.. After checking the service log, I see “upgrade failure” messages, seemingly due to not being able to fine the upgrade file – which of course it can’t since I’ve linked the upgrade dir to /dev/null!
So that (upgrade -> /dev/null) seems to be working for me, although now CP appears to be in a mode that it retries the upgrade every hour. It’s been doing that for at least 7 hours by the time of this post. But that doesn’t seem to be preventing backups from occurring.
My Banana Pi Pro & Raspberry Pi 3 CrashPlan servers are not accepting files now. 😦
I was just thinking out-of-the-box here… Has anyone tried running CrashPlan through an x86 emulator on the raspberry pi? I see there are a few emulators out there…
I believe someone just commented on that very thing. I’m not sure I could really recommend it, though. The memory constraints are just too much. It might work, but it’ll be far from optimal. I think the symlinking of the update folder to /dev/null sounds like the best approach to getting it running on the Pi for now, at least until v4.7 gets so far behind that current installs on other systems won’t talk to it anymore. In the long term, I think NOT installing it on the Raspberry Pi at all is the most likely to work forever. You have to install it “just for me” on a Windows computer, and then map a drive, but at least you can back up to somewhere on the network now. Of course, this kinda kills the backup buddy functionality, but I kind of get the feeling no-one ever really used that anyway.
Doesn’t though this solution leave an opening to most modern ransmoware, which are capable to reach and encrypt mapped drives as well? I loved Crashplan because it allowed me full decoupling my PCs from the backup storage device.
I’m not sure it would be quite THAT safe. If a file gets encrypted on your main computer, and then CrashPlan backs that up, then the backed-up copy will be encrypted as well, so the ransomware will STILL end up getting to your backups, just in a more round-about way. The big difference would be whether your backup file itself could be encrypted, and yeah… that would be bad. My hope is that Code42 will see how popular running CrashPlan on the Pi is, and maybe put a little more effort into not killing our installations so much. I don’t expect an official Raspbian version of CP, but maybe just make the update process less stupid.
I thought I’d share this observation about what is happening when using the /dev/null approach:
10/12/16: Implemented the symlink of the upgrade dir to /dev/null/
10/27/16: Got first upgrade attempt to 4.8. CP tried three times, about 30 mins apart, on this day, but failed.
11/03/16 until now: After a gap of six days, CP starts to attempt upgrade again. This time, it has tried about every 30 mins. So far 251 more downloads and attempts to upgrade. That’s a lot of tries! Note: the GUI says “will try again in 1 hour”, but it’s really 30 mins.
CP has sent 3-day and 5-day status reports stating that the RPI system has been “unable to reach any backup destinations”. A regular status report show no backups in x days This is apparently being triggered by the continuous upgrade attempt failures since 11/03, as this is clearly the point in time it is basing the report’s time.
However, it has been backing up just fine during that time.
This RPI has two attached HDDs, one serving as an NAS, the other as the backup drive. The RPI manages backups from the NAS files, from all my local PCs, and from several remote “friend” computers. These are all working just fine, despite the CP reports to the contrary!
Ron B, Thanks for sharing this. I too am using the /dev/null technique and have received two notices this week saying my Pi has been unable to reach destinations. All indications from my end is that everything is working fine. Your comment confirms that.
Hi guys,
Would you please supply me with the step by step method you’ve used to prevent Crashplan auto-upgrade?
Because I have been testing for 3 hrs, reinstalling several times the version 4.7, and then using :
sudo ln -s /dev/null /usr/local/crashplan/upgrade
But every-single time, crashplan auto-upgrades to 4.8 as soon as I start it.
Obviously, I must be missing a trick
I suspect you may want to delete /usr/local/crashplan/upgrade before recreating is as a symlink
So in other words: sudo rm -fr /usr/local/crashplan/upgrade && sudo ln -s /dev/null /usr/local/crashplan/upgrade
I delete the upgrade dir and as root touch upgrade, then chmod 000
I concur with Audrey’s two steps:
sudo rm -r /usr/local/crashplan/upgrade
sudo ln -s /dev/null /usr/local/crashplan/upgrade
Has this setup gone up and stayed up for you? I’ve heard of a few approaches to the update problem, but they all seemed to have problems reported.
Yes, it’s been backing up and fully functional on version 4.7 since early October. The application displays an Upgrade Failed message at the top and I have received a couple of Backup Alert emails saying it is unable to reach a destination but when I login to CrashPlan via browser, it shows active backup information and valid files.
working for me here too! (for now…)
My CP ports on my Raspberry Pi changed again today, for the fourth time this year. They are now 4306/4307.
Previously, they had been: 4242.4243, 4260/4261, and then 4272/4273. Doesn’t seem to affect anything, other than the little “sanity check” powershell script I have running on one of my Windows PCs that pings the CP ports to make sure it is still running, and sends me an email if it isn’t.
Anyone else seeing their ports changing??
Otherwise, it’s still running 4.7.0 with the /dev/null trick, after 1045 attempts to auto upgrade to 4.8.0!
I’m not sure if this is related to the port changes you’ve noticed – I tried the /dev/null trick and it worked fine but I did find that my crashplan installation had issues connecting to the crashplan server. As it was a new crashplan installation, I needed to adopt my previous pi installation to avoid backup everything up again, but this wouldn’t work through the front end – just timed out. I then tried to manually apply a licence in the front end settings, but this couldn’t be validated either so I was left unable to backup to the crashplan servers, my preferred option.
Perhaps these issues could have been resolved if I had a little more time or understanding, but I don’t, and I’ve already put more time into maintaining this backup system than I’d hoped. I’ve given up for now and am in the scary scenario of knowing my files are not backed up as well as I would like. There was also some worry associated with knowing my backup system wasn’t officially supported by the chosen software!
Thanks for all of these tutorials though Mel, you provided me a perfect introduction to the pi and linux in general.
That’s kind of the point I got to with CrashPlan, too. It’s not that it can’t be coerced into working, it’s just that it takes too much hand-holding and monitoring to make sure it stays up. A backup solution is supposed to be automatic and reliable, and CrashPlan has stopped fulfilling that need. It could stop at any time, not tell you that it has done so, and leave your data unprotected. I just can’t trust it at this point. I’m really hoping that Code42 will consider NOT breaking it quite so often. I don’t see an incentive for them to go out of their way to make a special Raspberry version of it, after all, there’s no money in it for them to pay the programmers with and they need to eat too. Maybe they could create some kind of config switch that would turn off the auto-updates though. They know how popular it is to run CrashPlan on ARM devices like consumer NAS boxes or Raspberry Pis.
In the meantime, there’s a workaround in the newer version of the series. It basically involves backing up to a file share, which means that the Pi no longer plays an active role in the CrashPlan setup. It’s just there running a Samba share. This means that it’s not subject to Code42’s updates breaking stuff anymore. It’s a good enough plan for me at the moment, and hopefully it can get you back on track. If you set it up on a Pi that was already running CrashPlan, you may be able to “adopt” your existing backup files and save some time.
Just a tiny comment:
Between the line:
“Exit nano, saving the file (ctrl-x,y,enter)”
and the “Start CrashPlan” title, I would insert an instruction to “sudo reboot”
(Might be obvious to some but it wasn’t for me!)
Thanks to the author for a great tutorial.
Pingback: Raspberry Pi Home Server v2: Introduction | MelGrubb.ToBlog()
I finally got Crashplan Desktop to work on Crashplan 4.8.0. It looks like Crashplan has upgraded to SWT 4, renamed swt.jar, and uses loads the .jar file dynamically, depending on if the processor is x86_64 or x86.
Instead of running this:
sudo apt-get install libswt-gtk-3-java libswt-cairo-gtk-3-jni
sudo cp /usr/lib/java/swt-gtk-3.8.2.jar /usr/local/crashplan/lib/swt.jar
Run this:
sudo apt-get install libswt-gtk-4-java libswt-cairo-gtk-4-jni
sudo cp /usr/lib/java/swt-gtk-4.3.2.jar /usr/local/crashplan/lib/org.eclipse.swt.gtk.linux.x86.jar
Great find. Now if they could just add ARM to the list. I’ll give this a shot over the weekend and see what happens. I presume the auto updates will still break everything, but I’d love to find otherwise.
I have updated the article with the commands for the newer libraries. Thanks for sharing this. I love that this series has turned from a simple blog series into a community.
So does CrashPlan 4.8.0 now work on the raspberry pi with the change described by Jeremy Nauta? Or are we still stuck?
To the best of my knowledge, 4.8 will work, symlinking will prevent it from updating itself, and Jeremy’s suggestion will get the UI working again. You’ll still get emails complaining that nothing is being backed up though, and I expect that your desktop installation will eventually refuse to talk to the installation on the Pi once their versions are too far apart. That’s why I’m still not ready to recommend it again just yet. I’m preparing an updated article, but it’s going to be loaded with warnings about his hands-on this part can be.
Mel, I’m a bit confused. I’m glad that the /dev/null trick is working for everyone, it was a shot in the dark but I’m glad it worked out.
1. Do we have steps to get the 4.8 server piece and desktop piece running (I haven’t looked at it in awhile but I remember we got stuck on a jar file that was supplied by CrashPlan that we couldn’t get for ARM) and the CrashPlan server wouldn’t start?
2. Why would I still get e-mails that nothing is getting backed up – I thought 4.8 is the latest version?
Check out Jeremy Nauta’s comment just above. It sounds like he’s discovered the proper versions of the libraries that 4.8 needs to get up and running. I’ve updated the article to use the newer commands Jeremy identified. As for the constant emails telling you nothing’s backed up, I’m guessing that’s just poor error handling somewhere within CrashPlan, and that behavior could change in the future.
I decided to jump to 4.8. All goes well until I try to log in. After a long pause I get “System error: If problem persists re-install CrashPlan.” I tried re-installing again but the same result. Any ideas?
BTW I see this in the engine_error.log – Exception in thread “AuthorizedStorageService STARTING” java.lang.NoClassDefFoundError: class com.code42.archive.jna.Archive42JNA
I tried upgrading to 4.8 but no-go on the login, so I went back to 4.7. Still running OK with the upgrade -> /dev/null directory redirection.
I have not tried an upgrade to 4.8. I did try an uninstall/purge and a clean install of 4.8, but I wasn’t happy with it at the time. I’ll be looking into it more, but not right away. I just don’t have a lot of confidence that anything I find acceptable we’ll keep working long-term at this point.
I’m afraid I have given up on using Crashplan on the Raspberry Pi. I haven’t given up on using my RP for remote backups though. I have set up a scheme using Syncthing, which is really presented as a file syncing tool. But you can set up one side as a Master, i.e., it never gets written to by the partner, and you can set up how to save deleted/modified files on the destination. So I have my home system directories set up as Masters and I have the remote RP directories set up to sync with these and to save old files for 30 days (like Crashplan I believe). Had this working for a few weeks now. Only downside I see at the moment is that to recover a file I have to go fetch the RP (at my daughter’s house in my case).
I haven’t completely given up on it just yet, but I’m not really recommending it anymore. There’s just too much hand-holding involved for me to entrust it with the safety of my backups. I’m backing up to a simple file share which is still hosted on a Raspberry Pi that lives in my detached garage. It’s still off-site, but I’d much rather have a full working CrashPlan instance. I’m waiting a little while longer to see if anything new surfaces, and then I’m going to revisit the article, but with a pretty pessimistic warning at the top. Warning: This thing could stop working at any time and without any notice.
I know this is a “raspberry PI” thread, but given the issues we’ve had with this, has anyone explored using an alternative that might be compatible with CrashPLan, but still be in the realm of “small computers”?
The main problem isn’t Linux, it’s the ARM processor. CrashPlan just doesn’t support them. There are small x86 computers out there, and they would be more directly supported, but nowhere as cheap as a Pi. An older leftover PC would do the trick. I used to use a outdated laptop, but their fans aren’t always up to the task of running 24/7. Mine got noisier and noisier until I eventually moved to the Pi. I’m okay with backing up to a mapped drive for now, but I am looking at CrashPlan on the Pi again soon.
Interesting find:
I went through all the steps (all today) and got CrashPlan on the pi. I opened it up for the first time and the UI came up fine, prompting me to log in. After logging in with my username and password, a “System error: If problem persists re-install CrashPlan” error message came up.Despite this, “raspberrypi” showed up on my other computers logged in under the same account, but it comes up as inactive. I even tried to hook up with the pi using CrashPlan on another computer, but it was unsuccessful. I don’t know if this gives you any info you don’t already have, but I thought I’d post anyway.
So 4.8 doesn’t work on the pi?
It kinda works, but it’s not happy about it. That’s why I’m not recommending this approach right now.
Hi,
I have been running the 4.7 on my R-Pi since Nov 2016. Any news on the topic? or is it really dead and sort of unlikely that we’ll find a solution?
Cheers to everyone,
Martin
I take it you’ve “black holed” the updates to dev/null, right? I was hesitant to recommend this because as soon as I do, the desktop versions well update and deprecate 4.7. Murphy’s law is my super power. It’s stupid, but it’s the only super power I have. I’m starting to think that it might be the only approach for now though.
Hello Mel,
Yes I have dev/null the pointers. This way, I keep receiving 2 types of warning :
1 – in the GUI, to tell me that the upgrade failed (That is normal… this is exactly what I want to prevent)
2 – by email, every two other day, I receive an email to tell me that my daily backup has failed (this is a stupid email that I don’t understand… because after having double-checked, the backup has run and is indeed successful).
So this is what I am living with right now. I got used to ignore the email. It just that it feels like a temporary fix becoming permanent.
cheers,
Martin
This week I gave up on the RaspberryPi approach altogether. I ordered a UDOO x86 board that just came out for public purchase. It’s more expensive (around $150), but it’s basically a normal X86 laptop that’s silent, low power, and roughly the same size as a RaspberryPi. Now I’ve got all the RAM I need and backups can encrypt at normal rates.
I’ve got crashplan 4.7 running for about a year now on osmc, since the 4.8 update with the dev/null solution. This is still working great, don’t have any problems with it. I just had to configure to automatically restart the crashplan service (systemd) since it crashes regularly (out of memory). I’m still very happy with it!
Hello everybody,
I would like to amend that I have found a very competitive alternative to the Raspi CrasPlan server: Borg Backup. Using Borg Backup, the workflow when coming from CrasPlan is quite the same. It took me about one day to set up everything, including offsite backup. Only the seeding of the initial backup is a little bit time consuming.
Cheers, Thomas