SOLVED Crashplan NOT updating?

Status
Not open for further replies.

Paul Suh

Dabbler
Joined
Jul 15, 2015
Messages
16
OK, I followed the various guides (mostly https://forums.freenas.org/index.ph...home-computers-to-crashplan-on-freenas.39265/). Crashplan on my Mac insisted on launching after installation no matter what to I eventually ran the 3.6.3 client in an Ubuntu VM, no big deal. Unlike others, for me the Crashplan service in the plugin jail doesn't update. I've disconnected, reconnected, restarted the jail multiple times with the 3.6.3 client and the version listed in app.log stays 3.6.3. Just for fun I tried connecting using 4.5.0 from my Mac and it just gives a disconnect, but the service in the jail stays at 3.6.3.

Anyone have any idea what's going on? The service.log file doesn't seem to have anything obvious. Is the lack of an update a problem? o_O


--Paul
 

mastax

Cadet
Joined
Nov 27, 2015
Messages
3
Hi Paul,

I have the same problem. Can't get it to update, but there is no indication of why in any of the logs.

What I will say is that you really should figure this out before using crashplan because I've had really bad luck with different crashplan versions trying to work together.

Backing up from 4.5.0 (mac) seems to work but then it gets really slow and never finishes the last few files no matter what I do. Worse, restoring doesn't work since the 4.5.0 backup archives are encrypted in a way that 3.6.3 can't decrypt.

I'm currently trying to manually install 4.5.0 using the linux .tar.gz and just replacing the old files from 3.6.3 but using the same modified crashplan plugin configuration. If it works I'll come back and give a step-by-step.

Edit:

I can't even get the 4.5.0 client on my windows machine to start in headless mode despite changing every possible config file. I'm giving up for now. Also looking for solutions.
 
Last edited:

Paul Suh

Dabbler
Joined
Jul 15, 2015
Messages
16
@mastax - thanks for the feedback. Please keep us posted on your results from replacing the files from the linux 4.5.0 .tgz.


--Paul
 

Paul Suh

Dabbler
Joined
Jul 15, 2015
Messages
16
On FreshPorts, the sysutils/linux-crashplan port is now at version 4.3. Has anyone tried using that one?
 

mastax

Cadet
Joined
Nov 27, 2015
Messages
3
@Paul Suh I've gotten a manually-upgraded version of Crashplan 4.5.0 to work.

Here's the steps I followed:
  1. Follow the guide to step 6, except install Crashplan 4.5.0 on the 'client' computer (DO NOT log in).
  2. On the Freenas, in a shell to the crashplan_1 jail, download and extract the Crashplan Linux 4.5.0 installer.
    Code:
    su -
    cd /usr/pbi/crashplan-amd64/share/crashplan
    wget --no-check-certificate http://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.5.0_Linux.tgz
    tar -xf CrashPlan_4.5.0_Linux.tgz
    cd crashplan-install
    cpio -idv < CrashPlan_4.5.0.cpi
  3. Stop the crashplan service
    Code:
    service crashplan stop
  4. Replace the libraries
    Code:
    cd ..
    rm -r lib*
    cp -r crashplan-install/lib* .
  5. Start the crashplan service
    Code:
    service crashplan start
  6. Follow the Crashplan Headless Guide, but make sure to make .ui_info read only on the client computer or it will be overwritten.
  7. Restart the crashplan service on the client computer and log in to the crashplan UI.
Edit:
8. Restart the Freenas (or at least the jail). I didn't do this initially and I thought it was working but it wouldn't restore properly.
 
Last edited:

Paul Suh

Dabbler
Joined
Jul 15, 2015
Messages
16
Interesting. I've been going a different route -- I created a standard jail, updated the ports tree using portsnap, then installed sysutils/linux-crashplan, which got me up to version 4.3.0. It still won't update to 4.5.0, however. I'll try your technique of copying in the items in lib. Thanks for writing this up!


--Paul
 

mastax

Cadet
Joined
Nov 27, 2015
Messages
3
Interesting. I've been going a different route -- I created a standard jail, updated the ports tree using portsnap, then installed sysutils/linux-crashplan, which got me up to version 4.3.0. It still won't update to 4.5.0, however. I'll try your technique of copying in the items in lib. Thanks for writing this up!
--Paul

I'd test this thoroughly before trusting it with your data. Also (as I added above) be sure to restart the jail or NAS afterwards. I was having restore issues that fixed themselves after I did that.
 

Eric Blau

Dabbler
Joined
Dec 13, 2015
Messages
25
Thanks. This procedure worked for me. It fixed some backups to a friend that were stuck since he is on 4.5 and I was on 3.6.3. Restores seem to work fine and backups to my NAS are working perfectly.
 

Reece Johnson

Dabbler
Joined
Dec 2, 2015
Messages
13
Worked for me too! I had been running on 3.6.3 after installing FreeNAS 9.3.1 for close to a month with no auto-update. No issues with this update process to get the 4.5.0 engine running.

One caveat I have - the History tab of the client does not seem to be updating after the upgrade. I can backup files, restore them, and verify file count through the CrashPlan website, but have no record of the backups on the client. Does the History tab update for others after this?
 

Eric Blau

Dabbler
Joined
Dec 13, 2015
Messages
25
Worked for me too! I had been running on 3.6.3 after installing FreeNAS 9.3.1 for close to a month with no auto-update. No issues with this update process to get the 4.5.0 engine running.

One caveat I have - the History tab of the client does not seem to be updating after the upgrade. I can backup files, restore them, and verify file count through the CrashPlan website, but have no record of the backups on the client. Does the History tab update for others after this?

I noticed immediately after upgrading that the app.log file in /usr/pbi/crashplan-amd64/share/crashplan/log has info about CrashPlan startup, configuration, etc., but none of the other log files, including history.log.0 (what is displayed in the History tab) are updating. I don't see that logs are being generated in another directory so I guess they are disabled now (other than app.log).

The my.service.xml file has this section:
<backupFilesLog>
<fileHandler append="true" count="2" level="ALL" limit="26214400" pattern="log/backup_files.log"/>
</backupFilesLog>
<restoreFilesLog>
<fileHandler append="false" count="1" level="ALL" limit="1073741824" pattern="log/restore_files.log"/>
</restoreFilesLog>



but I don't see a restore_files.log file anywhere even after doing a restore.

I'm not sure what's up, but history is not high priority for me. As long as the backups and restores work, I'm generally happy. That said, anyone have any other ideas?

Thanks,
Eric
 

Eric Katz

Cadet
Joined
Jan 16, 2015
Messages
5
I am observing the same behavior with the logs. Not a show stopper, but would be nice to figure out what is going on.
 

Klox

Dabbler
Joined
Sep 29, 2013
Messages
21
I went down a similar path @mastax. I basically went through and patched the linux-crashplan to install the latest 4.5. Below are the modified files:

/usr/ports/sysutils/linux-crashplan/Makefile
# Created by: William Grzybowski <wg@FreeBSD.org>
# $FreeBSD: head/sysutils/linux-crashplan/Makefile 393474 2015-08-03 15:53:52Z wg $

PORTNAME= linux-crashplan
DISTVERSION= 4.5.0
CATEGORIES= sysutils linux
MASTER_SITES= http://download.crashplan.com/installs/linux/install/CrashPlan/
DISTNAME= CrashPlan_${DISTVERSION}_Linux

MAINTAINER= subtil@gmail.com
COMMENT= Backs up data to remote servers or hard drives

RUN_DEPENDS= java:${PORTSDIR}/java/openjdk8-jre \
bash:${PORTSDIR}/shells/bash

WRKSRC= ${WRKDIR}/crashplan-install

USE_LINUX= yes
USE_LINUX_APPS= expat fontconfig xorglibs
USE_RC_SUBR= crashplan
USES= shebangfix tar:tgz

SHEBANG_FILES= scripts/CrashPlanEngine scripts/CrashPlanDesktop

ONLY_FOR_ARCHS= i386 amd64

NO_BUILD= yes

CRASHDIR= ${PREFIX}/share/crashplan

do-install:
@${MKDIR} ${STAGEDIR}${CRASHDIR}
cd ${STAGEDIR}${CRASHDIR} && ${CAT} ${WRKSRC}/CrashPlan_${DISTVERSION}.cpi | ${GZIP_CMD} -d -c - | ${CPIO} -i --no-preserve-owner
${INSTALL_SCRIPT} ${WRKSRC}/scripts/CrashPlanDesktop ${STAGEDIR}${PREFIX}/bin/
${INSTALL_SCRIPT} ${WRKSRC}/scripts/CrashPlanEngine ${STAGEDIR}${CRASHDIR}/bin/
${CP} ${WRKSRC}/scripts/run.conf ${STAGEDIR}${CRASHDIR}/bin/
${ECHO_CMD} > ${STAGEDIR}${CRASHDIR}/install.vars
${ECHO_CMD} "TARGETDIR=${CRASHDIR}" >> ${STAGEDIR}${CRASHDIR}/install.vars
${ECHO_CMD} "BINSDIR=${CRASHDIR}/bin" >> ${STAGEDIR}${CRASHDIR}/install.vars
${ECHO_CMD} "JAVACOMMON=${LOCALBASE}/bin/java" >> ${STAGEDIR}${CRASHDIR}/install.vars
${CAT} ${WRKSRC}/install.defaults >> ${STAGEDIR}${CRASHDIR}/install.vars

.include <bsd.port.mk>

/usr/ports/sysutils/linux-crashplan/pkg-plist
bin/CrashPlanDesktop
etc/rc.d/crashplan
share/crashplan/app.asar
share/crashplan/bin/CrashPlanEngine
share/crashplan/bin/restartLinux.sh
share/crashplan/bin/run.conf
share/crashplan/bin/uninstall.sh
share/crashplan/conf/custom_sample.properties
share/crashplan/conf/default.service.xml
share/crashplan/conf/service.log.xml
share/crashplan/conf/ui.log.xml
share/crashplan/conf/ui.properties
share/crashplan/conf/upgradeui.log.xml
share/crashplan/conf/upgradeui.properties
share/crashplan/doc/readme.html
share/crashplan/doc/readme.odt
share/crashplan/doc/readme.pdf
share/crashplan/doc/readme.rtf
share/crashplan/install.vars
share/crashplan/lang/txt.properties
share/crashplan/lang/txt_de.properties
share/crashplan/lang/txt_en_GB.properties
share/crashplan/lang/txt_en_US.properties
share/crashplan/lang/txt_es.properties
share/crashplan/lang/txt_es_ES.properties
share/crashplan/lang/txt_fr.properties
share/crashplan/lang/txt_it.properties
share/crashplan/lang/txt_ja.properties
share/crashplan/lang/txt_ko.properties
share/crashplan/lang/txt_nl.properties
share/crashplan/lang/txt_no.properties
share/crashplan/lang/txt_pt_BR.properties
share/crashplan/lang/txt_sv.properties
share/crashplan/lang/txt_th.properties
share/crashplan/lang/txt_zh.properties
share/crashplan/lang/txt_zh_TW.properties
share/crashplan/lib/bcpkix-jdk15on.jar
share/crashplan/lib/bcprov-jdk15on.jar
share/crashplan/lib/c42_protolib_shared.jar
share/crashplan/lib/com.backup42.desktop.jar
share/crashplan/lib/comfyj-2.10.jar
share/crashplan/lib/commons-beanutils-core.jar
share/crashplan/lib/commons-cli-1.2.jar
share/crashplan/lib/commons-codec.jar
share/crashplan/lib/commons-collections.jar
share/crashplan/lib/commons-io.jar
share/crashplan/lib/commons-jxpath-1.1.jar
share/crashplan/lib/commons-lang.jar
share/crashplan/lib/commons-logging.jar
share/crashplan/lib/ezmorph.jar
share/crashplan/lib/gson.jar
share/crashplan/lib/guava.jar
share/crashplan/lib/javassist-3.20.0.jar
share/crashplan/lib/jetty-continuation-9.2.9.v20150224.jar
share/crashplan/lib/jetty-http-9.2.9.v20150224.jar
share/crashplan/lib/jetty-io-9.2.9.v20150224.jar
share/crashplan/lib/jetty-security-9.2.9.v20150224.jar
share/crashplan/lib/jetty-server-9.2.9.v20150224.jar
share/crashplan/lib/jetty-servlet-9.2.9.v20150224.jar
share/crashplan/lib/jetty-servlets-9.2.9.v20150224.jar
share/crashplan/lib/jetty-util-9.2.9.v20150224.jar
share/crashplan/lib/jna-platform.jar
share/crashplan/lib/jna.jar
share/crashplan/lib/jniwrap.jar
share/crashplan/lib/jniwrapper-macpack.jar
share/crashplan/lib/jniwrapper-winpack.jar
share/crashplan/lib/joda-time.jar
share/crashplan/lib/json-lib.jar
share/crashplan/lib/json.jar
share/crashplan/lib/jtux.jar
share/crashplan/lib/log4j-api.jar
share/crashplan/lib/log4j-core.jar
share/crashplan/lib/log4j-iostreams-2.3.jar
share/crashplan/lib/log4j-jcl-2.1.jar
share/crashplan/lib/log4j-slf4j-impl.jar
share/crashplan/lib/miglayout15-swt.jar
share/crashplan/lib/org.eclipse.core.commands_3.6.1.v20120814-150512.jar
share/crashplan/lib/org.eclipse.equinox.common_3.6.100.v20120522-1841.jar
share/crashplan/lib/org.eclipse.jface_3.8.101.v20120817-083647.jar
share/crashplan/lib/org.eclipse.osgi_3.8.1.v20120830-144521.jar
share/crashplan/lib/protobuf-java.jar
share/crashplan/lib/reflections-0.9.10.jar
share/crashplan/lib/rhino.jar
share/crashplan/lib/sbbi-upnplib.jar
share/crashplan/lib/servlet-api-3.1.jar
share/crashplan/lib/slf4j-api.jar
share/crashplan/lib/sqlite-jdbc.jar
share/crashplan/lib/swt-64.jar
share/crashplan/lib/swt.jar
share/crashplan/lib/tika-core-1.7.jar
share/crashplan/lib/trove.jar
share/crashplan/lib/twitter4j.jar
share/crashplan/lib/websocket-api-9.2.9.v20150224.jar
share/crashplan/lib/websocket-common-9.2.9.v20150224.jar
share/crashplan/lib/websocket-server-9.2.9.v20150224.jar
share/crashplan/lib/websocket-servlet-9.2.9.v20150224.jar
share/crashplan/libjniwrap.so
share/crashplan/libjniwrap64.so
share/crashplan/libjtux.so
share/crashplan/libjtux64.so
share/crashplan/libmd5.so
share/crashplan/libmd564.so
share/crashplan/skin/icon_app_128x128.png
share/crashplan/skin/icon_app_16x16.png
share/crashplan/skin/icon_app_32x32.png
share/crashplan/skin/icon_app_64x64.png
share/crashplan/skin/logo_main.png
share/crashplan/skin/skin.properties
share/crashplan/skin/splash_default.png
share/crashplan/skin/splash_plus.png
share/crashplan/skin/window_bg.jpg
share/crashplan/upgrade/start.bat
share/crashplan/upgrade/start.sh
share/crashplan/upgrade/startDesktop.bat
share/crashplan/upgrade/startDesktop.sh
share/crashplan/upgrade/startDesktopLinux.sh
share/crashplan/upgrade/startDesktopSolaris.sh
share/crashplan/upgrade/startFirst.sh
share/crashplan/upgrade/startLinux.sh
share/crashplan/upgrade/startSolaris.sh
@dir share/crashplan/log
@dir share/crashplan/upgrade/UpgradeUI

/usr/ports/sysutils/linux-crashplan/distinfo
SHA256 (CrashPlan_4.5.0_Linux.tgz) = 8a3ca9c01bf55051223f4f40e7dc086244fa07ea724a9f5d4552cf2752ad157b
SIZE (CrashPlan_4.5.0_Linux.tgz) = 44356534

Notable features:
  • CrashPlan 4.5.0
  • Using OpenJDK8-jre (no need to download any separate installer
Steps for connecting to headless server:
  1. While crashplan is running, look at /var/lib/crashplan/.ui_info
  2. Copy the port and key to client.
  3. Append to your client .ui_info the ip address of the remote server (e.g., "<PORT>,<KEY>,<SERVER IP>")
With the above, you should be able to connect to the headless server.

Now for my specific problem: I cannot see my file system in the CrashPlan client. I open up the file selector and it just says "loading...". I've tried changing my mount points to /compat/linux/mnt. I am also manually mounting /compat/linux/proc after startup since it seems FreeNAS 9.3 doesn't support the linprocfs flag (I saw a patch that 10 will?).

If anyone identifies the fix for above please let me know. After that I'll submit a patch to the linux-crashplan maintainer for the latest.

edit: Some other helpful commands during the install:

portsnap fetch extract
portsnap fetch update && pkg upgrade

echo "compat.linux.osrelease=2.6.18" >> /etc/sysctl.conf
sysctl compat.linux.osrelease=2.6.18

sysrc crashplan_enable=YES
sysrc linux_enable=YES

cat /var/lib/crashplan/.ui_info ; echo

mount -t fdescfs fdesc /dev/fd
mount -t procfs proc /proc
mount -t linprocfs linproc /compat/linux/proc/

edit: Now I noticed in the service.log.0 output that my .identity file is not being written, so each startup is showing as a separate jail in crashplan. I get both unable to load and unable to store errors. Most likely still an issue with the file system and permissions.

[01.09.16 12:53:46.731 INFO main om.backup42.service.IdentityInfo] BEGIN GUID assignment
[01.09.16 12:53:46.732 WARN main om.backup42.service.IdentityInfo] Unable to load computer identity. Not implemented on null, com.code42.exception.DebugException: Not implemented on null
STACKTRACE:: com.code42.exception.DebugException: Not implemented on null
at com.backup42.service.IdentityInfo.<init>(IdentityInfo.java:204)
at com.backup42.service.CPService.start(CPService.java:496)
at com.backup42.service.CPService.main(CPService.java:2239)

[01.09.16 12:53:46.734 INFO main om.backup42.service.IdentityInfo] GUID created! guid=724134886161708707
[01.09.16 12:53:46.734 WARN main om.backup42.service.IdentityInfo] Unable to store computer identity. Not implemented on null, com.code42.exception.DebugException: Not implemented on null
STACKTRACE:: com.code42.exception.DebugException: Not implemented on null
at com.backup42.service.IdentityInfo.save(IdentityInfo.java:451)
at com.backup42.service.IdentityInfo.<init>(IdentityInfo.java:228)
at com.backup42.service.CPService.start(CPService.java:496)
at com.backup42.service.CPService.main(CPService.java:2239)
 
Last edited:

Slovak

Explorer
Joined
Sep 10, 2013
Messages
62
@Paul Suh I've gotten a manually-upgraded version of Crashplan 4.5.0 to work.

Here's the steps I followed:
  1. Follow the guide to step 6, except install Crashplan 4.5.0 on the 'client' computer (DO NOT log in).
  2. On the Freenas, in a shell to the crashplan_1 jail, download and extract the Crashplan Linux 4.5.0 installer.
    Code:
    su -
    cd /usr/pbi/crashplan-amd64/share/crashplan
    wget --no-check-certificate http://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.5.0_Linux.tgz
    tar -xf CrashPlan_4.5.0_Linux.tgz
    cd crashplan-install
    cpio -idv < CrashPlan_4.5.0.cpi
  3. Stop the crashplan service
    Code:
    service crashplan stop
  4. Replace the libraries
    Code:
    cd ..
    rm -r lib*
    cp -r crashplan-install/lib* .
  5. Start the crashplan service
    Code:
    service crashplan start
  6. Follow the Crashplan Headless Guide, but make sure to make .ui_info read only on the client computer or it will be overwritten.
  7. Restart the crashplan service on the client computer and log in to the crashplan UI.
Edit:
8. Restart the Freenas (or at least the jail). I didn't do this initially and I thought it was working but it wouldn't restore properly.


Brilliant. I've had 2 FreeNAS boxes running 4.3.3 and since it wasn't giving me an issue, I just let it go without updating. The limitation was that I was unable to connect to the system remotely via GUI due to the 4.5.0 (GUI) to 4.3.3 (FreeNAS) version mismatch. Just made do without. Until today, when I thought I absolutely needed GUI access. Your steps fixed me right up (along with editing my.service.xml on FreeNAS - it got reset to localhost only connections with the upgrade), and after editing ui.properties and .ui_info files on the remote client, I connected without issues.

Second lesson learned - logging into CrashPlan online to manage the account provides many relevant functions that one would want to perform via GUI. Effectively, it's a cloud version of the GUI allowing granular configuration changes on any client associated with the account. Once the FreeNAS is up and running and registered to the account, all management can take place via web.
 

Greg Harvey

Cadet
Joined
Jan 18, 2016
Messages
4
The mastax post worked for me too, I guess this is a relatively new problem. Long version, in case it helps people Google this thread:

I had a stock plugin jail with CrashPlan 3.6.3 installed, if I installed the 3.6.3 *client* on my laptop all was fine (on Fedora here, Linux 3.6.3 client is available still from Code42 but I won't link - it's worthless, because...) but I discovered CrashPlan quite deliberately updates the client and *then* the server - so you install an older client, next time you restart it updates itself to 4.5.2 and you get the disconnection errors talked about at the start of the thread. (In fact, you don't get that far unless you edit .ui_info and remove the IP address 4.5.2 added to it that 3.6.3 doesn't know how to handle.) So the client cannot connect to kickstart the update of 3.6.3 on the FreeNAS and you're stuck. You can downgrade your client again and carry on, but next time you restart the client the same thing will happen all over. PITA!

Nothing in the FreeNAS logs, slight clue in ui_output.log indicating some kind of incompatibility in the handshake but the server doesn't detect a problem - just a client that doesn't stick around. Weirdly though, double-click the CrashPlan logo on the login screen with 4.5.2 connecting to a 3.6.3 server and the command line version actually works! You can get 3.6.3 to give you back version details, restart, etc. etc. It just falls over as soon as you login. Actual log errors (again, for Google):

Code:
[01.17.16 18:38:54.818 WARN MQ-UI-0 .messaging.nio.MessageConnection] Error building message: Unable to deserialize TargetComputerUsagesMessage, invalid stream header: 1F8B0800, TargetComputerUsagesMessage[725286975080986698]
[01.17.16 18:38:54.821 ERROR MQ-UI-0 ode42.messaging.nio.MessageQueue] Caught exception handling message(s)! Closing session=Session[id=725286975080986698, closed=false, isAcceptor=false, remoteIdentity=ENDPOINT, completedAuth=false, lat=2016-01-17T18:38:54:497, lrt=2016-01-17T18:38:54:497, lwt=2016-01-17T18:38:53:408, #pending=4, enqueued=false, local=192.168.0.33:40680, remote=192.168.0.8:4243, usingProtoHeaders=false, usingEncryptedHeaders=false, LAN], MessageWorker[MQ-UI-0, handling = true, handlingStartTime = 1453052334496, waitingStartTime = 1453052329898, handlingTime = 11, waitingTime = 9993, totalNumMessages = 3, numMessagesSinceLast = 3], com.code42.exception.DebugException: Caught exception handling message(s)! Closing session=Session[id=725286975080986698, closed=false, isAcceptor=false, remoteIdentity=ENDPOINT, completedAuth=false, lat=2016-01-17T18:38:54:497, lrt=2016-01-17T18:38:54:497, lwt=2016-01-17T18:38:53:408, #pending=4, enqueued=false, local=192.168.0.33:40680, remote=192.168.0.8:4243, usingProtoHeaders=false, usingEncryptedHeaders=false, LAN], MessageWorker[MQ-UI-0, handling = true, handlingStartTime = 1453052334496, waitingStartTime = 1453052329898, handlingTime = 11, waitingTime = 9993, totalNumMessages = 3, numMessagesSinceLast = 3], 7177, Session[ sessionId=725286975080986698, isDirect=false, remoteIdentity=ENDPOINT], java.nio.HeapByteBuffer[pos=0 lim=599 cap=599], MessageHeader [messageId=7177 length=599 options=0000 nonce=00000000 MAC=00000000 payloadEncrypted=false compressed=false useMac=false useNonce=false headerEncrypted=false]
STACKTRACE:: com.code42.exception.DebugException: Caught exception handling message(s)! Closing session=Session[id=725286975080986698, closed=false, isAcceptor=false, remoteIdentity=ENDPOINT, completedAuth=false, lat=2016-01-17T18:38:54:497, lrt=2016-01-17T18:38:54:497, lwt=2016-01-17T18:38:53:408, #pending=4, enqueued=false, local=192.168.0.33:40680, remote=192.168.0.8:4243, usingProtoHeaders=false, usingEncryptedHeaders=false, LAN], MessageWorker[MQ-UI-0, handling = true, handlingStartTime = 1453052334496, waitingStartTime = 1453052329898, handlingTime = 11, waitingTime = 9993, totalNumMessages = 3, numMessagesSinceLast = 3], 7177, Session[ sessionId=725286975080986698, isDirect=false, remoteIdentity=ENDPOINT], java.nio.HeapByteBuffer[pos=0 lim=599 cap=599], MessageHeader [messageId=7177 length=599 options=0000 nonce=00000000 MAC=00000000 payloadEncrypted=false compressed=false useMac=false useNonce=false headerEncrypted=false]


Smoking gun in there, I believe, is "Unable to deserialize TargetComputerUsagesMessage", hence my comments about some handshake problem.

Anyway, long story short is the 4.5.x client simply *cannot* update the 3.6.3 server, but mastax's instructions above work fine. The only additional thing I did was copy the encryption key in .ui_info on the FreeNAS back to the client so they match, and set the IP in the same file to 192.168.0.8 (the IP of the FreeNAS on my LAN, of course).

You'll note I'm not doing all that SSH tunnelling malarkey. There's no need to, just set the IP address of the server machine in .ui_info and ui.properties on the client machine and your local client will connect on the usual ports.
 

stualden

Explorer
Joined
Apr 11, 2015
Messages
80
I see that this thread started as a way to get the FreeNAS CrashPlan plugin to move off its original version (3.6.3). I am trying to find out if it's also a workable solution to the problem we heard about via email from Code42:

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.



In other words, because of the old Linux kernel, FreeNAS CrashPlan won't update on its own past 4.4.1.

I have been using a local Windows CrashPlan 4.4.1 client as the head for my 4.4.1 FreeNAS CrashPlan server. I've been backing up FreeNAS to a remote Windows CrashPlan 4.4.1 on a VPN. Three days ago, the remote CrashPlan updated itself to latest version (4.5.2), which brought the whole thing to a halt.

So, my questions (and sorry for my obvious Linux ignorance):

--Is mastax's method a reliable way to install the latest version of CrashPlan (not just 4.5.0) onto FreeNAS? Is it essentially updating the kernel in the Linux emulator, thereby sidestepping the limitation described by Code42?

--Once this fix is made, should subsequent versions of CrashPlan on FreeNAS update automatically, now that it appears that a newer kernel is in place? Or will the update need to be done manually each time in the same fashion?
 

Greg Harvey

Cadet
Joined
Jan 18, 2016
Messages
4
Well FreeNAS is based on FreeBSD, not Linux, so it doesn't have Linux kernel at all. It has FreeBSD kernel, which is different. Whether this affects that, I couldn't tell you. Code42 probably couldn't tell you either, as they don't officially support FreeBSD at all, I don't think?! Anyway, the FreeNAS kernel is FreeBSD 9.3-RELEASE-p31 on my box, and CrashPlan 4.5.0 runs just fine, so whatever libraries and kernel features it needs are evidently there. Kernel version is probably not what's stopping your FreeNAS CrashPlan updating, it's likely something else entirely. Or rather, Linux kernel version can't be. It could be Code42 have written in some application logic now that stops automatic update if it the kernel is unsupported (as it surely would be with FreeBSD/FreeNAS) which, on balance, is probably a good thing. I'd still prefer to have the option to manually make CrashPlan attempt an auto-update, but hey ho. Anyway, I'm guessing here! Your questions:

--Is mastax's method a reliable way to install the latest version of CrashPlan (not just 4.5.0) onto FreeNAS? Is it essentially updating the kernel in the Linux emulator, thereby sidestepping the limitation described by Code42?

I am assuming here you're doing things "the usual way" and running CrashPlan in a jail - not in a VirtualBox Linux VM or something like that - in which case there is no "Linux emulator". The jail is FreeBSD-based, just like the base system.

Edit: I re-read mastax's instructions, I got confused because there's a version of 4.5.0 available on the FreeBSD website which I thought I'd used, so what I wrote previously is wrong. Apologies! I didn't actually try it, but I see mastax pulled the Linux version from the Code42 website. I'd expect 4.5.2 to work fine, since 4.5.0 does - just pull the latest package. In fact, I think I'll do this myself now. :)



--Once this fix is made, should subsequent versions of CrashPlan on FreeNAS update automatically, now that it appears that a newer kernel is in place? Or will the update need to be done manually each time in the same fashion?

Good question. My 4.5.0 server doesn't seem to be updating itself, so it seems not. Certainly in my case, CrashPlanEngine is not self-updating to 4.5.2 after I installed 4.5.0. I don't particularly care about this as long as 4.5.0 continues to work with the latest client, and I'm not sure why it wouldn't auto-update if previous versions always did... As I said above, if I were to guess I'd bet Code42 have introduced something into the application to suppress risky auto-update on unsupported systems. :cool:

HTH!
 
Last edited:

Greg Harvey

Cadet
Joined
Jan 18, 2016
Messages
4
Right, I thought I'd just do this and I can confirm - mastax's method is just fine with 4.5.2 as well, simply replace 4.5.0 with 4.5.2 in all steps and it installs and runs - here's the output from the CLI tool in the GUI for the `version` command:

Code:
4.5.2 - 1435726800452 (2015-07-01T05:00:00:452+0000) - Build: 78


Yay! :D
 

stualden

Explorer
Joined
Apr 11, 2015
Messages
80
Very good, thank you, I think I will give it a try!

I am fully aware that FreeNAS is based on FreeBSD. I mentioned Linux because it was my understanding (perhaps wrong) that the FreeNAS CrashPlan plugin was developed by taking the Linux CrashPlan program (written and updated regularly by Code42) and running it in a Linux emulator. Is that not true?

I also had concluded (again, perhaps incorrectly) that my FreeNAS CrashPlan, which has updated itself regularly all the way from the initial 3.6.3 to the current (for me) 4.4.1, was no longer updating itself due to the fact that the Linux emulator in which it was running was (from Code42's viewpont) too old to be updated past 4.4.1. There are other threads in this forum on this topic as well, and I believe others have had similar experiences.

I can probably live with manual updates to the FreeNAS CrashPlan every time my Windows CrashPlan updates itself - at least until I find something better than CrashPlan (which I haven't yet).

Thanks again.
 

Greg Harvey

Cadet
Joined
Jan 18, 2016
Messages
4
I am fully aware that FreeNAS is based on FreeBSD.

Right, sorry! Didn't mean to condescend in any way! :)

... running it in a Linux emulator. Is that not true?

From what I've read, no. And also, if you open a jail terminal in the FreeNAS GUI (or SSH in to a jail) and do uname -a you get a FreeBSD kernel, not a Linux one. I think it's simply compatible with FreeBSD kernel, although not supported officially. I might be wrong here, but everything I know points to a jail just being a kind of FreeBSD VM - sort of like a FreeBSD version of Docker.

I also had concluded (again, perhaps incorrectly) that my FreeNAS CrashPlan, which has updated itself regularly all the way from the initial 3.6.3 to the current (for me) 4.4.1, was no longer updating itself due to the fact that the Linux emulator in which it was running was (from Code42's viewpont) too old to be updated past 4.4.1.

I believe it has stopped updating, I can see that. But I suspect the cause is something different. Might be worth asking Code42 directly if they now stop auto-updates on unknown/unsupported systems, because that would be my hunch. The code looks up the kernel details, sees it's not Linux, stops. That's a total guess, but I think it's more likely than compatibility issues, as it's stopped in places where there are apparently no compatibility issues as well.

Cheers,

Greg
 
Status
Not open for further replies.
Top