10 comments on “Crashplan on headless QNAP installation starts failing after auto-update.

  1. Hello,
    here same kind of issue.
    3.7.0.34 want to update, but can not complete.
    Your procedure did work in the past, but not with this update.

    Any solution for this version?

    Thx

  2. Pingback: Warmfuzzyland » Archives » Fixing CrashPlan failing auto-updates for a headless QNAP installation

  3. Great post! Saved my day 🙂

    Just whish QNAP would incorporate this update feature into the package instead of us having to fudge around in the filesystem.

    Thanks a million phatdee c”,)

  4. I found another way…

    Looking in the upgrade.log file, I found that the upgrade script was failing because the BusyBox Linux distro doesn’t know what the -v switch is for the mv and rm commands. By editing the ‘upgrade.sh’ script in the numbered upgrade folder that you reference above and removing the -v option for those commands, I could run the ‘upgrade.sh’ script manually successfully. I did have to restart the CP service after the script was complete, however.

    In the ‘upgrade.sh’ script you will find the following lines near the top…

    # commands, NOTE that the options are different based on OS/shell
    RM=”rm -fv”
    MV=”mv -fv”

    Change these as follows…

    # commands, NOTE that the options are different based on OS/shell
    RM=”rm -f”
    MV=”mv -f”

    • Just got around to upgrading this crashplan Qnap package, and looks like your right on with that mod to upgrade.sh script. After removing -v it installed fine.

      Thanks Jerry nice catch.. For such a simple fix, you would think QNAP would have fixed their package by now..but looks like end users are still providing their QA for them..

  5. Have just verified the solution proposed by Jerry Attrick and I can confirm that it worked for me too…

    I had to “chmod +x upgrade.sh” after to be able to run the script… could be my fault I’m not a Linux guy :/

    Thanks both of you!

    Sincerely Stefan c”,)

  6. The upgrade to v4.3 cause a lot more trouble than the normal replace of the arguments in the upgrade.sh file:
    RM=”rm -f”
    MV=”mv -f”

    This upgrade also included a key that the client need to present to the server to connect to it and they also moved the ui.properties file to a new location, making the old one invalid 🙁

    1. The Key
    Copy the authentication key from your QNAP in this location:
    /share/MD0_DATA/.qpkg/CrashPlan/var/.ui_info
    it’s the long part after “4243,”

    We have to modify (on Windows) the following file:
    C:\ProgramData\CrashPlan\.ui_info
    it has the contents like this:
    —–File Start—–
    4243,ab1c23de-a12b-1a2b-1ab2-a123b4c5678d
    —–File End—–
    with the key from the QNAP.

    2. New location of ui.properties
    They have the ui.properties to a new location and possibly making individual property files per user that uses the CrashPlan client.

    The new files are here:
    C:\ProgramData\CrashPlan\conf\ui_(YOUR_USERNAME_ON_WINDOWS).properties
    Fx my username on this box is “test” so the file name is:
    C:\ProgramData\CrashPlan\conf\ui_test.properties
    just add the line:
    ServiceHost=192.168.1.55
    or whatever your QNAP’s IP is 😉

    Start the client and you’re good to go!

    Took me some time and reading a bunch of log files and articles on the net to find and understand this change! Hope this helps a lot of people out there

    • Thanks StefanBC/DK, haven’t had a chance to upgrade to this version yet, but thanks a million for the write-up!!

Leave a Reply

Your email address will not be published. Required fields are marked *