Installing CrashPlan on a PogoPlug Pro

Send to Kindle

There are critical updates embedded in this post, added on 9/3/2011, all preceded with Update:. You can apply those instructions separately if you’ve already completed the rest of this installation. Updates will be marked with End Update to allow for multi-paragraph updates. I will strike-through the parts that were replaced, so that you can safely ignore them if you’re going through this guide for the first time.

PogoPlug Pro is an amazing device (coupled with an amazing service). CrashPlan is an amazing piece of software (and also provides a fee-based amazing service). I’ve had both for a while and think very highly of them.

To solve a number of my own problems (not caused by either service!), I decided to investigate marrying them (the PogoPlug device, with the CrashPlan software). To be slightly more accurate, I wanted the device to perform an additional function (beyond backups). I wanted it to be my primary DLNA server.

Caution: none of what follows is supported by either company. You will be voiding your PogoPlug warranty and CrashPlan does not support this configuration of their Linux software. Proceed at your own risk!

My primary reason for installing CrashPlan on this device is to compensate for the pathetic upload speed provided by Time Warner, all of 485Kbps, shared with my wife, for normal Internet use, VoIP calls and backups. In other words, not really a useful real-time backup solution. Since we are often at other, very high-speed locations, I still believe that paying for the CrashPlan online backup service is the way to go (and gives me great comfort), but when I’m home, I wanted a local solution (that didn’t involve plugging in a hard drive to my laptop).

Since I was able to do this, successfully, the instructions can be found on the Net. Since it took me way longer to find the various pieces, let alone get them to work, than I felt it should have, I’m writing this (for myself, as well as for others who might give up more easily than I did). None of the credit goes to me, I’m just collecting the wisdom of others in one place, hopefully an easy one to find.

Update: All sections marked Update: that apply to Java and udev were courtesy of Ankit Mohan. Ankit used this guide to get CrashPlan running on his PogoPlug, then dug in a lot more than I did to solve the problems I described. I am indebted to him. End Update.

There are a number of Linux distributions available for the PogoPlug Pro (an ARM-based device). I chose Arch Linux because it was the most prominent one I found and because it has a very good reputation independent of the PogoPlug. The specific ARM implementation has it’s own site, which is where I started my odyssey.

After reading the overview on that page, I clicked on the Installation tab. The instructions there are extremely clear. The first time I followed them, the formatting of my external drive failed. I ended up formatting the drive while it was connected to a laptop running Linux, but all of the other instructions on that page worked. I will repeat them here, so that anyone who doesn’t want to link off of this page can simply follow all the way through.

You have to register your PogoPlug at This is required, even though we will shortly be disabling the service, since this is the only way to get SSH access to the device. You will be able to reverse the process, returning the device to a full PogoPlug in the future, should you desire that, but it’s not a dual-boot situation where you decide which version you want it to be.

