CrashPlan Pro for Linux: Stuck at “Waiting for Backup” or “Connecting to Backup Destination”

First off, I want to give a shout-out to a very helpful post. Thank you to Bryan for posting these tremendously helpful posts on how to get CrashPlan up-and-running on headless Linux server (aka: pretty much any Linux Web Server).

Installing CrashPlan on a Headless Linux Server
Using the Windows CrashPlan Client to manage a headless Linux server 

Also there is more on CrashPlan’s own site about this here.

Anyways, so the rest of this article assumes that you have successfully gotten CrashPlan installed on your Linux server, and that you are able to manage it via a remote client and select folders for backup.

So, what happened to me was, I got everything configured correctly, but still could not get the backup going. These are the symptoms I faced:

1. The folders were successfully selected; I could see them on CrashPlan’s web interface as selected
2. CrashPlan PRO Online (CrashPlan Central) was selected as the destination
3. No matter  what I tried, it would just sit there saying “Waiting for Backup” or “Connecting to Backup Desitnation” and would say 0 files completed.

These are the troubleshooting steps I performed:

1. I verified that ports 443, 4242 and 4243 were allowed for outbound connections
2. I tried restarting the CrashPlan Engine multiple times
3. I even uninstalled and re-installed CrashPlan completely
4. There were various posts online about versions of Java and changing things with the Java install. I didn’t think this was the problem for me…so I would suggest you skip those steps if you see them.

I eventually started looking at the logs, and found this Java error in one of the log files:

