CrashPlan updated to 4.3.0, now will not connect

[Xelas]

That much HAS been done correctly, definitely - and it doesn't work......?

With all of the issues you've been having, and with even the basic "tail" utility not working, I'm not 100% certain your jail is healthy. The latest update requires bash, and it very well could be that you may have bash installed, but it isn't working correctly.

Liek Nick said, I'd take a long and hard look through crashplan logs for any clues - spend some good quality time and dredge through the logs. The logs are, indeed, extremely detailed.

At this point, I'd also start seriously considering a nuke and rebuild, especially if this jail has been around a long time. At the every least, you'll be starting from known environment, and you should be able to just go back through this thread and follow the steps that were outlined. A newly created jail won't have ancient versions of pkg that needed to be force-updated, for example, along with any other old cruft that may have broken during a borked subsequent update.

P.S. - I don't bother setting up SSH in the jail itself - there's no real good reason. I do have SSH set up with a keyfile and a password for the main FreeNAS install, then just use jexec if I need to execute commands within a jail, or you can browse the file contents straight from the main account. For example, if I have my Crashplan jail in a dataset called "Jails", and my volume "MainVol", then you can just got to /mnt/MainVol/Jails/Crashplan" to get to the root folder of your jail.

 

[diskdiddler]

You just told us your server is on 4.3.X, and your client is 4.4.X. Which means you haven't done that correctly.

Code:

You'll need to put the correct IP in the ui.properties file on the client side, and then connect to the engine. As soon as you connect, that should trigger the engine connecting to the CrashPlan cloud, which will cause it to attempt to update. You can also check the error log on the server for any things that aren't working correctly.

I can assure you, that much has been done correctly. Why Crashplan won't update I don't know. I'm not debating I have the wrong server version but something is clearly not working right.
Each time the jail is restarted, the crashplan engine is generating a new key and writing a fresh .ui_info - also the app.log file which I renamed, was re-populated (as part of testing)
The engine is running.

Regardless, attempting to connect with my 4.4.1 client on my desktop doesn't work, (due to server version)
Do I need to downgrade to 4.3 on the desktop to force it to connect properly and then force 4.3 to update?

I'll take a peek in the log file now.

 

[Xelas]

...
Do I need to downgrade to 4.3 on the desktop to force it to connect properly and then force 4.3 to update?

I'll take a peek in the log file now.

If you still have the installer for 4.3 around, then, yes, by all means try using it! Between 4.4 and older versions, the crashplan UI and engine broke compatibility, so you have to use an older UI to connect to the older engine, and vice versa.

 

[diskdiddler]

Will that be the best method of instigating 4.3 to update (on the server?)

 

[Xelas]

Will that be the best method of instigating 4.3 to update (on the server?)

Well, at least if you log into it, you'll rule out basic connectivity being an issue. BTW - I DON'T have a copy of the old client.

 

[diskdiddler]

I've got a copy of the app.log but.... perhaps I'm stupid or ........ I dunno but wow does it look a lot more like a config.log - there's very little log style information in there.
Reminds me of an XBMC / Kodi advancedsettings.xml file you know? Nothing like al og file dumping errors.

 

[Nick2253]

Code:

You'll need to put the correct IP in the ui.properties file on the client side, and then connect to the engine. As soon as you connect, that should trigger the engine connecting to the CrashPlan cloud, which will cause it to attempt to update. You can also check the error log on the server for any things that aren't working correctly.

I can assure you, that much has been done correctly. Why Crashplan won't update I don't know. I'm not debating I have the wrong server version but something is clearly not working right.
Each time the jail is restarted, the crashplan engine is generating a new key and writing a fresh .ui_info - also the app.log file which I renamed, was re-populated (as part of testing)
The engine is running.

Regardless, attempting to connect with my 4.4.1 client on my desktop doesn't work, (due to server version)
Do I need to downgrade to 4.3 on the desktop to force it to connect properly and then force 4.3 to update?

I'll take a peek in the log file now.

You still not reading what we're telling you: you need to be on 4.3 on the client side in order to connect to 4.3 on the server side. Theoretically, if you have no other issues, that should automatically start the update.

