CrashPlan Community Forum – Support & Assistance

CrashPlan 4.8.2 Installation Fix for Synology (1436674800482_4 April 2017)

Affiliate Links

NEW for CrashPlan for Small Business users: note that the correct package paths will now begin with ´/var/packages/CrashPlanPRO/…´.


Following up the discussion on this thread from our forums, here’s what I’ve gathered about this new version upgrade. FYI the auto-upgrade block procedure continues to work just fine, preventing CrashPlan from breaking inadvertedly.

Edit: use this to whenever possible to follow the log tail in realtime:

tail -f /var/packages/CrashPlan/target/log/service.log.0

Solution 1 (Dedicated Java install):

Considering I’ve been experiencing some server timeouts while CrashPlan is running, when accessing my DS412+, I chose to use the dedicated install instead, to see if that makes a difference. It worked and upgraded fairly easily to 4.8.2 and it is now synchronising (without any adoption). Here goes:

  1. Take note of your current Java Heap size (issue java mx on your client’s CLI)
  2. Using terminal, copy cpio:
    sudo cp /volume1/@appstore/CrashPlan/bin/cpio /bin/cpio
  3. Place the Java SE Runtime file in your public share (you need a Oracle login to get it from here, the latest version of patters’ package requires not the latest Java package, but version 8u121: jre-8u121-linux-x64.tar.gz)
  4. Uninstall CrashPlan using DSM Package Manager
  5. Install CrashPlan using DSM Package Manager and disable the “Run after installation” checkbox.
  6. Wait a moment and try to run it (in my case it wouldn’t run so I uninstalled/reinstalled one more time). A good option is to check the tail log, as suggested at the beginning of this post, for “Upgrade complete” and related messages.
  7. You can read the real time log with terminal open:
    tail -f /var/packages/CrashPlan/target/log/service.log.0
  8. You should see the install script starting the upgrade and finishing with “Service stopped normally”.
  9. Wait a moment and try to run the package again; if it fails, wait some more time and run again. The tail log should now show lots of output, which means it’s running.
  10. After this, don’t forget:
    1. Change the .ui_info file contents, using this guide. Note that this first time the headless .ui_info may be ending in – this means that the next time you restart CrashPlan it will change, and then showing the correct headless server IP.
    2. Check if the GUI is properly connecting and login
    3. Change your Java Max Heap size if necessary, using this guide (Solution 2 for persistence) and restart
    4. Verify your .ui_info connection info again – it may have been broken after the restart
  11. You may now block the auto-upgrade process, using this guide
  12. Check if the GUI is properly connecting.


Solution 2 (built-in Java install), quote from user @krachvik ‘s experience:

  1. Uninstalled Crashplan
  2. Confirmed Built-In Synology Java8 is installed
  3. Reinstalled Crashplan
    1. chose Built-in Java (NOT dedicated)
    2. unchecked the option to start service upon completion)
  4. Disabled Auto-update process
  5. Connected to the Crashplan server from client and logged on using my credentials at which point it said “Updating client” but nothing happened because it couldn’t update (auto-update is disabled)
    1. did not close the client window (reused at step 8)
  6. Re-enabled Auto-update process
  7. Plugged in my credentials again at the client windows I already had opened
  8. Crashplan window came up
    2. while the client window was still up, double clicked the Crashplan logo and typed in “java mx 1536, restart” as per An’s suggestion
  9. Crashplan service stopped
  10. Started Crashplan service
    1. was informed it failed
  11. Started Crashplan again and this time it stayed running

Thanks for all the feedback and help. I suppose I’ll be back when it fails again.



