CrashPlan updated to 4.3.0, now will not connect

[nello]

See Update below.

I'm thinking that perhaps I have a network configuration problem since I'm getting these NAT errors:

Code:

root@crashplan_1:/ # tail /usr/pbi/crashplan-amd64/share/crashplan/log/service.log.0
        at com.code42.peer.PeerConnector.connect(PeerConnector.java:201)      
        at com.code42.peer.PeerConnector.connect(PeerConnector.java:102)      
        at com.code42.peer.PeerGroup.doConnectRemotePeer(PeerGroup.java:366)  
        at com.code42.peer.PeerGroup.doConnectRemotePeers(PeerGroup.java:326)
        at com.code42.peer.PeerGroup.access$200(PeerGroup.java:68)            
        at com.code42.peer.PeerGroup$ConnectWorker.run(PeerGroup.java:926)    
        at java.lang.Thread.run(Unknown Source)                              
                                                                             
[12.02.15 15:20:45.794 WARN    RPConnWrk-DefaultGro com.code42.peer.PeerGroup
            ] PG::DefaultGroup PeerException attempting to connect. RemotePeer-[
guid=614979079452111220, state=CONNECTING, mode=HOST, location=10.10.49.116:4242
, public=76.205.49.244:0, transportPbK=X509.checksum(95f14febe05b9dc46d8d089e511
605e8), connecting=2015-12-02T15:20:45:793, connected=0, disconnected=2015-12-02
T15:20:43:995, attempts=1, connectActivity=2015-12-02T15:20:45:793, keepAliveSen
t=0, minRetry=34938, retryDelay=0, reflector=na, #nat=0, session=null] e=com.cod
e42.peer.exception.PeerException: IOExcepton opening remote session. guid=614979
079452111220, remoteLocation=[[614979079452111220@10.10.49.116:4242], transportP
bK=X509.checksum(95f14febe05b9dc46d8d089e511605e8)], bindLocation=null, timeout=
5000, java.net.SocketException: Failed to connect to address /10.10.49.116:4242
root@crashplan_1:/ #

Can someone give me a hint about what this means and where I should look to correct it?

Thank you.

- nello

UPDATE 2015.12.06
After reviewing CrashPlan logs for both WAN and LAN Macintosh clients, I see now that all these clients were connecting and backing up to my FreeNAS server. Please accept my apology for posting this red herring.

 

[nello]

Anybody run into Crashplan constantly disconnecting?

[11.03.15 09:27:37.693 WARN MQ-Peer-0 aging.peer.ClientIdentifierAgent] DUPID:: Possible duplicate session detected. remote guid=42, old session=714408166928224831. Delay retry for 5 minutes. Disconnect

Did you figure out what caused these log entries? Better yet, did you figure out how to fix them?

 

[nello]

UPDATE 2015.12.06
After performing the following steps, my FreeNAS CrashPlan server is now working correctly, backing up both WAN and LAN (Macintosh) clients:

1. Followed @Liriel's configuration instructions
2. Uninstalled CrashPlan on my Macintosh
3. Installed CrashPlan 4.3.0 on my Macintosh (thanks for the link @jadz)

UPDATE 2015.12.03
Still getting this missing shebang 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:/ #

 

[stualden]

Nello, can you confirm this (your statement, slightly generalized) for backups from one computer to another?

In other words, the version mismatch...is a problem only when traversing the Internet, not within [the] LAN.

This is important for me due to the fact (cited by jadz above) that the FreeNAS CrashPlan version (and any Linux CrashPlan running on an older kernel) will be frozen at 4.4.1. I do my backups from my local FreeNAS to a Windows box in another physical location, but they're both on the same VPN so it appears to CrashPlan like everything's on my LAN.

Code42 told me that there is no way to prevent updates, so that poses a big potential problem for anyone with FreeNAS CrashPlan on one end and a non-Linux CrashPlan on the other. But if version mismatch within a LAN is okay, I have some breathing room (at least until they throw the another wrench into the works!).

--Stu

 

[nello]

… can you confirm this (your statement, slightly generalized) for backups from one computer to another?

In my case, all clients have upgraded and are now 4.4.1:

But my server has stayed at 4.3.3:

Code:

cat /usr/pbi/crashplan-amd64/share/crashplan/log/history.log.0 | grep version
…
I 12/04/15 02:35PM CrashPlan started, version 4.3.3, GUID 659746361683476481
root@crashplan_1:/ #

Both WAN and LAN (Macintosh) clients are backing up just fine, based on what I see in the clients' History tab. Here, for example is some history from a LAN-based iMac (named Argus):

And here is History from a WAN-based Mac Mini; the backup interruptions were due to FreeNAS reboots and a power failure:

Here's the History for a MacBook Pro; interruptions are for the same reasons:

So it appears that mismatched versions of CrashPlan 4.3.3 through 4.4.1 are compatible with one another regardless of whether the connection is WAN or LAN.

 

[nello]

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

The answer is that there is no need to "force" CrashPlan to connect to Code42 servers; it calls home automatically if the network permits it.

Here are some CrashPlan support articles on network configuration to support computer-to-computer connectivity:
https://support.code42.com/Administ...ng_Port_Forwarding_In_Your_Code42_Environment
https://support.code42.com/CrashPla...ng_A_Telnet_Test_to_Verify_Network_Connection

 

[stualden]

So it appears that mismatched versions of CrashPlan 4.3.3 through 4.4.1 are compatible with one another regardless of whether the connection is WAN or LAN

Thank you, very helpful!

I also checked with Code42, and they indicated that version mismatch will be a problem, regardless of LAN or WAN. So I guess if our setups are able to function with a version mismatch, we're just lucky, and our luck could disappear at any time.:(

 

[nello]

… Code42 … indicated that version mismatch will be a problem, regardless of LAN or WAN.

Yes, I've heard from many sources that the versions must match. That's why I included logs and screenshots of I'm observing.

 

[raidflex]

I currently have the Crashplan plugin installed and I did confirm in the log that the version is up to date with 4.4.1. The problem I have no matter how many times I change both the my.services.xml and the .ui_info files with the correct info, once I start the jail back up the both files reverts back to the incorrect info. Now I have multiple clients and I do not want to have to go to each one with the correct .ui_info, this is why I am changing it on my Freenas server.

 

[stualden]

Are you saying that you use multiple clients (front-ends) to access a single crashplan server? (I guess that should work - haven't thought about it.)

You shouldn't need to modify my.services.xml - is it changing on you too? All that's generally needed are these two steps:

1) Copy server's .ui_info to the front end's .ui_info (so they are both using the same key).
2) On the front end's .ui_info, replace the 0.0.0.0 at the end of the line with the server's IP address