You HAVE to go to 4.3. Until you go to 4.3, any changes you make are meaningless, because you CANNOT connect a 4.4 client to a 4.3 server. And until you connect, the upgrade will NOT start.

 

[diskdiddler]

That seems like incredibly poor design. Can I manually update the server?
I really don't want to go and hunt and peck around the internet for 4.3 client x64 for Windows.

 

[jadz]

https://download1.code42.com/installs/win/install/CrashPlan/jre/CrashPlan-x64_4.3.0_Win.exe

 

[diskdiddler]

NOTE ALL:
Just got this in my email today.

Mike (Code42 Helpdesk)

Dec 1, 3:29 PM

Hello,

We're contacting you to let you know about some changes made to the newest version of CrashPlan that may affect the CrashPlan app on one of your devices. Starting with the release of CrashPlan version 4.5.0, the System Requirements with regards to Linux have changed. Here are the system requirements that have changed:

Linux kernel version:

• CrashPlan app version 4.5.x or later: 2.6.27 or newer and glibc 2.9+
• CrashPlan app version 4.4.1 or earlier: 2.6.13 or newer and glibc 2.4+

If you have a Linux device running kernel 2.6.26 or older and are still on CrashPlan version 4.4.1, CrashPlan on this device will not upgrade to version 4.5.0. If your device is on kernel 2.6.26 or older and has already upgraded to CrashPlan version 4.5.0, CrashPlan has likely stopped working.

To continue using up-to-date versions of CrashPlan, we recommend upgrading your operating system to a supported version of the Linux kernel. For instructions on upgrading your Linux device, refer to the documentation for your device or your Linux distribution.

An alternate solution to resolve this is to Uninstall CrashPlan 4.5.0, and install CrashPlan version 4.4.1, which can be found in this direct link:

• https://download.crashplan.com/installs/linux/install/CrashPlan/CrashPlan_4.4.1_Linux.tgz

Please Note: Computer-to-computer backups require both devices be on the same version of the CrashPlan app.

We've created a Support Article that explains more about this change, here:

• https://support.code42.com/CrashPla...inux_CrashPlan_App_Version_4.5_Cannot_Back_Up

Please let us know if you have any further questions.

Thank you,
Code42 Customer Champion Team

 

[stualden]

I did too. Could someone please tell us whether the message there indicates that FreeNAS CrashPlan users will experience a problem or not?

I (probably like many happy FreeNAS users) am blissfully ignorant of which Linux-emulation kernel and glibc version FreeNAS is currently using!

 

[jadz]

If you were selected for the early rollout of CrashPlan 4.5.0 (i.e. prior to them realizing this issue) CrashPlan would have tried to upgrade from 4.4.1 to 4.5.0 (for me this happened on Nov 23rd). Per their notice, 4.5 is not compatible and would have been in a broken state.

As far as I know there is no uninstall, and they simply suggest you re-install (which for FreeNAS users means installing the plugin, then getting CrashPlan to automatically upgrade).

They have also indicated that they will put a check in to prevent the upgrade if the system that is running crashplan doesn't have a supported Kernel. I believe what this means is that users with an older Linux kernel (or emulation as is the case for FreeBSD) will simply not be upgraded beyond 4.4.1.