16 comments for “CrashPlan 4.8.2 Installation Fix for Synology (1436674800482_4 April 2017)

  1. Gino Verhulst
    May 20, 2017 at 06:07

    Hi all,

    I’m trying to get this to work for some time now, but I’m still not there 100%

    I’ve re-installed patters 4.8.0 and blocked the upgrade, which is working ok.
    I can connect from my Mac to the Synology package, but when I login I get the message “Crashplan Upgrading” and nothing else happens.

    Is the update to 4.8.2 required to get it tow work again ?

    I tried that als well, but the upgrade doesn’t go well.
    In the log it says the Upgrade completed, but restarting the Crashplan package afterwards doesn’t work. It will not run.
    Also there is no upgrade jar file or anything to be found when looking for it with terminal.

    If anybody can be of assistence, that would be awesome.

    • an
      May 20, 2017 at 09:38

      If it says “CrashPlan upgrading” it probably isn’t blocked. But in any case, the idea here is to allow CrashPlan to complete the upgrade and after it is running 4.8.2 block the auto-upgrade so that it doesn’t break inadvertedly. And yes, I do think you have to upgrade in order to keep it going. Try reinstalling it a couple of times, give it time for the upgrade, anddon’t forget to check both the java heap (if your dataset is large) and the ui_info file – it changes a lot. It will eventually kick in.

      • Gino Verhulst
        May 22, 2017 at 07:46

        Hi an,

        OK, I’ll give it another try tonight or tomorrow and post back here should I run into problems.

        Thanks for the tip.

      • Gino Verhulst
        May 29, 2017 at 14:10

        Just to give an update on the status : Working Fine again.
        Giving it a little more time to finish the upgrade is what was required, alhtough it said upgrade complete…

        Still have to check the Java heap

        Thanks again for your assistence.

  2. Alok
    June 18, 2017 at 04:32

    Crashplan service on synology got upgraded to 4.8.3 (on 15th june 2017) and it cannot start anymore. Do we have any fix for this yet? I forgot to disable auto upgrades earlier.

    • an
      June 18, 2017 at 15:52

      I’ve noticed the auto-upgrade process warning on my main instance, but haven’t delved into it so far. have you tried any of the solutions of this particular article? Unless they changed something significantly, solution 1 should work to get you back up to speed. Do report back, please, if you happen to try it. Cheers

      • Alok
        June 18, 2017 at 16:03

        yes, the old steps worked for me. i uninstalled and reinstalled Crashplan. This time i disabled autoupgrade. copied ui info. Everthing started working after that.

        • an
          June 18, 2017 at 16:08

          Great. Thanks for the update

          • Alok
            June 21, 2017 at 15:00

            there seems to be an issue after that. i am going to look into this on weekend. Initially my desktop client was not able to connect the cp service on synology. I upgraded my desktop client to latest version (4.8.3). Now the client starts up and i think it is connecting… but shows no backup selected. All my configuration is empty. need to investigate further now.

          • an
            June 21, 2017 at 15:39

            That is most likely because of the .ui_info file configuration is not correct:

  3. max
    June 20, 2017 at 09:24

    Crashplan tried to upgrade from 4.8.2 to 4.8.3 and broke. I was able to get it working again by reinstalling and blocking the upgrade. However it appears to be unhappy about not being able to upgrade. Every time I unblock the upgrade and allow it to proceed crashplan will no longer start.

    I don’t understand how blocking up upgrade helps. Or how to get the upgrade to work.

    Do you block the auto upgraded so you can set aside the time to working on installing the upgrade? Knowing that it will take a few goes of uninstalling, reinstalling blocking unblocking and repeating till you get it to work?

    I did this about 4 times last night. Each time was the same, the install works. The upgrade fails.


    • an
      June 20, 2017 at 09:36

      In my case, I prefer to have the auto-upgrade blocked in part because I can decide when to actually do the upgrade and that way (most of the time) there is a graceful period without Crashplan not being working. When you maintain more than one CrashPlan instance it starts to make a lot more sense.
      Then there’s the fact that in the past we’ve spent days, into weeks, without crashplan working after breaking from the auto-upgrade process, because we didn’t have a working solution that would allows to upgrade – and that might happen again anytime in the future. Having it in place allows us to wait for a proper solution to be tested and make sure we can upgrade knowing it will work afterwards.

  4. an
    June 21, 2017 at 15:40

    Please have a look at the most recent thread about this issue, in case you’re having troubles with the fix:

Leave a Reply

Here's what other Users are reading:

Affiliate Links