Once you’ve enabled SSH on the device, you can set your own password. The username will be root. The default password for a PogoPlug Pro is ceadmin (as noted, you can change it via the website, or once you log in, with the passwd command. Change it!

One of the steps that they don’t cover is discovering the IP address of your PogoPlug, so that you can SSH to it. In a home environment, this is relatively easy (for the geeks among us). You login to your router, look at the list of attached devices and easily spot it.

I’m installing the software on a second device as I type along. I’m in an office environment and don’t have access to the router. There are hundreds of devices in the office. I had to write down the MAC address of the PogoPlug, go over to a system administrator and ask him to search the DHCP log files for that MAC address. He did and I found out the address that was assigned to it. Whew.

I successfully logged into the device, just to make sure it worked, while it was still an official PogoPlug. That step was optional, but comforting. Since the next step is to power down the device (which you can safely do by just pulling the power cord, especially if you have no hard drives attached yet), since I’m logged in as root, I typed /sbin/halt instead, to be a little safer. Wait 60 seconds (for added safety), then pull the power cord.

We’re going to install Arch Linux on an external drive. The only thing that will be changed on the PogoPlug itself is the boot sector, which will now point to the external drive (that’s what would need to be reversed to restore the PogoPlug functionality).

With the PogoPlug powered down, attach only the drive that you intend to install Arch Linux on. This way there will be no confusion or errors. Later on, if you want multiple drives attached (for backups and/or media files) it will be easy to add them. I am using a 2TB Fantom Drives to do my install.

Once the drive is attached (and turned on), plug the power cord back into the PogoPlug and wait for it to boot. Then SSH back on to it (the root password will be what you set it to, or ceadmin if you didn’t change it). The box is still running the PogoPlug software, with your drive attached to it.

Type: killall hbwd

That will stop the PogoPlug software from running on the box. We don’t want it to interfere with the installation of Arch Linux. You might have to wait a bit for the service to stop. If you want to check, type the following:

ps | grep hb

The only result should your grep process. Then, you can type:

/sbin/fdisk –l

The last line of output should start with /dev/sda1. That means your disk drive was found and has a partition on it (it’s likely formatted already). We are about to erase everything on the disk, so be absolutely sure that you want to continue with this adventure before doing that! If you’re ready, type:

/sbin/fdisk /dev/sda

That will bring up the fdisk program on the entire drive (sda as opposed to sda1 which is the first partition). You will now have a prompt that is directly from the fdisk program. We will type a number of one character commands. Right after you type the character and press enter, fdisk will go off and do what you asked it to.

Type: o

That will clear the partition table so that the disk will become unusable (for the moment). As you can see from the messages, nothing has been committed in stone as yet (very soon). This has modified an in-memory copy of the partition table.

Type: p (to verify the above, that there are now no partitions)

Type: n (press Enter, this will create a new partition)

Type: p (to make it a Primary partition. At this point, I’ll stop saying “Press Enter”, but you still have to!)

Type: 1 (to make this partition )

At the next two prompts (First and Last cylinders), just Press Enter to accept the defaults (you are making the entire disk available as the first and only partition).

Now comes the destructive part. This will actually wipe out any data you had on the disk (but still doesn’t modify the PogoPlug in any way!).

Type: w (this writes the partition table back out to the disk)

You are now back at the command line. If you’re a paranoid type (or just careful), you can verify that things worked by repeating the fdisk command and listing out the partition table, all in one shot:

/sbin/fdisk –l

This is the output on my system:

Device Boot      Start         End      Blocks  Id System
/dev/sda1               1      243201  1953512001  83 Linux

2TB, in one partition, marked for use by a Linux system. Now we need to actually create the filesystem, which in our case will be an ext3 one. This will require downloading some commands that will need to be executed. Here are the steps:

Type: sync (to flush any filesystem changes)

Type: cd /tmp (to change to a temporary, writable working directory)

Type: wget (to retrieve the program mke2fs)

Type: chmod 755 mke2fs (to make it executable)

Type: ./mke2fs -j /dev/sda1 (the leading dot is critical. This will format the partition to an ext3 filesystem)

The above command can take quite a while, depending on the size of your external drive. This is the command that failed for me on my first PogoPlug, so I ended up having to detach the drive, connect it to a Linux laptop, perform the same exact command as above (which was already available, I didn’t need the wget part) and then reattach the drive to the PogoPlug.

Note: it failed for me again. I was able to format it using the built-in /sbin/mkfs.ext2 command (passing in the “-j” flag), but I didn’t trust that it was building a true ext3 filesystem (ext2 + journal). So, I disconnected the drive from the PogoPlug, attached it to a VirtualBox VM on my Win7 laptop, and formatted it there as a real ext3. Took forever, but it worked.

Whether the mke2fs command worked for you or whether you had to format the drive separately, like I had to on two separate installations, you’re now ready to install Arch Linux on the external drive. You should already (still) be in /tmp, but to make sure, feel free to type: cd /tmp

Type: wget (that retrieves the install script)

Type: chmod 755 (this makes the script executable)

Type: ./ (this starts the script, which will send lots of messages to your terminal window. It also downloads the root filesystem image, which is roughly 129MB, so it can take a while if you don’t have a fast network connection.)

When it’s finally done (took between 5-10 minutes on a very high speed connection in the office), the output should look like this if it succeeded (at the very end):

## Looks good!
# Sync …
# Unmount
# Reboot to enter into Arch Linux ARM

Note the looks good! and then the instructions to reboot. That’s what we’re going to do next.

Type: /sbin/reboot (cross fingers!) Winking smile

This will immediately disconnect you from the terminal window you were in. You need to wait a few minutes for the orderly shutdown of the PogoPlug, followed by the booting up of Arch Linux ARM. You can watch the lights on your external drive to see when there is activity on it, indicating that the booting has begun. When the light settles down, the boot is complete.

We’re ready to log back in (this time to the new operating system), and the password has been changed to a new default one. The user is still root, but now so is the password (root), which you should change right away with the passwd command. It’s quite possible that the IP address of the box has changed during the reboot, so please verify the new (or existing) one, before SSH’ing back on.

If the IP address did not change, then you might have to remove the old key associated with it, or ssh might refuse to connect, thinking it’s a security violation. If you get the same IP address again, you may need to run the following command first (on your local machine, the one you are SSH’ing from):

Type: ssh-keygen -R # (using your device’s IP, which won’t likely be

The following First Steps page on the Arch Linux ARM Wiki explains the above, and gives you a number of other useful tips. I followed them religiously the first time through, but I changed the order a bit this time around and it saved a bit of typing (or I think it did).

Instead of going through the above, this time I updated all of the packages right away. I believe that it installed openntpd and updated the /etc/rc.conf file (one of the first steps that I performed manually the last time). You can do what I did, then check if openntpd is installed and running.

Type: pacman –Scc (clear out old packages. I said YES to the first, and NO to remove unused repositories)

Type: pacman –Syu (this will do a large update, first syncing the repositories, then updating all packages)

Now comes a crazy part. I say crazy because by the time you read this, perhaps the maintainers of Arch Linux ARM will have updated the repositories and this will no longer be necessary. Then people will think I’m an idiot, so be it, I’m putting it in here because it can’t hurt!

Type: pacman –Sy udev-compat (to fix a problem with udev + syslog-ng taking up 100% of your CPU)

The 100% cpu problem might be happening as you read this (if you’ve done the previous steps already). It might be filling up your disk in /var/log as well. We can check that in a minute (here’s the thread that helped me: there’s a typo in that thread, “sleep3” should be “sleep 3”), but first, let’s do a few more things and then reboot.

Update: Type pacman -Sfy udev-oxnas udev-automount (this fixes the udev problem noted above, now struck-through. I added the f option to pacman to force the removal of the bad udev, or udev-compat that you installed if you’ve already completed these instructions. You will have to say Y to the prompt to remove udev, which defaults to N.) End Update.

Let’s create a swapfile:

Type: dd if=/dev/zero of=/swapfile.img bs=1M count=1024 #for a 512MB swapfile, use count=512

Type: mkswap /swapfile.img (to turn the file we just created into a valid swapfile)

Type: swapon /swapfile.img (to see whether you get any errors, you shouldn’t)

Now we’ll edit /etc/rc.local (use your favorite editor, I use “vi”, you might prefer “nano”) to add exactly four one lines after the comments:

swapon /swapfile.img
kill $(pidof udevd)
sleep 3
udevd &

The first line turns the swap on after each reboot. The next three lines kill the bad udev (even after updating the udev-compat the process sometimes misbehaves at boot), then sleeps for three seconds and restarts udev, which makes it seem to behave correctly so far.

OK, time to reboot and see if we have a stable system:

Type: sync (flushes the memory to disk)

Type: reboot (you should lose your ssh connection right away)

Wait until the disk activity settles down a bit, then ssh back in.

Type: top (to see what processes are running. If udev and/or syslog-ng are at the top, something isn’t good)

Type: q (to exit top, whenever you’re done looking around)

You can follow any of the additional instructions for setting up a user, adding sudo, changing TimeZone settings, etc. All are linked from the First Steps above.

Since the reason I did this was to install DLNA, I’ll cover that first (it’s really short), then we’ll move on to the heavier CrashPlan setup. Skip the next few lines if you have no interest in DLNA.

Type: pacman -Sy minidlna jack (this names two packages, but will install something closer to 44, with dependencies)

You should edit the file /etc/minidlna.conf and change any variables (where the files are stored, where to store the DB, what you want to call your DLNA server, etc.). You can read the Wiki page (linked above) to see the more important entries.

Then add the word minidlna at the end of the DAEMONS= line, which should be at the bottom of the /etc/rc.conf file. This will auto-start the DLNA server every time the PogoPlug is booted. To start it right now, type: /etc/rc.d/minidlna start

Update: I discovered two things. 1) Many devices, e.g. Google TV and Sony Bravia TV, don’t show any of the files with a filetype of FLV. It turns out that if you simply rename the filetype to AVI (probably others), the files play fine (assuming they were encoded with H.264). 2) After you populate your media directory, run the following command and wait patiently: minidlna -R to force a build of the database. You probably want to kill all minidlna processes when this is done and start it again (minidlna alone on the command line is good enough). You can tail the minidlna.log file (in your database directory) to know when the database rebuild is done. End Update.