If your various clients each have a different key, that will definitely cause trouble.

 

[raidflex]

Are you saying that you use multiple clients (front-ends) to access a single crashplan server? (I guess that should work - haven't thought about it.)

You shouldn't need to modify my.services.xml - is it changing on you too? All that's generally needed are these two steps:

1) Copy server's .ui_info to the front end's .ui_info (so they are both using the same key).
2) On the front end's .ui_info, replace the 0.0.0.0 at the end of the line with the server's IP address

If your various clients each have a different key, that will definitely cause trouble.

I have multiple clients that are remote and backup to my Freenas server. All of the client's .ui_info files have the same key. What I am trying to do is update the Freenas server's .ui_info file with the same key that all of the clients have. Currently I would stop the jail and update both the my.service.xml and .ui_info files with the correct information. After I start the jail back up I find that both files have been reverted back to the previous settings. I am trying to figure out how to make these settings stick.

 

[stualden]

Oh - so you are backing up from those clients to FreeNAS and you also need each of them to be able to act as a front-end to the headless CrashPlan server on FreeNAS?

 

[raidflex]

Oh - so you are backing up from those clients to FreeNAS and you also need each of them to be able to act as a front-end to the headless CrashPlan server on FreeNAS?

Yes basically, well right now I need at least one client to be able to even connect to the headless interface. As it stands I cannot gain access to the GUI interface on the headless server because every time I change the .ui_info file on the Freenas server it reverts back. So when this happens none of the client's can find the server anymore and therefore I cannot use the Crashplan GUI to configure the back-end headless server.

 

[stualden]

Just one theory - if your clients are Windows, what do you have (for any of them) in

C:\ProgramData\CrashPlan\conf\ui_<username>.properties

Looking back at my notes for a prior CrashPlan version, I had an inconsistency between this and the other files, and that was causing my.service.xml to be overwritten every time I fired up the jail and the plugin. Don't know whether the same issue exists in the latest version of CrashPlan.

 

[raidflex]

Just one theory - if your clients are Windows, what do you have (for any of them) in

C:\ProgramData\CrashPlan\conf\ui_<username>.properties

Looking back at my notes for a prior CrashPlan version, I had an inconsistency between this and the other files, and that was causing my.service.xml to be overwritten every time I fired up the jail and the plugin. Don't know whether the same issue exists in the latest version of CrashPlan.

I ended up changed the permission on the .ui_info and my.service.xml files to read only and this worked.

 

[Xelas]

I ended up changed the permission on the .ui_info and my.service.xml files to read only and this worked.

Can you please provide detail? Did you do this on the client, server, or both?

 

[Andrew076]

I am having a different problem. I had to reinstall the plugin and now it is stuck at version 3.6.3. It seems to be working (after I found an old version of the GUI for windows to install) but I can't seem to get it to update. Any ideas as to what may be going on?

 

[Andrew076]

Fix is Here. It worked for me to get past 3.6.3.