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>(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:662)

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 -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0"

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

-Djava.io.tmpdir=<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="-Djava.io.tmpdir=/home/myname/crashplan-temp -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx512m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -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!

About these ads

5 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.
    Cheers!
    Kevin.

  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.(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:662)

    Thanks!

  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 (https://packages.debian.org/wheezy/armhf/libffi5/download) and finally libjna-java for armhf (https://packages.debian.org/wheezy/armhf/libjna-java/download), then dpkg -i libffi5 and finally dpkg -i libjna-java before everything worked.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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