Whew. Finally ready for the very tricky and long installation of CrashPlan. This is not for the faint of heart, nor is it in any way supported by CrashPlan. It works for me (and obviously others), but you’ll have to be the judge as to whether the hassle is worth it for you.

Let’s start with crediting the place that got me unstuck, the CrashPlan support forums! Kudos to CrashPlan for allowing this type of discussion on their forums, even though they don’t support this configuration. Here’s the thread, but all of the interesting bits are in the long comment by Torbjorn. It was really hard for me to find, because I was searching for the word PogoPlug. This solved the problem for Sheeva (the baseline of the Pogo), but it’s not quite identical.

Type: pacman –Sy openjdk6 cpio (we need to get a working Java installed and CrashPlan will require the cpio package separately)

The next step (according to Torbjorn) is to download an ancient (2005) libjtux source package, apply a patch and compile it. He supplies a pointer to the source (amazingly, still available) and the patch file is available as an attachment to his comment. You can grab both from the the thread linked above. If you do, you will likely have to download a bunch of development packages (using pacman), starting with gcc.

Instead, I will attach the completed that I built (following those instructions), to save you time, effort and potential errors. I also just grabbed it from my first build and applied it to my second, for the same reasons.

Now we need to install CrashPlan itself by heading to the download page for Linux. I right-clicked on the download button (currently version 3.0.3, but the software auto-updates after the first install). I copied the link location. Back on the PogoPlug:

Type: wget (that should work, but starting at the http part, just paste in the link you copied if it’s newer than 3.0.3)

Type: cd /tmp

Type: tar –xzf WHEREVER_YOU_DOWNLOADED_THE_CRASHPLAN_FILE (which could be /tmp to simplify matters)

Type: cd CrashPlan-install

Type: ./ (all of the defaults seem reasonable to me, though I did put my archives in another directory. You will need to page through the license file with the space bar and accept that as well. The init scripts on Arch are in /etc/rc.d, which is the other thing I changed from the default.)

When this is done, it will report that it has successfully started the CrashPlan service. It did not. That’s because we haven’t yet replaced the that comes with CrashPlan. The problem is that it was compiled with an Intel i386 architecture.

Type: cd /usr/local/crashplan

Type: mv (no real need to save it, other than to memorialize the changes we’re making)

Type: cp WHERE_YOU_DOWNLOADED/ . (this copies my version from wherever you downloaded it, or you can right click my link above, and wget directly from my website to this directory)