Exception in thread "W30145090_ScanWrkr" java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.<init>(
at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(
at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(
at com.code42.backup.path.BackupSetsManager.access$1600(
at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(

Now, as far as I understand it, inotify is only needed if you want to do scanning for real-time file changes. I actually didn’t even want to do this, so I disabled that, but it still didn’t find my problem.

I finally came across this post on CrashPlan’s own site that has a viable answer! Unfortunately the title of the post doesn’t say anything about “Waiting for Backup” so it is hard to connect it as the solution for this particular issue. Thank you to Renee S from CrashPlan for posting a viable solution that works on that forum!

Basically, the short of it is, CrashPlan doesn’t have the right parameter on the /tmp/ folder it needs to perform the backups.

Here are the instructions to get it to work again. 

1. You will need to create a new tmp folder for CrashPlan on your Linux server. Here are the specifications for that folder
– They recommend putting the directory in a user’s home directory (not root’s)
– The user CrashPlan was installed under must have write permissions on the directory you create
– IMPORTANT: The directory must be without the noexec restriction.
– So, for example, your directory might be: /home/myname/crashplan-temp

2. Once you have your temp folder created, you need to edit the run.conf file which is located here: /usr/local/crashplan/bin/run.conf

3. Open up this file, and look for this line:

SRV_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Dnetworkaddress.cache.ttl=300 -Dnetworkaddress.cache.negative.ttl=0"

4. We need to add an additional paramater specifying the new temp directory. This is done using this form:<path>

where <path> is a pointer to the directory you created in step 1. This can be added to the BEGINNING of the line, right after the quotes, so using the theoretical directory listed in step 1, it might look something like this

SRV_JAVA_OPTS=" -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Dnetworkaddress.cache.ttl=300 -Dnetworkaddress.cache.negative.ttl=0"

5. Once you have that saved, restart CrashPlan on the Linux server for good measure, then it should work!

A couple tips if it still isn’t working:

– Make sure you have appropriate permissions on the directory you specified
– a few people had success changing the ownership to nobody:nobody  (chown nobody:nobody). I didn’t have to do this, but it might work for you

I hope this fix works for you!

22 thoughts on “CrashPlan Pro for Linux: Stuck at “Waiting for Backup” or “Connecting to Backup Destination”

  1. Huge thumbs up to you, been on the line with CrashPlan support for two days now, too bad they weren’t aware of this. Anyhow, thanks for posting solution. As for the user and dir info, we’ve always stored the backups in /backup until they could be seeded, and we’ve got crashplan installed as root, so instead of creating a new tmp dir in a user dir, I created it at /backup/tmp which is owned by root, and it worked perfectly once the Java file had been updated as you instructed.

  2. What Log file and path did you find this in?

    Exception in thread “W30145090_ScanWrkr” java.lang.NoClassDefFoundError: Could not initialize class com.code42.jna.inotify.InotifyManager
    at com.code42.jna.inotify.JNAInotifyFileWatcherDriver.(
    at com.code42.backup.path.BackupSetsManager.initFileWatcherDriver(
    at com.code42.backup.path.BackupSetsManager.startScheduledFileQueue(
    at com.code42.backup.path.BackupSetsManager.access$1600(
    at com.code42.backup.path.BackupSetsManager$ScanWorker.delay(


  3. Pingback: CrashPlan on a headless server - John Bousman

  4. Another reason CrashPlan can get stuck at ‘waiting to connect’ is missing libjna-java. I have recently reinstalled Ubuntu 12.10 on my Cubox (armv7, armhf) on top of Oracle Java 1.7 RE, for which I couldn’t apt-get the libjna-java archive as I had done previously. So I had to apt-get libc6 and manually download libffi5 ( and finally libjna-java for armhf (, then dpkg -i libffi5 and finally dpkg -i libjna-java before everything worked.

  5. Fantastic – “We are not trained to support a headless installation, sorry” was Crashplan’s response – your reply worked straight away, so easy.

  6. Fortunately, I am trained in such installations, even though CrashPlan Support gets paid to do it and I don’t. Go figure!

  7. I am trying your advices on a synology NAS DS 413 because my backup is stuck and never started.

    But i modified the run.conf and create a new temp forlder
    Change nobody:nobody on the folder
    check my permissions

    But still stuck, anyone who got a synology NAS have an advice for me … thx

  8. You are awesome!

    Had spent an couple of hours trying to get this working. 5 minutes with your instructions and job done. Many thanks!

  9. Pingback: CrashPlan Error "Cound not Initialize class com.code42.jna.inotify.InotifyManager" - GeekTank

  10. I’m running into this issue on my Netgear ReadNAS 104. Almost identical engine_error log output as in the post. I tried adding the temp dir and I do see a file got created there but I still get the error in the log after restarting Crashplan. My CP version was recently upgraded automatically to 4.4.1 as well, and I have libjna installed and running openjdk-7-jre. Any ideas on what else I could try? Or does it just take a little while before the backups kick in – I noticed in 4.4.0 this was the case… although I had issues other than this with 4.4.0 where backups would initially work and then the service would halt due to other Java issues. Maybe that was related to this, I don’t know. I guess I’ll just wait a bit and see if it eventually kicks the backup off. From what it sounds like though, it should almost immediately start backing up.

  11. So I ended up realizing the jna.jar in my Crashplan lib had a different md5sum from the jna.jar provided by the libjna-java package. I copied the jna jar from libjna over to the Crashplan lib and restart and no more error in the engine_error log as well as in the service log! I’m holding my breath though because it doesn’t look like the backup has started (though, it has been almost a month since my CP backups have been broken…)

  12. On my WD MyBook Live CrashPlan stopped working with “Destination not available” after the automatic upgrade to v4.4.1. As mentioned in an earlier post, the problem turned out to be the libjna-java: the native library provided by this package contained an older version of the library no longer compatible with the version of JNA used by CrashPlan. Ideally, I would have upgraded this native library to the latest version, but since I couldn’t find the latest version for linux-ppc required for my NAS, I downgraded the jna.jar found in the CrashPlan installation back to the earlier version 3.2.7 (downloaded from Maven repository). A bit risky I guess, since CrashPlan might use features of the newer library, but it seems to work for now!

  13. The solution to the NoClassDefFoundError is actually fixed by setting -Djna.nosys=true in the SRV_JAVA_OPTS value in bin/run.conf The temp folders have nothing to do with this problem. There is an incompatibility between the INotifyManager in the Crash Plan com.backup42.desktop.jar and the system library that java loads at runtime.

    If you carefully review the log/engine_output.log for errors, it will document this error with three suggestions. One is the value I provided above (which is disabling reception of individual file change notices from the kernel–this forces the system to scan the full path for changes). There are a few other suggested options for setting the jna.boot.library.path value, but my own attempts to get the setting right were unsuccessful.

  14. I followed your device, but it still wasn’t working. I read in another post, that an update of the jna.jar was necessary.

    I downloaded the latest version of jna from:

    I then replace the jna.jar in /var/packages/CrashPlan/target/bin with the latest version. Now everything is working.

  15. HeikoU, you’re probably going to have to repeat what you did in the case that Crashplan auto-upgrades your system. Because the CP auto-updates basically wipe out/overwrite anything you manually modified, including the jna.jar you copied in.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s