IMO this is actually a good thing for the short/medium term, as FreeNAS installations should remain stable and not break on future updates. In the long term this means that at some point they will drop support for 4.4.1 (which isn't good).

 

[nello]

There is no such thing as "forcing" an update. Every time the CrashPlan services connects to Code42, it will check if it's running the most recent version. On the next startup, it attempts to install this newer version.

Okay, then the question is, "How can we force CrashPlan to connect to Code42?"

 

[jadz]

My experience is that to force CrashPlan to connect to CPC (CrashPlan Central) you have to associate the installation with an active CrashPlan account. In my case, each time CrashPlan gets in a funky state, I redeploy the CrashPlan FreeNAS plugin (in a new jail). I connect using the matching client GUI from my windows desktop, and I take over the backup from my old corrupt CrashPlan jail. When I do this, it connects to CrashPlan Central and then downloads and installs the update.

I just did this again last night because I was one of the ones that had CrashPlan 4.5.0 pushed to me (which is incompatible with FreeBSD/FreeNAS. I'm not back up and running with successful backups.

Okay, then the question is, "How can we force CrashPlan to connect to Code42?"

 

[nello]

https://download1.code42.com/installs/win/install/CrashPlan/jre/CrashPlan-x64_4.3.0_Win.exe

Do you know where I could find the Macintosh 4.3.x CrashPlan client?

Sorry, I looked and couldn't find it.

Thank you.

 

[nello]

Apparently, there's some nuance to the requirement that CrashPlan client and server versions match.

I backup my brother's Macintosh over the Internet to my FreeNAS CrashPlan Jail.
This worked fine until November when my FreeNAS CrashPlan failed to update (presumably due to the lack of bash) and stayed at version 4.3.3 while my brother's client updated successfully to version 4.4.1. (Meanwhile, on my LAN, my Macintosh CrashPlan client upgraded to 4.4.1 and continued to do it's backups despite the version mismatch with CrashPlan (4.3.3) on my FreeNAS server.

In other words, the version mismatch (4.4.1 client vs. 4.3.3 server) is a problem only when traversing the Internet, not within my LAN (10.10.49.x, mask 255.255.255.0)


UPDATE 2005.12.02
After restarting the LAN Macintosh and I'm no longer able to connect to my FreeNAS CrashPlan. Apparently the routing necessary for a connection was cached somewhere on my LAN Macintosh.

UPDATE 2005.12.02
After installing Java for OS X 2015-001, my Macintosh CrashPlan 3.6.3 client is able to connect and back up to my FreeNAS Crashplan 4.3.3 server. Apparently upgrading to OS X 10.11 (El Capitan) interfered with the Java 6 I had already?

 

[jadz]

Do you know where I could find the Macintosh 4.3.x CrashPlan client?

Sorry, I looked and couldn't find it.

Thank you.

https://download1.code42.com/installs/mac/install/CrashPlan/CrashPlan_4.3.0_Mac.dmg

 

[nello]

In my case, each time CrashPlan gets in a funky state, I redeploy the CrashPlan FreeNAS plugin (in a new jail).

In my case …

My FreeNAS CrashPlan failed to update (presumably due to the lack of bash) and stayed at version 4.3.3 while my Macintosh LAN client updated successfully to version 4.4.1. As I noted above, my backups continue to run for this LAN connection (despite this version mismatch). However, backups fail to run over the Internet between client 4.4.1 and server 4.3.3.

I think my FreeNAS CrashPlan would now accept an upgrade because I've:

Code:

pkg install bash
pkg upgrade
pkg update
ln -siv /usr/local/bin/bash /bin/bash

Then I stopped the CrashPlan Jail and replaced the contents of /usr/pbi/crashplan-amd64/share/crashplan/bin/run.conf with

Code:

SRV_JAVA_OPTS="-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx3072m -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false -Djava.net.preferIPv4Stack=true"
GUI_JAVA_OPTS="-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider -Dfile.encoding=UTF-8 -Dapp=CrashPlanDesktop -DappBaseName=CrashPlan -Xms20m -Xmx512m -Djava.net.preferIPv4Stack=true -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.ttl=0 -Dnetworkaddress.cache.negative.ttl=0 -Dc42.native.md5.enabled=false

In an attempt to trigger an update to CrashPlan (from 4.3.3 to 4.4.1) on my FreeNAS server, I

Code:

Uninstalled CrashPlan (4.4.1) from my LAN Macintosh
Installed CrashPlan 3.6.3 on my LAN Macintosh
Configured my LAN Macintosh to "adopt" its previous backup

At this point, my LAN Macintosh CrashPlan 3.6.3 (client) seems to connect just fine with my FreeNAS Crashplan 4.3.3 (server).

I'm assuming that at some point my LAN CrashPlan 3.6.3 with contact Code42 and upgrade itself serially. Presumably, when it gets to 4.3.3 (matching the FreeNAS CrashPlan version), both the Macintosh and FreeNAS CrashPlans will hold hands and jump to version 4.4.1

Does this update scenario seem plausible?


UPDATE 2005.12.02
After rebooting my LAN Macintosh (CrashPlan 3.6.3) it can no longer connect with CrashPlan 4.3.3 on FreeNAS.

UPDATE 2005.12.02
After installing Java for OS X 2015-001, my Macintosh CrashPlan 3.6.3 client is able to connect and back up to my FreeNAS Crashplan 4.3.3 server.

UPDATE 2005.12.02
The FreeNAS CrashPlan hasn't attempted a update since Nov 23, over a week ago

Code:

cat /usr/pbi/crashplan-amd64/share/crashplan/log/history.log.0 | grep version
…
I 11/23/15 11:18AM Downloading a new version of CrashPlan.
I 11/23/15 11:18AM Installing upgrade - version 1435726800441
I 11/23/15 11:18AM Upgrade failed - version 1435726800441
root@crashplan_1:/ #

UPDATE 2005.12.02
Any idea why server status throws this error?

Code:

root@crashplan_1:/ # service crashplan status
/usr/local/etc/rc.d/crashplan: WARNING: no shebang line in /usr/bin/cpuset
crashplan is not running.
root@crashplan_1:/ #

 

[jadz]

November 23rd happens to be when CrashPlan 4.5.0 was pushed to some FreeNAS users.

Crashplan 4.5.0 doesn't work on FreeNAS (and they are now preventing the upgrade from being pushed onto non-compliant systems, such as FreeNAS).

CrashPlans suggestion is to re-install the older, compatible version. If this is your problem, then your best bet is to create a new CrashPlan plugin instance instead of trying to fix the broken one.

 

[nello]

If this is your problem, then your best bet is to create a new CrashPlan plugin instance instead of trying to fix the broken one.

None of the updates since Nov 23rd succeeded so I don't think that I have CrashPlan 4.5.0.

Doesn't this prove that I'm running 4.3.3?

Code:

root@crashplan_1:/ # cat /var/log/crashplan/engine_output.log
Java HotSpot(TM) Client VM warning: Can't detect initial thread stack location - find_vma failed                                                               
[ … ] Locale changed to English                                       
[ … ] *************************************************************   
[ … ] *************************************************************   
[ … ] STARTED CrashPlanService                                         
[ … ] CPVERSION = 4.3.3 - 1430802000433 (2015-05-05T05:00:00:433+0000) - Build: 3                                                                     
[ … ] LOCALE = English                                                 
[ … ] ARGS = [  ]                                                     
[ … ] *************************************************************   
[ … ] Adding shutdown hook.                                           
[ … ] BEGIN Loading Configuration                                     
[ … ] BEGIN Copy Custom                                               
[ … ]   Directories: [.Custom, custom, /repository/.Custom, /repository/custom]                                                                       
[ … ]   NOT waiting for custom skin to appear                         
[ … ]   NO customizations found.                                       
[ … ] END Copy Custom                                                 
[ … ]   Loading from default: /usr/pbi/crashplan-amd64/share/crashplan/conf/default.service.xml                                                       
[ … ]   Loading from my xml file=conf/my.service.xml                   
[ … ]   Loading ServiceConfig, newInstall=false, version=7, configDateMs=1449035556745, installVersion=1388556100363                                   
[ … ]   OS = Linux                                                     
[ … ]   AuthorityLocation@10050674[ location=central.crashplan.com:443,             ]   NO customizations found.                                       
[ … ] END Copy Custom                                                 
[ … ]   Loading from default: /usr/pbi/crashplan-amd64/share/crashplan/conf/default.service.xml                                                       
[ … ]   Loading from my xml file=conf/my.service.xml                   
[ … ]   Loading ServiceConfig, newInstall=false, version=7, configDateMs=1449035556745, installVersion=1388556100363                                   
[ … ]   OS = Linux                                                     
[ … ]   AuthorityLocation@10050674[ location=central.crashplan.com:443, hideAddress=false, isLocked=false ]                                           
[ … ]   Checking Java memory heap max.                                 
[ … ]     Previous Java memory max heap size was 3072                 
[ … ] END Loading Configuration
jtux Loaded.                                                                   
root@crashplan_1:/ #

Am I misunderstanding what the log says?

Thank you.

- nello