Torjborn mentions editing a file to add jna.jar to it. I didn’t need to do that, and the directory he references doesn’t exist. I think it’s from a different installation of Java (for the original Sheeva) and not necessary when using the openjdk6 package.

Update: This next part solves the timing delays, apparently among a number of other issues that I wasn’t even aware of! Once again, thanks to Ankit for figuring this all out.

You will need the nss package installed. Mine was there after the major update above. If you don’t have it installed, type: pacman -Sy nss

The file that’s missing from openjdk, which is causing all of the problems with CrashPlan, is It’s part of the jna package (Java Native Access). You’ll have to download a Debian package and extract the file.

Select a location near you from this link: In the US, I chose this link directly:

Assuming you downloaded that file to /tmp, here are the commands to extract the file we’re interested in:

Type: cd /tmp

Type: ar vx libjna-java_3.2.7-4_armel.deb (this will extract three files, one of which contains the file we’re interested in)

Type: tar -xzf data.tar.gz (this will unpack the tar file, creating a series of directories in /tmp/usr)

First we need to create the target directory for this. Since mkdirs (make nested directories) doesn’t exist by default, we’ll execute a number of consecutive mkdir commands. Hint: you can hit up-arrow after each command and just append the next directory name in the series of mkdir commands.

Type: cd /usr/local/crashplan/lib

Type: mkdir com

Type: mkdir com/sun

Type: mkdir com/sun/jna

Type: mkdir com/sun/jna/linux-arm

Type: cp /tmp/usr/lib/jni/ com/sun/jna/linux-arm/ (now we have the file in the correct directory)

Type: cp -p jna-3.2.5.jar jna-3.2.5.jar-ORIGINAL (this isn’t strictly necessary. Aside from documenting our change, it allows us to recover from errors more easily)

Type: jar uf jna-3.2.5.jar com/sun/jna/linux-arm/ (this is the critical step, inserting the library into the jar file that CrashPlan uses. I’m not sure the com/sun/jna/linux-arm directory creation is necessary, but better safe than sorry)

It seems that in addition to solving the timing issues (long delays in starting up), this actually dispatches (duh) maintenance tasks like pruning, synchronizing, etc. It’s all good, but there is a side-effect (well worth it!) that the Java process now takes up a significant amount of CPU, even when backups aren’t active, since it appears to actively maintain the system. Previously, Java would consume 0% of the cpu when it wasn’t backing up.

End Update.

We’re ready to start CrashPlan (at least to see if it comes up and stays up). We can do it by hand, but I am going to add it to the DAEMONS list at the end of /etc/rc.conf (like we did with minidlna) and reboot the machine to ensure that it comes up on it’s own. The daemon name to add right after minidlna is crashplan (lower case).

Type: /sbin/reboot

If you did everything above correctly, when you log back in, there should be a java process running, with CrashPlan as the application. It can a few minutes to completely initialize. In that case, we’re done, right? Wrong! CrashPlan is indeed sitting there, waiting to go to work, but it needs to be configured to allow your machine(s) to start backing up to it. Under normal circumstances, this would be trivial to do, but since the PogoPlug is a headless server, we have to jump through a few final hoops.

Once again, CrashPlan support to the rescue (again, for a completely unsupported feature). If you want to understand the details, or are enough of a techy to prefer the theory, I urge you to just read the CrashPlan document and skip to the final section of this post. If you want fewer steps (and warnings) to follow, I’ll give you the bare necessary steps here.

They key is that on every machine that has CrashPlan installed, there are two programs: 1) the server that does all the work and 2) the GUI (graphical user interface) that connects to the server when launched, and allows you to configure and monitor the server process. On the PogoPlug, we only have . The good news is that the GUI speaks to the server over the network. By default, that network is local to the machine that the server is running on, but with some ssh magic (and a little editing of a configuration file), we can make that a remote connection.

All of the work is going to be done on your desktop or laptop, where you already (presumably) have CrashPlan running. This is likely the machine that you want to backup to the PogoPlug. Let’s just call it laptop so that it’s obvious it isn’t the PogoPlug.

On laptop, make sure that the CrashPlan GUI isn’t running. If it is, exit the application. Find the conf directory associated with CrashPlan on your system. On my Windows 7 x64 machine, it’s this directory: “c:\Program Files\CrashPlan\conf”. In that directory is a file called Edit that file. The following line is in that file: “#serviecPort=4243”. This line is commented (#), because 4243 is the default value. You can leave that line commented and add a line below it:


(You could also remove the comment and replace 4243 with 4200, but I recommend adding a new line.)

Save the file to disk. While still on laptop, open a terminal window and execute the following SSH command (if you’re using Putty to do this on Windows, rather than cygwin, I recommend reading the post back on the CrashPlan site).

ssh -L 4200:localhost:4243 user@

In the above command, substitute your username (or root) where I put in “user” and the IP address of your PogoPlug where I put in the “”. This command makes port 4200 on laptop magically redirect to port 4243 on the PogoPlug, which is where the CrashPlan server is listening by default already.

Now launch the CrashPlan GUI on laptop by double-clicking the icon (on Windows, it’s probably in your system tray). You should see a request to create a new CrashPlan account (free) or log in to an existing one. Since I already have one (and presumably you do too), just put in your email address and password. It took quite a while for it to log in and download the configuration, but it worked. I think when I first tried it on my first PogoPlug it actually timed out, but worked the second time.

Once that’s done, you can exit the GUI, as all of the defaults are exactly what we want/need. The only exception to that is if you want to let others (that aren’t part of your account) backup to your PogoPlug. Then you will need to write down the CODE to enable that (it’s toward the bottom of the front page on the GUI and also on a Settings tab).

You can now exit from the ssh session that was started above (Type: exit or hit Ctrl-d in that terminal window).

Once the GUI is shut down, edit the file again and delete the extra line we added with “servicePort=4200” (or place the comment “#” back in front of it). Save the file.

Launch the GUI again. This time it will connect to the local CrashPlan server on laptop. Now click on Destinations (bottom left entry on the left-hand navigation). Then click on the icon labeled Computers in the center (the PogoPlug is a real computer!). Whatever you called your device should be in your list, no code necessary, since you should have used the same account on both machines. If you didn’t name your device, then Arch Linux ARM defaults your host name to alarm (get it? ArchLinuxARM?).

Now you’re truly done. If you have a large amount to backup, it could take a couple of days to complete the first backup, even though it’s on a LAN. It will also alternate between the various backup locations (including CrashPlan Central), which is one of the reasons it will be somewhat slowed down.

For reasons I can’t explain, it can take a very long time to start the initial backup, even if you pause the other locations. The GUI correctly communicates with the server instantly, since I can see the correct directory created on the PogoPlug, but the destination still shows up as unavailable for some period of time. Eventually, it gets going, and appears to be quite reliable from that point on.

Update: I struck out the previous paragraph since I’m hopeful that with the addition of to the jna jar file, you won’t experience the long startup delay.

cp -p jna-3.2.5.jar jna-3.2.5.jar-ORIGINAL



, , ,



65 responses to “Installing CrashPlan on a PogoPlug Pro”

  1. aff Avatar

    Thanks for the write-up.  Got Crashplan working on my Pogoplug v2 thanks to this.

  2.  Avatar

    Excellent, thanks for letting me know! I’ve been told that the reason for the long delays before the backups begin has to do with my choice of Java VM, but I was unsuccessful in getting any others to run. If I solve that problem, I’ll update this post or write another.

  3. Andre Aguiar Avatar

    This is good news.  Brother just got me a Pogoplug (pink one) for my birthday. Can’t wait to set it up now

  4.  Avatar

    Cool gift! 🙂

  5. Andre Aguiar Avatar
    Andre Aguiar

    Is it possible to still use the Pogo software to interact with additional drives?  I got this working on the pink model and I can connect to the headless Crashplan client but when accessing the pogo plug via the web gui it doesn’t recognize any drives.  I would love to have Crashplan work along with using Pogoplugs cloud solution with this.

  6.  Avatar

    That would indeed be the ultimate goal, but I didn’t even contemplate trying it, because I didn’t see a hint of anyone saying that the distro that Pogo uses is complete enough to get Java running (which would be the minimum requirement, perhaps much more software would be necessary).

    Still, it’s a great idea, because the Pogo software/service itself is a wonderful thing to have. If I buy a third one (both of my current ones are now basically CrashPlan + miniDLNA servers), I might try to get CP running without overriding the Pogo software.

    Thanks for the idea and obviously let me know if you discover a way to do this before I do. 🙂

  7. WarheadsSE Avatar

    Don’t supposed you might like to make this into an official community guide on the ArchLinuxARM community forum?

  8.  Avatar

    Happy to have the content appear there. Is there something special I need to do, or do I just need permission for someone to link to this or copy the instructions?

  9. epsilon Avatar

    aaah, finally someone who has the cure for that udev/syslog-ng problem!
    thanks a lot!! 

  10.  Avatar

    Glad you found this. It was driving me crazy too, since the log was filling up fast, even on a 2TB drive.

  11. Cinony Avatar

    Saw i noticed a sweet deal for the pro, 30 bucks!  got me thinking about crashplan since i use it to backup files over to my brothers house.. So search and found your great write up… I have to buy 2 of these now…

  12.  Avatar

    I’m running two of these as CrashPlan servers already, but I saw that deal too, and grabbed 4 more (seriously!). One of them might end up being yet another CrashPlan server, but the others will probably find some other general Linux usage, perhaps one even remaining a real PogoPlug. 🙂

  13. guest Avatar

    Thanks for the detailed tutorial. I just ordered a pogoplug pro, and am interested in trying out crashplan on it. I have a couple of questions. Would this work on a “pro”, given all its limitations (older kernel, etc)? Also, how has your experience been with crashplan on the pogo? Any unexpected errors/crashes/slowdowns?

  14. Ankitmohan Avatar

    doh… looked at the title of the post again, looks like it does work on the pro!!

  15.  Avatar


    It’s running _great_ on the Pro. The only consistent “issue” (and I hesitate to even call it that) is that there can be long lags before the client will reconnect to the server after finishing a backup.

    The lag can be a few hours, up to a day! That’s marginally annoying, but it always starts back up, with no intervention, and always completes the backups, so it’s still totally reliable.

    This would be a problem if your data was so critical that when you changed a file, if it wasn’t backed up 15 minutes later, you could be screwed, then you might need to dig further/hard than I did.

    I was told that the problem likely stems from the version of Java that I’m using. That might be true, but I spent hours (quite a number of them!) trying to get other JVM’s to work, and could not. So, I’m happy with the ease of installing this one, and I’ll suffer the (mostly short) delays in connecting to the server.

    Good luck!

  16. guest Avatar

    So I got my pogoplug, installed arch, and followed your instructions to get crashplan to work. When I start the service (/etc/rc.d/crashplan start), I get a process called “java”. On examining top, this process takes 100% cpu time. Unfortunately I am unable to connect to port 4243. Do I need to wait a while before the crashplan server starts working on the plug? Is this related to your lag? I waited about 10 minutes but the java process was still at 100% and there was nothing on port 4243.

  17.  Avatar

    Hmmm. It definitely takes Java a while the first time it starts up. 10 minutes seems long enough, but I honestly don’t recall how long it took for me. Subsequent startups (like after a reboot) don’t seem to take quite as long, so perhaps the class files were compiled and cached, etc.).

    Java process will take nearly 0 CPU once it’s settled, if it’s not backing up actively.

    I assume that you fixed udev-compat issue (you must have, or 100% of the cpu would be taken up by that process instead). You would want/need to reboot after that. I also assume you fully updated the system with “pacman -Syu”.

    I’m not really an expert on this, mostly because I’ve luckily not had to be (it’s just working well for me, including the minidlna stuff!). But, if I were in your shoes, my next step would be to kill the Java process (actually: /etc/rc.d/crashplan stop), make sure nothing else is soaking the system, and when load was down to 0, I’d manually start the CrashPlan service again with:

    /etc/rc.d/crashplan start

    If you continue to have problems, feel free to comment here and I’ll try to help in any way that I can. Good luck! 🙂

  18. CinoNY Avatar

    just tried the new steps, connected right away and started the backup!! Thanks man

  19. Cinony Avatar

    thinking i should had brought more then 2 myself now…lol.. Have you found any how-to to take it apart without breaking the plastic? I want access to the sata port

  20.  Avatar

    My pleasure, even though I can’t take credit for the fix, just for documenting it publicly. 🙂

    It’s working fantastically for me too!

  21.  Avatar

    I doubt I’ll crack one of my new ones open to find out, but it’s actually a pretty good idea! 🙂

  22.  Avatar

    In case you’re subscribed to the comments, there’s now an update above with a much cleaner way to solve the udev problem.

  23.  Avatar

    Thanks for the thorough tutorial

    Do you know if the Pogoplug Pro or Pogoplug pink handles Crashplan better?

    I wonder if the Pro’s Dual Core 700ghz is faster the Pink’s single 1.2 ghz processor. Plus the Pink has twice as much RAM.

    Does Crashplan on the Pogoplug utilize multiple cores?

    I missed the Pogoplug Pro deal, but see the Pink (POGOE02) for $40.

  24.  Avatar

    Excellent questions. I hadn’t thought about it until this week, when Ankit (the guy who solved the Java timing problem) mentioned the Pink deals to me as well.

    If Java uses both cores, then CrashPlan will benefit from them. Otherwise, not.

    But, I can tell you for sure that I get a bit of swap (it’s not much, but any swap is worse than no swap), so I too wonder whether the 256Mb of ram would be a win for CP, even if the ultimate speed of the dual-core CPU is better.

    Of course, if you want/need any wireless (which so far, I don’t), that would be a big consideration toward the Pro as well.

    Just yesterday I set up another Pogo, this time with their software remaining on it. When you enable “Media Sharing” to a PS3, that turns it into a DLNA server as well. Given the cheapness of these devices, I’m now considering dedicating one to CP and using the Pogo Software as-is, as a remote and local (via DLNA) server.

    If I have to buy another device (not likely for a while), I will either try the Pink one, or possibly even try something like a Trim-Slice or Sheeva, which might be a bit beefier spec-wise.

  25.  Avatar

    Thanks for the feedback. I think I may jump on a Pink one to act as a Crashplan Server.

    I have a dockstar that I run the Pogoplug software on for its easy iOS media player. I have open pogo on it as well to run Transmission.

  26. Example Avatar

    mkdir -p com/sun/jna/linux-arm work and create all the subdirs at the same time?

  27.  Avatar

    Good point. I haven’t tried that on ARCH, but I assume it works perfectly. I took the lame, but safe approach.


  28. Gmickd Avatar

    I have a quick question about the Crashplan installation process. During the installation process, I get a question asking where my runlevel init links are located. Since Archlinux is a BSD system it doesn’t have any runlevels. Do you just put /etc/rc.d ?

  29. hadar Avatar

    Yes, /etc/rc.d is the correct answer here. All of the init.d equivalent scripts end up in here, including the “crashplan” one.

  30. Zhentao Sun Avatar
    Zhentao Sun

    crashplan is great! But sometimes I need mirror my desktop files to pogoplug. Do you know how?

  31. hadar Avatar

    If I understand you correctly, then I don’t think you can do what you want, which is to use the PogoPlug in a normal mode but also be able to us it as a CrashPlan server. Unfortunately, it’s one or the other. You can switch back and forth, but only by altering the software on the PogoPlug boot sector.

  32. S.K. Avatar

    Hey! Not sure if  you’re still here…. but I’m trying this with a PogoPlug v4 and I got stuck… I’m at the point where you use the command

    ssh -L 4200:localhost:4243 user@ is, when I open crashplan on my laptop, it says “unable to connect to the backup engine, retry?”and while sshed into the pogoplug, it says “channel 2: open failed: connect failed: connection refused”Any ideas?

  33. hadar Avatar

    I’m not really sure. First, when you type the SSH command above, it should leave you on the PogoPlug machine. Is that true for you?

    Second, if it does, you can also type commands in that same shell. So, you can try typing:

    ps ax | grep crashplan (or ps ax | grep java)

    If that doesn’t return a running process with a giant command line, then CrashPlan isn’t running (started) on the Pogo.

    If it is, then I’m at a loss as to why it isn’t connecting, but you can also try to telnet to port 4243 on the pogo and see if it responds in any way.

  34. S.K. Avatar

     Hey Thanks for the reply! Sadly though this still isn’t working… Aw well…

    Using the command actually doesn’t let me SSH into the device, it just hangs after it asks for a password…but I can regularly SSH into it just fine… weird… and If I try again to open Crashplan on my laptop, the cygwin terminal now reports “channel 3: open failed: connect failed: Connection refused” so I have no idea what’s up with this… Crashplan is running, as well as java, so that isn’t my problem… Ah well, thanks for the help anyways hadar! I’ll keep trying if I can!

  35. hadar Avatar

    Wow, very strange indeed. If a regular ssh from the same terminal window works, there really is no reason why the one with -L should fail. Even if you didn’t edit the crashplan conf file, the SSH command should work, but no actual traffic will flow over the redirected port.

    So sorry I couldn’t help. 🙁

  36. Kvweb Avatar

    Well,  not  much luck here…  The CP install script just says I am using an incompatible Java….    Sure would like to find someone who has recently gotten CP installed on a Pogo Plug… if anyone is listening.  Thanks!!

  37. Kvweb Avatar

    I believe I discovered the necessary changes to make this work now as of 11/2012.   This follows nicely the steps above with a few changes that I found necessary.  

    first we need to get the cpio package
    pacman -Sy cpio

    First thing to do is download the latest CrashPlan-  at this time it is here:
    cd /tmp
    tar -xzf  *
    cd CrashPlan-install

    Select Y for “would you like to download Java…”
    Enter /etc/rc.d  for  the question about SYSV init scripts

    Now we download the Java that will actually be used  (if you do this earlier, the install script will complain about an invalid version)
    cd /tmp
    pacman –Sy openjdk6

    There seems to be a missing file in openjdk6 but it can be remedied by doing this:
    ln -s /usr/lib/ /usr/lib/

    Next we need to download a patched version of and stick it in the crashplan install directory
    We get the proper file from this blog post:
    cd /usr/local/crashplan

    finally we tell crashplan to look at the openjdk6 java and not the one it downloaded
    nano  install.vars
    Change the line   JAVACOMMON to this:   JAVACOMMON=/usr/lib/jvm/java-6-openjdk/bin/java

    Now you can start the crashplan engine and verify it is running
    cd /usr/local/crashplan/bin
    ./CrashPlanEngine start
    ./CrashPlanEngine status

    Next to supposedly “speed things up”  I did these steps: (from here again: )
    pacman -Sy nss
    cd /tmp
    ar vx libjna-java_3.2.7-4_armel.deb
    tar -xzf data.tar.gz
    cd /usr/local/crashplan/lib
    mkdir com
    mkdir com/sun
    mkdir com/sun/jna
    mkdir com/sun/jna/linux-arm
    cp /tmp/usr/lib/jni/ com/sun/jna/linux-arm/
    jar uf jna-3.2.5.jar com/sun/jna/linux-arm/

    finally I added “crashplan” at the end of the DAEMONS line in  /etc/rc.conf


  38. hadar Avatar

    I am glad to hear that you finally got it working, and even more pleased that you shared your steps with anyone else who might be stuck. Thanks!

    I’m not sure exactly which step was different in your solution from what I showed above, but since you start with the CPIO installation, I’m gonna guess that was a key piece. If I’m right, then you might have missed that I had it installing on the same line that Java was being installed:

    “Type: pacman –Sy openjdk6 cpio (we need to get a working Java installed and CrashPlan will require the cpio package separately)”

    Either way, congrats and enjoy the Pogo with CrashPlan! 🙂

  39. Kvweb Avatar

     Thanks for your comments.  I found that if I installed openjdk before installing CP,  CP would complain about an invalid version of Java…    So I installed  cpio first,  then CP, letting it download its own Java…  then I finally downloaded openjdk6 and told CP to use it instead of its own Java…   just a bit of a hoop…  🙂

  40. Kvweb Avatar

     Other steps that were different include dealing with a missing file….   Things for some reason were different for me than they were for you… who knows why?  🙂

  41. hadar Avatar

    Very interesting. Thanks for the explanation!

  42. hadar Avatar

    Actually, I wonder whether it’s because the new base root file system is updated, and there might be changes that affect my original steps.

  43. Kvweb Avatar

     Well,  you know this stuff much better than I … I am just glad to have it working right now!   I hope it keeps going.  I am wondering if upgrades will happen automatically or if I’ll have to work on stuff every time CP comes out w a new version… I guess we’ll see!!!   🙂

  44. S.K. Avatar

    Actually, neither of these will work anymore, because Arch has switched to using Systemd, which means that DAEMONS and init-scripts won’t work very well anymore, so for anyone who wants to do this, follow these instructions:

    For the most part everything seems to work as listed in the instructions, so you can:

    1) Install openjdk6 and cpio first, but after installing openjdk 6, you need to make a link between the two files using the command:

    cd /usr/lib
    ln -s

    (This is also said in Kvweb’s post, but the original thread is here:
    2) Get the latest Crashplan (which is currently also 3.41 at the time of writing, so just follow Kvweb’s comment or the actual post)
    ** when installing crashplan, and it asks you where to store the Init scripts, the /etc/rc.d location is fine, because we can make a systemd .service file and point it towards that

    3) Crashplan should install fine, because the new Java should work, and when it’s finished installing, then you can carry on through the rest of the instructions

    4) following the rest of the instructions are fine, but there’s no need to
    reinstall nss because it’s already installed in the newest Arch build, so just make all of the directories and follow the rest of the instructions until you get to the point in the post where it says

    “… I am going to add it to the DAEMONS list at the end of /etc/rc.conf”

    the problem with this is that rc.conf no longer exists, and will probably be phased out entirely in the newer builds, so what we have to do instead is make a systemd .service file

    **Note that I took all of this information from the thread over at and I just modified it to fit out scenario, so you should go and give them credit where it’s due, becuase I would have had no idea what I was doing

    5) To create a .service file, we need to do the following:

    cd /usr/lib/systemd/system/

    nano crashplan.service

    (and inside of the new file you can copy and paste this)

    Description=CrashPlan Backup Engine




    ExecStart=/usr/local/crashplan/bin/CrashPlanEngine start
    ExecStop=/usr/local/crashplan/bin/CrashPlanEngine stop


    (and then just save the file)

    6) Now to start crashplan we need to use some different commands, first we need to enable it at boot and we can do this using the command

    systemctl enable crashplan.service

    (This command will set crashplan to run at boot)

    7) Just restart and that’s it! Run top and check if you have a java process running, then follow the rest of the post

    *** Final Note, if you have the problem I did, which was the message:

    Channel 3 Open Failed Connect Failed Connection Refused

    Then don’t worry about it, All you need to do is wait, because for some reason, initially, crashplan uses 99% CPU and it won’t let you access it, but after you give it about 10 mins to work it’s magic, you should see the CPU usage drop, and you should be able to access it now

    That’s it! it you have any problems, comment here and ask Hadar, or Kvweb, or whoever else is still reading this, because chances are that they know more than I do…


  45. hadar Avatar

    Wow! Thank you so much for the detailed instructions. I feel like I should totally clean up the post to incorporate them, and perhaps someday, I’ll have the energy to do that. One of my hesitations is that I would feel like starting from scratch with an installation so that I could be sure of the exact steps, rather than just patch an old post.

    In any event, I’m sure you’ll save some future readers a huge headache even if I don’t!

  46. jackson Avatar

     Thanks for this.  I just had to follow my own instructions again earlier this week and found them to already be outdated.. yes- b/c of the rc.d stuff you mentioned.  I didn’t solve that problem your way but next time I will- as it is the right way– as opposed to the hack I did earlier this week.   I too had the Channel 3 open problem which I had not seen before.  I thought it helped when I deleted my .ssh directory but maybe really what happened was the 10 minute time span you mention.  Thanks so very much!!!   It would be cool to script this up someday but it seems that things change pretty often.

  47. jackson Avatar

     BTW_   this is KVWEB

  48. S.K. Avatar

    No Problem! I spent hours trying to get this to work as well, and when I finally did I totally forgot about sharing my knowledge! but then one of my circuit breakers popped and corrupted my installation so I had to do it again 🙁 I think Hadar should actually edit the original post, and change the instructions becuase those don’t work, and I don’t think we’re the only ones who want Crashplan on their pogoplug, but that’s just my opinion anyways…

  49. S.K. Avatar

     Yea, I think the switch to systemd is one of the biggest things for Arch right now, so if you ever get the time I’m sure it would help somone out there 🙂 But I think that you deserve the most thanks for writing this in the first place, because without you, I don’t think I would have any idea where to start! so thanks again Hadar 🙂

  50. Ridlr Avatar

    Thanks Guys, 

    With the updated instructions, I got CP installed without any issues… except 1. When it runs it maxes out the CPU… Not sure whether this will lead my box to an early grave (running many hours at max CPU).  I saw a post on getting Subsonic to run on Arch and apparently with the openJDK java environment it also consumes 100% cpu, but when folks swap out the Sun version it runs much better.  Wondering if anyone has tried this and whether there would be any reason that this wouldn’t work??

Leave a Reply

Your email address will not be published. Required fields are marked *