6,692 thoughts on “CrashPlan packages for Synology NAS”

1. Sam October 8, 2015 at 00:23

   Ugh. I just had a double disk crash and lost my volume completely (I had 1 disk redundancy but not 2).
   Luckily its all backed up on Crashplan! But…….all of my applications were corrupted and all had to be repaired. Crashplan has disappeared. Cant see it anywhere. Its not available to re-download in the package store.
   I assume something got corrupted and my NAS is confused. How do I do a manual download and install to get it back again (and get my 800GB of data back!).

   Reply ↓
2. Singularity October 8, 2015 at 04:06

   And they changed it once again! Anyone login to their NAS today and see how everything changed? Right now it doesn’t know that I have 3 years left on my subscription or any of my folders on my NAS… Hence the reason why I’m uploading to iDrive right now…

   Sigh..

   CrashPlan you could have been great, but instead you made it a PITA which sucks..

   Reply ↓
3. Robbert Marrink October 8, 2015 at 10:26

   I gave Crashplan another try today, based on the new information and instructions. Up and running again, very nice. It is a better backup solution compared to iDrive in my opinion. Thank you Patters for taking the time to fix the issue and inform us. I really appreciate it!

   Reply ↓
4. rwijngaa October 8, 2015 at 11:18

   And it’s broken again with the 4.4.1-0034 update. The complete package just dissappeared from my ds412+ after updating CrashPlan. I got the same as this guy:
   https://forum.synology.com/enu/viewtopic.php?f=116&t=102442&start=30#p397334

   After 4 broken updates, i think i’m looking for a better/more stable (and faster!) backup solution now. Any recommendations?

   Regards
   Rino

   Reply ↓
   1. mrizkalla October 10, 2015 at 19:28

      Same here. Any thoughts or recommendations?

      Reply ↓
5. tuxerr October 8, 2015 at 12:54

   Yesterday everything seemed to be back in order. But today when I started the client on my computer it stopped at the splash screen with the message “Cant connect to the backup engine, do you want to retry yes/no”. Logging into to the crashplan web/restore I can see the backup have bee running. Checking all settings in the ui files and guid on the synology all seems to be in order. Any ideas what I can try to get the connection back ?

   Reply ↓
   1. Robbert Marrink October 8, 2015 at 18:43

      Same thing here. After a reboot of my MacBook I’m unable to connect to the backup engine with the same message.

      Reply ↓
   2. tuxerr October 9, 2015 at 08:57

      Today the client and synology connect, and indicating the backup is running just fine :-).
      Not sure why I got the issue yesterday.

      Reply ↓
6. scontrerasStefaan October 9, 2015 at 04:07

   Was able to upgrade to 4.4.1 and get the OSX app to connect to my NAS, but looks like I lost my catalog. The app on OSX says: Last Backup: Initial Backup not completed. To Do: 0MB, Completed 0MB. How can I pickup my catalog again?

   Reply ↓
   1. scontreras October 10, 2015 at 21:12

      Also sent you a donation Patters. Thanks for all your hard work!

      Reply ↓
   2. acn November 6, 2015 at 21:13

      You might want to try checking this discussion out:
      http://crashplan.setepontos.com/forums/topic/crashplan-stopped-backing-up-solved/

      ——-
      Have a look at a forum forum I’ve created for crashplan users!
      http://crashplan.setepontos.com

      Reply ↓
7. Stanislav October 9, 2015 at 16:00

   I just wanted to add my mistake I made. I followed all the comments made by patters and all the other helpful people but I never managed to get the headless client working. And then I realized that I installed CrashPlan for ALL users on my Mac, which means, that the .ui_info file is not only under /User/Library/Application Support/Crashplan but of course (as I had installed it for all users) in /Library/Application Support/Crashplan which means NOT in my home directory. After I edited this file it worked!!! Finally!!!

   Maybe you all now shake your heads on my stupidity but maybe there are some others guys like me in the world outside who are just missing this final advice.

   Thank you patters for all your work. PayPal is coming.

   Reply ↓
   1. GeeWhiz October 10, 2015 at 06:21

      If you can assist me I’d be eternally grateful. I stopped using CrashPlan after 4.3 as it showed the drives on my NAS as Missing as I didn’t have time to troubleshoot. Now I need to get it up and running properly. I’ve updated the 4.4.1 on both Mac and DS412+ and my DS has shown me the GUID but now I need to update the file on my Mac with the GUID and I’ve hit an issue…in my /Library/Application Support/CrashPlan folder I have 1 ui file – ui_(username).properties and this file contains –

      #Sat Oct 10 07:07:49 BST 2015
      MessageDisplayed.UpgradeReminder=1444456613534
      window=422,208,800,610
      plus=true

      there is no GUID for me to update…how do I proceed from this point?

      CrashPlan is running on my DS and it also runs on my Mac but I don’t think the two are talking to each other…

      Reply ↓
8. R0n0b October 9, 2015 at 17:18

   I used to have the client on my Windows 10 system sending data to the headless server on my NAS. I used to be able to connect to either with the gui by changing the info in the ui.properties file. Now I can’t seem to get any of it to work. After doing the update on the NAS, I put the new port,guid,ip_address in my .ui_info file and now I can only connect the gui to the NAS. And the NAS shows my inbound backup (from the desktop) as disconnected. Any ideas?

   Reply ↓
9. jirikafka October 9, 2015 at 18:14

   Little update for those considering leaving CrashPlan.

   After few days of using iDrive, I am not able to recommend it anymore. Backup works on and off, Synology “app” is hacked piece of garbage, and support is just your typical indian who knows nothing about nothing. It is budget solution and it shows on all fronts.

   So I switched yet again, this time to Amazon Glacier. Finally, this solution truly looks like it wasn´t developed by trio of drunken monkeys, and the official app from Synology has worked without hickup so far. Yes, 1 TB will cost you around 2 times more than with iDrive, but you are charged only for the gigabytes you really use. So, when you need to go for 1.1 TB, you don´t have to suddenly jump to 10 TB overkill.

   I´ll keep you posted how it goes.

   Reply ↓
   1. Robbert Marrink October 9, 2015 at 18:21

      I recognize completely what you mean about iDrive. It started well, but constant disconnects from the backup server and little to no support. I tried Crashplan again after a successful re-install, but network performance seems poor and it slows my NAS down. With the added unreliability with the upgrade proces I’m looking for an alternative. I’m comparing Amazon S3 and Glacier at the moment. Haven’t decided what fits my needs the best yet.

      Reply ↓
      1. Rich October 9, 2015 at 19:23

         What I didnt understand about idrive was that it didnt seem to allow you to go back to last Wednesdays version of the file. I have some high priority stuff on S3.. but it seems to suffer from the same problem, there doesnt seem to be a way to grab last Tuesdays version of your repository. I am a little afraid of glacier. The storage is cheap but the recovery can be very expensive. If you go and ask for 300 gigs without throttling the recovery costs can be in the hundreds of dollars. Any glacier app needs to do a very specific job of throttling the recovery requests otherwise you will get a giant bill. Glacier seems to be a great solution if you wanted to archive documents in a way that you would never expect to download more then a few percent of them each month.
      2. jirikafka October 9, 2015 at 19:44

         From my Crashplan 3+ years experience, I rarely needed to retrieve more than few GB a year. Yes, A year. Its important to realize CrashPlan/Amazon are backup solutions, not your cloud drive. When I need access my files on the road, I just connect to my Synology. Or OneDrive. Or Google Disc.

         And when the catastrophe emerges, and I lose all my data? $100 for their retrieval is a trifle.
   2. andyyee October 9, 2015 at 21:41

      My concern with using Glacier is that there doesn’t seem to be a great way of restoring your data. When I last looked into it, it’ll only restore to a Synology device. Which seems to defeat the purpose of using Glacier if the reason why you’re using a restore is if your Synology device becomes damaged/corrupted.

      Reply ↓
10. Myname October 10, 2015 at 02:08

    Well, I wasted hours on this but I need to share with you how i got around the issues that many people keep having.
    – First, THANK you for all your work on this. I’ve been tempted to try the Docker version, but won’t until you tell us is good. lol.
    -Ok, so….what was the problem???? Days ago, i switched to BASH. So when the install happens or when it runs or at some weird point, things just break.
    – I tried uninstall and reinstall, etc, etc. but netstat wouldn’t show me a running service, even though package manager said it was running.
    – as soon as i commented out the bash exec from my .profile…BOOM, it worked, it installed, alllll with the default and very complete recommendations from this post (Install, start, stop, start again, modify the client so you can connect, VOILA)

    Now, i have no idea why it would break it. I put the following to prevent a lot of the bash config to occur if it wasn’t an interactive login:
    # If not running interactively, don’t do anything
    [ -z “$PS1” ] && return

    But, it still stays in BASH.
    Anyway, no idea how to fix, just SOOO happy i can start backing up again.
    I hope this helps someone.

    Reply ↓
11. Michael October 10, 2015 at 08:19

    I have managed to get the client up and running again by making the file C:\ProgramData\CrashPlan\.ui_info (Windows) read only, as every restart would set the ip back to 0.0.0.0. I have been able to adopt my previous computer and all files have synchronised, but now the client stays on “waiting for back up” and the last back up line states “initial back up not complete”. It correctly reports the amount of files waiting for back up.

    Reply ↓
    1. acn October 12, 2015 at 12:11

       There are other users, including myself with that issue; it doesn’t upload anything new.

       Reply ↓
12. glenn b October 10, 2015 at 11:26

    My 3 year old 3TB back up is gone, the client wont open on Mac, the NAS update failed, stopped backing up cos the backup is ‘gone’, the web account shows that indeed tha my backup is now gone.

    Thanks Patters for all your hard work but CrashPlan are losing it literally Perhaps it’s time to consider other options. They obviously dont like NAS users.

    Reply ↓
    1. acn October 12, 2015 at 12:09

       Don’t jump to that conclusion so quickly. After all these issues I also found my CrashPlan client reporting as if nothing had backed up, but after a ton of time re-analyzing the data set it got back to where it was.

       My issue is now is that it’s not uploading anything else, it seems stuck, but the old stuff (nearly 2Tb) is there.

       Reply ↓
       1. glenn b October 13, 2015 at 21:21

          I’m not jumping to any conclusions quickly. I have spent many days adopting, synchronising backups (3TB) only to find that they are gone. Also worth bearing in mind that the Black Friday & Christmas deals are imminent so they will get a load more new subscribers who will no doubt be ‘low impact’. Ho hum the joys of ‘business’.
       2. acn October 13, 2015 at 21:25

          You should write to them then. They don’t support headless clients but they usually pay attention to someone that loses their backup and there’s nothing to restore even on the web platform. It’s simply something that shouldn’t happen, even if your local setup screws up.
13. semperfidelis October 10, 2015 at 21:31

    I think the installation instructions for the Windows client need to be updated for v4.4.1.

    1. The ui_info is in two different locations: The locations are:
    c:\users\{user}\AppData\Local\CrashPlan\ui_info
    and
    C:\ProgramData\CrashPlan\.ui_info

    Per the instructions, I logged into the NAS as root and typed:

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

    From there I got the following:

    4243,5ffa54be-2d27-478f-be7d-445120adfb3e,0.0.0.0

    I changed the 0.0.0.0 to the local IP of the NAS and then pasted the above (with the IP change) into both ui_info files.

    2. There is now no ServiceHost line in c:\users\{user}\AppData\Local\CrashPlan\ui.properties

    I added the line with my actual ServiceHost IP but I’m not sure if I needed to.

    Bottom line is that it did not work until I added the updated ui_info data to the c:\users\{user}\AppData\Local\CrashPlan\ui_info location.

    Reply ↓
    1. Sean October 18, 2015 at 20:29

       This was the trick! I’ve been struggling for a few days to get the headless config to actually communicate and update .ui_info in the multiple locations fixed it.
       Thanks!

       Reply ↓
    2. avpman October 29, 2015 at 19:03

       I just want to clarify. Is the full file path then:
       c:\users\{user}\AppData\Local\CrashPlan\ui_info\.ui_info OR
       c:\users\{user}\AppData\Local\CrashPlan\.ui_info

       Reply ↓
14. CoachR October 11, 2015 at 00:23

    I struggled to get things working again for this latest update. I had to complete a few extra steps over and above what’s in the instructions here on the site to get the client connected.

    On the Diskstation: I had to actually edit the .ui_info file on the Diskstation (instead of just reading it to get the GUID). That file had 127.0.0.1 following the GUID and I had to change that to 0.0.0.0. After I edited the file I had to stop and restart the Crashplan package on the Diskstation. NOTE: you have to ssh in as root to change permissions/edit the .ui_info file. I changed them the file to read only when I was done.

    On the Mac: Also, as someone else mentioned in the comments, I needed to set my .ui_info file on my client to read only after changing the GUID and address. Otherwise, every time I reboot (or start the client?) the file would revert…

    Seems to be working again for me. Hopefully this helps others.

    Thanks, again, for keeping development going on this!!

    Reply ↓
    1. patters Post authorOctober 11, 2015 at 10:35

       Was yours a new installation on the Syno? I think I will amend the script to force that change to 0.0.0.0 in .ui_info

       Reply ↓
       1. barrmy October 18, 2015 at 21:30

          patters – the above (changing from 127.0.0.1 to 0.0.0.0 in .ui_info) fixed it on a syno reinstall for me, so it would be helpful to change in the script…my other DS that didn’t reinstall did not need the change
    2. pmcdonaldeditor October 31, 2015 at 11:53

       I’m getting 127.0.0.1 in the NAS file as well. I’ve changed it to 0.0.0.0 like CoachR suggested as well as the IP’s in the two Windows files with no luck. I’ve also tried setting them all to the default 127.0.0.1, no luck, to my NAS’s IP 192.168.x.x, no luck, the NAS to 127.0.0.1 and the Windows files to my NAS’s IP, no luck. I get the Crashplan splash screen hanging indefinitely. Any advice? To date following the advice to the letter has worked. Patters has done an almighty job keeping this site and package updated but Code42 are making this all a little hard for us lately…

       Reply ↓
       1. Mark November 5, 2015 at 23:12

          Hi pmcdonaldeditor,

          I’m not sure what your settings are, but here’s what’s worked for me.

          1. Make sure that Crashplan is running on both your PC and NAS.
          2. Get the contents of the ui_info file on the NAS. ssh: cat /var/lib/crashplan/.ui_info ; echo
          2a. The format of this is ..
          3. Make sure that the in this file is open on the NAS firewall.
          4. Make sure that the in this file is 0.0.0.0.
          5. Copy the and to your computer.
          6. Set your computers ui_info file to …

          Be aware that every reboot of the program on the NAS or PC will wipe this file and you will need to restore these settings. Your PC is easy, just keep a healthy copy of the file on your computer and copy it into the directory everytime you reboot. If you restart crashplan or maybe even change the settings (such as logging in under a new account after a fresh install), then a new ui_info file will be created and you’ll have to pull the new data over SSH and renew the “good” file on your computer.
       2. Mark November 5, 2015 at 23:15

          Hi pmcdonaldeditor,

          I’m not sure what your settings are, but here’s what’s worked for me.

          1. Make sure that Crashplan is running on both your PC and NAS.
          2. Get the contents of the ui_info file on the NAS. ssh: cat /var/lib/crashplan/.ui_info ; echo
          2a. The format of this is port.GUID.IPaddresss
          3. Make sure that the port in this file is open on the NAS firewall.
          4. Make sure that the IP address in this file is 0.0.0.0.
          5. Copy the port and GUID to your computer.
          6. Set your computers ui_info file to port.GUID.NAS_IPaddress

          Be aware that every reboot of the program on the NAS or PC will wipe this file and you will need to restore these settings. Your PC is easy, just keep a healthy copy of the file on your computer and copy it into the directory everytime you reboot. If you restart crashplan or maybe even change the settings (such as logging in under a new account after a fresh install), then a new ui_info file will be created and you’ll have to pull the new data over SSH and renew the “good” file on your computer.

          Edit: My previous reply was half-deleted because this website thought that I was trying to write HTML, so here is a fixed version.
15. acn October 11, 2015 at 12:57

    Even with all these issues with the upgrades, I’ve often been able to connect to the CP client, just to find that it looked like it wasn’t backing up anything, though it showed no errors.

    So given that crashplan is back running properly and I still have no new uploads actually been done, here’s the log error I found:

    [10.11.15 13:23:04.338 INFO erTimeoutWrk e42.messaging.peer.PeerConnector] PC:: Cancelling connection attempt due to timeout – pending connection=PendingConnection[timeout(ms) = 10000, startTime = Sun Oct 11 13:22:49 IST 2015, remotePeer = RemotePeer-[guid=628269892669820948, state=CONNECTING, mode=PRIVATE, location=192.168.80.21:4242, public=62.48.253.239:0, transportPbK=X509.checksum(c31e3866331e096e43ef6d962942f9e2), transportPbKRequestable=false, connecting=2015-10-11T13:22:49:446, connected=0, disconnected=2015-10-11T13:22:14:326, attempts=2, connectActivity=2015-10-11T13:22:49:446, keepAliveSent=0, minRetry=33410, retryDelay=0, reflector=na, #nat=0, session=null], sessionData = MessageConnection[ sessionInfo=null, readBuffer=com.code42.messaging.nio.MessageConnection$MessageBuffer@1682936, maxBufferSize = 65536, currentSize = 0, enqueued = false, #items = 0, Connection[7258882, state=0, context = Context@13859914[null->nullconnectionState=0], SendBufferQueue[closed=false, queueSize=0, maxSize=1310720, enqueueTimeout=60000, numItems=0, waitingCount=0, waitingPriorityCount=0, items.size()=0, priorityItems.size()=0, lastEnqueueTS=0]]]]

    A couple of things are odd: first it’s the “cancelling connection attempt due to timeout” that isn’t seen anywhere else, the other it’s the “location” field that is populated with a 192.168.80.21:4242 IP address which is unfamiliar to me (my network is under 192.168.1.x).

    The history log is just a loop of “Starting backup”:

    I 10/11/15 01:35PM Backup scheduled to always run
    I 10/11/15 01:35PM [Padrão Dias Uteis] Starting backup to CrashPlan Central: 146,689 files (730.90GB) to back up
    I 10/11/15 01:40PM Stopping CrashPlan
    I 10/11/15 01:41PM CrashPlan started, version 4.4.1, GUID 544550513805885703
    I 10/11/15 01:41PM Backup scheduled to always run
    I 10/11/15 01:42PM [Padrão Dias Uteis] Starting backup to CrashPlan Central: 146,689 files (730.90GB) to back up
    I 10/11/15 01:47PM Stopping CrashPlan
    I 10/11/15 01:48PM CrashPlan started, version 4.4.1, GUID 544550513805885703
    I 10/11/15 01:48PM Backup scheduled to always run
    I 10/11/15 01:48PM [Padrão Dias Uteis] Starting backup to CrashPlan Central: 146,689 files (730.90GB) to back up

    I can’t find any other issues, connectivity test reports as ok (NAT Trasversal Ok) and no memory warnings (I have set 1900Mb heap size). Also, CrashPlan does not consider this behavior as irregular, I don’t get any “your computer is not being backed up in X days” messages or anything like that.

    I’d be thankful for any input on this.

    Reply ↓
    1. acn October 11, 2015 at 13:37

       Ok, I’ve figured out that that log excerpt is not even important. It was there because crashplan was trying to connect to one of my old computers, listed under my account but unused for a few years now.

       The problem is that CrashPlan is still not doing any actual backups and I can’t pinpoint what’s wrong.

       Reply ↓
       1. coutch October 20, 2015 at 00:58

          I have the same exact issue. crashplan was running great from my qnap nas during the trial period, but after paying up, and upgrades, it’s not backing up anything anymore.
       2. acn October 20, 2015 at 15:07

          Yeah, but I can’t find anyone with a solution for this. I’ve written to support, even though they don’t support headless configurations and still no reply.
16. thegoose October 11, 2015 at 13:18

    I’ve given up waiting for Crashplan to be available again on my DS-415+ (it still doesn’t show up in Package Center). Fortunately I have a small reasonably inexpensive “server” (HP ProLiant MicroServer running Ubuntu linux) that I’ve already moved other services to. Getting Crashplan up and running there was straightforward, it picked up where the Synology left off, and I’m back in business.

    As an aside, I also have a single large disk in this device to backup my Synology via rsync. I put this in place after my old NAS (Netgear) had a hardware failure, and I realized that RAID storage only protected me from a drive failure. So why Crashplan? One, I’m already using it for each of my family members computers (great “family plan” w/ Crashplan), but also for offsite backup in case something happened to my house.

    Reply ↓
17. cdonnellytx76 October 11, 2015 at 21:51

    Something of a “gotcha” to be aware of for longtime (pre-5.0 days) PC LOAD LETTER package users…

    I had trouble downloading the file from Code42 because I had installed wget from ipkg, which doesn’t include builtin https support and was overriding the version the package installer was trying to use. After I uninstalled it, the default wget (which does include https support) worked, and the package installed successfully.

    While I did find that the ipkg package list includes a wget_ssl (which may or may not fix the problem), I don’t recommend using its wget anymore simply because it is out-of-date and the Synology one is “good enough”.

    Reply ↓
18. jerseygirl54 October 12, 2015 at 01:19

    I have upgraded both client and diskstation to 4.4.1. and changed ip in.ui_info and .ui_properties, but I am still unable to connect to the client. It stalls so I’m unable to change any settings. Very frustrated. Could you help me with this? I sure would appreciate it.

    Reply ↓
    1. jerseygirl54 October 12, 2015 at 23:33

       Just an update…it now works! Apparently, I missed a “0” in the GUID before the ,0.0.0.0. Once I added it, everything works! Note to self…check the numbers!
       Thanks so patters for this!

       Reply ↓
19. jbrerhel October 12, 2015 at 04:47

    My client is now seeing the Synology and everything appears to be running. But the client now automatically quits after about 15 minutes. It never finishes the initial startup scan for new changes. Is anyone else seeing this issue?

    Reply ↓
    1. Richard October 12, 2015 at 06:03

       This sounds like a “out of memory” issue
       You could split up your backup-set or increase the heap-size

       Reply ↓
       1. acn October 12, 2015 at 12:05

          I would bet that in this case it’s not an “out of memory” issue. I have the same behavior and I am positive that’s is not the issue (1.9Gb of RAM heap size, like it was set before all this). It restarts without any significant error in the logs.
       2. iNSaNe-oNe October 12, 2015 at 22:13

          Same here, my DS213j was backing up 1,5TB of files flawlessly before the 4.4.1 update, now it stops the CrashPlan package after a minute or 10-15, restarts it and loops this behavior. If you pause the backup the initial scan will eventually finish, but once started, the client just quits and it never gets past the ‘analyzing’ phase of new files to backup. It never starts sending files. Has it anything to do with the new libjna files in this release? I’m slightly disappointed by this behavior, my backups to CrashPlan are not updated anymore.
20. Tony October 12, 2015 at 08:20

    What if you are backing up to TWO Nas from one client – surely this will not work if you change the IP from 0.0.0.0?

    Reply ↓
    1. George October 12, 2015 at 09:04

       Hi Tony,
       There are two usage scenarios for Crashplan on Synology. One is backing up client files to the NAS using the CP client on your client computers (my scenario and I think yours), the other backing up NAS files to Crashplan Central (the cloud), which I think many are doing.
       In the first usage, you do not need to change the client .ui_info file IP address (mine is still 127.0.0.1 from the original install). I am backing up successfully from my client systems (Linux and Windows) to the CP engine running on the NAS. I do not backup to Crashplan Central as I use Synology Backup and Replication to copy the backup archives to external hard disks.
       The only time you need to change the IP address on the client to the IP address of the NAS is if you wish to change setting for the NAS CP engine (eg change default backup archive location after install).
       So, in your case, set up the two NAS CP instances, and once they are running, you will see them in the list of computers in the Destinations list on your client. Set up schedules as you wish for each destination and you are good to go.
       Hope this helps and that I have not misunderstood your query
       George

       Reply ↓
       1. Tony October 12, 2015 at 12:31

          Hi George,
          Thanks for swift response :-)
          We have one client and two CP headless NAS. The client was happily backing up to both until one of them updated to the new version 4.4. Now it cannot connect. Do we put *both* NAS port, guid, IP entries in the client .ui_info file?
          Cheers, Tony
       2. George October 12, 2015 at 21:11

          Tony,
          I don’t have anything to do with the NAS in my client .ui_info files, my IP addresses are 127.0.0.1 and I have not changed the GUID
          One thought, have you checked the /var/lib/crashplan/.ui_info on your NAS to confirm IP address is 0.0.0.0 rather than 127.0.0.1. Others have reported this being necessary and patters said he would update his package to set this. I did do an update from his 4.4.1 package when it became available.
          Happy hunting!
          George
       3. David October 12, 2015 at 22:48

          George. You mention IP on NAS (/var/lib/crashplan/.ui_info) needs to be 0.0.0.0 – but doesn’t it need to be changed from 0.0.0.0 to the actual NAS IP? I though that was a new requirement since the last update??
       4. George October 13, 2015 at 06:17

          David
          My understanding of the discussion on this that the NAS .ui_info file just needs 0.0.0.0 (which I think means “any IP”). That is how my NAS is setup.
          If I/you want to manage the NAS instance (eg change any CP on NAS settings), then you need to change IP in client .ui_info file to be able to connect.
21. David October 12, 2015 at 08:42

    Hi,

    Connects but not backing up ?

    Name Files Size Complete % Last Connected Last Known IP
    NAS 1087101 1.3TB 90% 3 mins xxx.xxx.xxx.xxx

    I just run crashplan as a headless client on my DS1511+. It connects OK, but back-up progress hasn’t changed from 90% since the new update came out.

    I’ve updated the ui.info file etc – any ideas ?

    Cheers

    Reply ↓
    1. acn October 12, 2015 at 12:04

       I have the same issue and found no way of solving this…

       Reply ↓
22. jack October 14, 2015 at 01:03

    For some reason the my.service.xml on the synology did not have the correct setting. I had to update it to 0.0.0.0 in order to connect to the service port. Also, would it be possible to store the uuid in .ui_info in a more permanent place and copy/overwrite it when the package is started? I’ve had to update my ui_info several times now because the file gets deleted or updated.

    Reply ↓
    1. B.Goodman October 14, 2015 at 14:33

       I stop crashplan service on my NAS nightly do the disks sleep and restart every afternoon. My port and GUID change every time the service starts! It never did this before. Now I have to edit the .ui_info on the PC daily to connect to the NAS, then in the client GUI in the PC, I change the port. EVERY DAY now!

       Reply ↓
       1. patters Post authorOctober 15, 2015 at 10:01

          That’s how I use it and I haven’t encountered that issue. Strange.
       2. B. Goodman October 16, 2015 at 01:19

          Maybe I’m wrong to say the GUID is changing. It’s the port and the number immediately after the port in the .ui_info file. Still changing every time the service starts:
          drwxr-xr-x 2 root root 4096 Jul 8 21:33 .
          drwxr-xr-x 16 root root 4096 Oct 15 15:56 ..
          -rw——- 1 root root 2360 Oct 15 16:00 .identity
          -r-xr-xr-x 1 root root 49 Oct 15 16:00 .ui_info

          See how the file on my Synology has today’s date and a time of 16:00? That is the exact time I started the service via scheduled task.
          I tried using chmod to make the file -r–r–r– and I note today it’s rx.
       3. B. Goodman October 16, 2015 at 01:29

          I found someone in a Drobo CrashPlan forum back in September asking about this very same issue:
          http://www.drobospace.com/forums/showthread.php?tid=141634&pid=192103#pid192103

          Maybe I could schedule a task to delete the existing .ui_info at 16:01 and copy a known good version back to the name .ui_info?
       4. B. Goodman October 17, 2015 at 00:57

          My scheduled task to copy the existing .ui_info file back as soon as the service restarted did not resolve my issue. I’m embarrassed to say that I started mucking around with both .ui_info and .ui_[MyUsername].properties and somehow when I thought CrashPlan was working again, it had reverted to connecting back to my local client, rather than the Synology. I then updated the .ui_info again to match the results from “cat /var/lib/crashplan/.ui_info ; echo”.

          At some point, my PC froze for a good minute, with some weird screen gibberish before finally hard crashing with a BSOD (Win 8.1). After restarting, CrashPlan connected to the Synology and suddenly the “cat /var/lib/crashplan/.ui_info ; echo” results stablized and survived a service restart on the Synology for the first time since CrashPlan 4.3.

          I gave up fighting to force the use of my chosen port and instead altered my Port Forwarding on my router to match what CrashPlan on the Synology kept insisting to use. Oddly, none of my friends’ CrashPlans were seeing my Synology as being on, though internally my PC was connecting fine. Rebooting the router didn’t help. Finally, after an hour, I rebooted the Synology and suddenly my friends’ PCs were all seeing it and starting backups.

          The moral of the story is that sometimes it’s good to be lucky?
       5. B. Goodman October 20, 2015 at 00:34

          So today I find that the port and ID have changed again. :(
    2. jbrerhel October 14, 2015 at 21:09

       How do you access and update the my.service.xml on Synology? Sorry for the NOOB question but I don’t know how to find files on the Synology (CP logs as well). Do I need to SSH in? Is there GUI for viewing and manipulating the files?

       Reply ↓
23. qriff October 14, 2015 at 07:49

    Patters, please datestamp your post and updates. There is “no way” of telling if this article/post has expired a few years ago or updated yesterday.

    Reply ↓
24. Charlie October 14, 2015 at 23:21

    Hi guys, I managed to update my Crashplan app to the latest version, with no problems. I have a DS415+, with 8GB RAM upgrade. In order to access the app through your PC, follow the “Crashplan Client Installation” written in this site.

    Replace the default ip in the serviceHost with your NAS’s ip and then run the SSH session (I use WinSCP portable) with echo `cat /var/lib/crashplan/.ui_info` command, the result should look something like this:

    4243,9ac9b642-ba26-4578-b705-124c6efc920b,0.0.0.0

    Copy and paste the result in the .ui_info located in c:\users\{user}\AppData\Local\CrashPlan\ui_info (remember to replace the default values with your own data)

    IMPORTANT!!! This is not mentioned in the installation guide.

    Replace the 0.0.0.0 with your NAS’s local ip address.

    Try connecting and if you’ve followed these instructions, it should work.

    I really hope this can help all of you, since I myself have been helped many times in this forum!

    @patters – Thank you so much for all your hard work!!!

    Cheers!!!

    PS.: Feel free to correct me if I’m wrong, but it worked for me.

    Reply ↓
    1. patters Post authorOctober 15, 2015 at 10:00

       I wonder if that’s because the package was installed only for your user account, rather than all users. More complications…

       Reply ↓
25. Johnny Bane (@johnnybravobane) October 15, 2015 at 12:45

    Hi,

    I am struggling to find the .ui_info file on my mac so that I can edit. I have tried to navigate to it using the path to make sure it is there and i can’t find it at

    /Library/Application Support/CrashPlan/.ui_info (Mac OS X)

    and when I try to use terminal (sudo nano /Library/Application Support/CrashPlan/.ui_info) it doesn’t open the file but asks me to write a new file. I am a recent mover to a Mac after always been a Windows man so I might be doing something daft here. Can you put me out of my misery??

    Johnny

    Reply ↓
    1. acn October 15, 2015 at 13:39

       First rename the file in Terminal, e.g.:
       mv .ui_info t.ui_info

       Make your edits and revert the file renaming.

       Reply ↓
    2. patters Post authorOctober 15, 2015 at 13:41

       Did you try using terminal, but enclosing the full path in quotes? That space in “Application Support” is possibly the issue.

       Reply ↓
       1. Johnny Bane (@johnnybravobane) October 15, 2015 at 15:40

          Awesome, that did it. Stupid mistake
26. Alex October 15, 2015 at 15:51

    I couldn’t get the PROe app to work on my Sonology, so decided to scrap the idea and test backing up of mapped network drive from my Mac. I’m in the UK so using Ceejay server and app. Can you think of any downsides of backing up NAS as mapped drive?

    Reply ↓
27. arestant October 15, 2015 at 18:22

    The Crashplan App changes the content of the “ui_info” back to default value after restart the computer. Not overtime but most of the time. (Version 4.4.1, Mac OS)

    Any ideas?

    Reply ↓
    1. Michael October 21, 2015 at 07:23

       I had the same problem in windows, I changed the file to read only and now all is fine.

       Reply ↓
28. Bionic Cat October 15, 2015 at 20:22

    Anyone intrepid (or foolish) enough to install DSM 6 Beta? Wondering if Crashplan survives it.

    Reply ↓
    1. acn October 16, 2015 at 11:42

       As it is right now with DSM 5 – for me not uploading any new data – no, I won’t be upgrading until this is stable again.

       Reply ↓
    2. Mark Venn October 16, 2015 at 11:43

       Yes and yes, in that order.

       Reply ↓
       1. Stephen Cranfill October 16, 2015 at 11:49

          Thanks for being adventurous (and reporting back)!
       2. BranislavG October 18, 2015 at 15:21

          @ Stephen Cranfill, Mark Venn – results apparently vary, mine’s busted since DSM 6.0 instal. Reinstalling the package didn’t help. Yep, I know, my fault, but I might be interesting what’s broke it this time or if there is any solution.
    3. The Dude October 19, 2015 at 02:49

       DS414 DSM 6 beta – Crashplan did not survive. Won’t start. Uninstalled, reinstalled. Still will not start.

       Reply ↓
       1. Stephen Cranfill October 19, 2015 at 10:41

          In a sense, I got lucky. My Crashplan survived the DSM 6 upgrade. That’s a good thing since my external USB disks that I use for onsite backups now spontaneously eject after a few hours.
       2. patters Post authorOctober 19, 2015 at 13:08

          I can’t move to DSM 6.0 beta until beta 2 because I run Surveillance Station which isn’t currently compatible.
       3. Mike October 19, 2015 at 19:06

          I updated to DSM6 (DS415+) and CP is running just fine.
       4. The Dude October 21, 2015 at 21:51

          Still no luck with DSM 6 beta on my DS414. Using Glacier for now.
29. jirikafka October 17, 2015 at 02:10

    These comments last few weeks… From what I see, running CrashPlan on Synology is starting to be not so much about actual backing up your data as it is about solving devious linux puzzles in exchange for few more days of uptime.

    Reply ↓
30. sman October 20, 2015 at 14:45

    Crash plan was working, but for some reason wouldn’t start anymore. I uninstalled it from my Diskstation, and then reinstalled it, stopped the service and restarted it. Then I connected via ssh and tried: echo `cat /var/lib/crashplan/.ui_info` and it returned the correct info except the IP listed is not 0.0.0.0, instead it was 127.0.0.1. The client still will not connect. I’ve edited the ui.properties file to make sure the IP address is pointing to the NAS and is NOT commented out.

    What am I doing wrong?

    Reply ↓
    1. George October 21, 2015 at 20:52

       Did you change the client .ui_info file as detailed in instructions above starting with “Starting with CrashPlan version 4.3.0 …”? You have to change the GUID and IP address in the client .ui_info file.

       Reply ↓
31. Dale October 20, 2015 at 16:14

    I’ve discovered another odd anomaly. At first I was running 4.3.1 with the older CP package that worked for it, and when it kept attempting to update the client the update would fail and CP kept working with my DS214+. However, one weekend the update succeeded and backups were broken. After updating the package, installing the latest version of the client software, and copying my port and GUID from the NAS, I was able to get backups working again, however I notice that now my log is empty, both on the NAS and on the client. Backups and restores continue to work, but the log now appears to be broken.

    Reply ↓
32. acn October 20, 2015 at 23:28

    I’ve rebuilt my entire cache and still nothing on my DS412+. It runs the GUI just fine but I found that in the middle of the logs there are java Exception errors appearing:

    STACKTRACE:: com.code42.exception.DebugException: BQ:: Exception: java.lang.NullPointerException, Skipping and removing! FileTodo[fileTodoIndex = FileTodoIndex[backupFile=BackupFile[459ac7bb863533c77e82bef8c169dda9, parent=a28e2d1f7ffa8244784df08af2dba51e, type=0, sourcePath=/volume1/*****THISWASONEOFMYFILESHERE*****], newFile=true, state=NORMAL, sourceLength=6621593, sourceLastMod=1410121622000], lastVersion = null, startTime = 1445382999841, doneAnalyzing = false, numSourceBytesAnalyzed = 0, doneSending = false, %completed = 0.00%, numSourceBytesCompleted = 0]; BC[544550513805885703>42, sameOwner=f, backupConnected=t, authorized=t, usingForBackup=t, backupReady=t, backingUp=t, validating=f, closing=f, keepBlockState=1, con=2015-10-21T00:11:18:727, val=2015-10-21T00:13:59:434, readyCheckTime=2015-10-21T00:11:18:727, MM[BT 544550513805885703>42: openCount=2, initialized = true, dataFiles.open = true, /volume1/@appstore/CrashPlan/cache/42], session=Session[id=712419434112002110, closed=false, isAcceptor=false, remoteIdentity=ENDPOINT, completedAuth=true, lat=2015-10-21T00:16:21:007, lrt=2015-10-21T00:15:57:566, lwt=2015-10-21T00:16:21:007, #pending=0, enqueued=false, local=192.168.1.74:39678, remote=162.222.41.231:443, usingProtoHeaders=true, usingEncryptedHeaders=true, WAN], syncHandler=ClientSyncHandler@28597508[ timestamp=0, txValid=false, bmfValid=false, propsValid=false, pathsValid=false, throttler=700/1000], hosted=t, hostedCloud=t, replacing=f, selectedForBackup=t, selectedForRestore=f, validationNeeded=f, backupUsageTime=2015-10-21T00:16:21:006, restoreControl=RestoreReceiveControl@16816411[ , hasRestoreEnv=false, hasRestoreJob=false ], cacheMaintenanceState=null, BackupQueue[544550513805885703>42, running=t, #tasks=0, sets=[BackupFileTodoSet[backupSetId=687787892003045703, guid=42, doneLoadingFiles=t, doneLoadingTasks=f, FileTodoSet@27235396[ path = /volume1/@appstore/CrashPlan/cache/cpft687787892003045703_42, closed = false, hasLock = true, dataSize = 2769131, headerSize = 0], numTodos = 25678, numBytes = 215314935946]], BackupFileTodoSet[backupSetId=1, guid=42, doneLoadingFiles=t, doneLoadingTasks=f, FileTodoSet@29309104[ path = /volume1/@appstore/CrashPlan/cache/cpft1_42, closed = false, hasLock = true, dataSize = 497900, headerSize = 0], numTodos = 2778, numBytes = 56392392415]], BackupFileTodoSet[backupSetId=706610375256847611, guid=42, doneLoadingFiles=t, doneLoadingTasks=f, FileTodoSet@19057538[ path = /volume1/@appstore/CrashPlan/cache/cpft706610375256847611_42, closed = false, hasLock = true, dataSize = 33000550, headerSize = 0], numTodos = 134545, numBytes = 246963365364]], BackupFileTodoSet[backupSetId=687866989194510660, guid=42, doneLoadingFiles=t, doneLoadingTasks=f, FileTodoSet@22992339[ path = /volume1/@appstore/CrashPlan/cache/cpft687866989194510660_42, closed = false, hasLock = true, dataSize = 210209, headerSize = 0], numTodos = 1599, numBytes = 13413384192]]], env=null, TodoWorker@3014986[ threadName = BQTodoWkr-42, stopped = false, running = true, thread.isDaemon = false, thread.isAlive = true, thread = Thread[W5686859_BQTodoWkr-42,5,main]], TaskWorker@15812268[ threadName = BQTaskWrk-42, stopped = false, running = true, thread.isDaemon = false, thread.isAlive = true, thread = Thread[W5039087_BQTaskWrk-42,5,main]]] ]
    at com.code42.backup.save.BackupQueue.handleException(BackupQueue.java:1255)
    at com.code42.backup.save.BackupQueue.processTodo(BackupQueue.java:902)
    at com.code42.backup.save.BackupQueue.access$800(BackupQueue.java:99)
    at com.code42.backup.save.BackupQueue$TodoWorker.doWork(BackupQueue.java:1807)
    at com.code42.utils.AWorker.run(AWorker.java:148)
    at java.lang.Thread.run(Thread.java:745)
    Caused by: java.lang.NullPointerException
    at com.code42.backup.handler.BackupHandler.(BackupHandler.java:117)
    at com.code42.backup.save.BackupQueue.saveFile(BackupQueue.java:1328)
    at com.code42.backup.save.BackupQueue.processTodo(BackupQueue.java:887)
    … 4 more

    I first saw this while running Java 8, uninstalled and installed Java 7, but it’s the same thing.

    Any thoughts?

    Reply ↓
33. Dirk October 21, 2015 at 07:00

    It seems that the content of .ui_info is reset once in a while. I noticed it after a reboot of MacOSX that I had to change the UID in the file once again.

    Reply ↓
    1. Mike October 23, 2015 at 15:11

       I’m constantly seeing this. It appears that CP is regenerating the .ui_info file on the Mac Client, so each time I have to ssh into my DS in order to get the correct GUID.

       Reply ↓
34. Scott Tomlinson (@Scottio200) October 21, 2015 at 10:02

    Ok followed the information above and have everything in place

    When opening the client on a mac I’m asked for a Crashplan PROe server address which i enter (I’m using ceejay.net) however I am always getting the error message that it cannot connect to the server with the message to check my network

    Anyone else got this issue?

    Reply ↓
35. Tim Johnson October 22, 2015 at 04:19

    So after updating to the latest client 4.4.1. I can connect to my synology and it starts the backup but then Desktop app stops and the logs only show that crashplan stopping.

    Also I noticed if i restarted my desktop the ui_info file would change and I would have to go back and ssh into synology to get the correct info and update the ui_info file.

    Reply ↓
36. Tim October 22, 2015 at 04:45

    after upgrading the synology and the client app to 4.4.1. My crash plan keeps stopping and the log only says crashplan stopping. It gives no error.

    Also I noticed as well that if I reboot my desktop the client app won’t connect the ui_info file changes and I have to ssh into synology get correct info then update ui_info file.

    Reply ↓
    1. Michael October 23, 2015 at 10:18

       I made the file read only and now all works fine

       Reply ↓
    2. acn October 23, 2015 at 10:49

       Check if your RAM heap size is high enough, maybe you had changed it before. You should see it in:

       tail /var/packages/CrashPlan/target/syno_package.vars

       If that’s not the issue, then you have my issue, which is CrashPlan not backing up anything, though you can connect and it scans the files. I have found no solution for this so far.

       Reply ↓
37. jbrerhel October 22, 2015 at 05:03

    I am trying to locate the crashplan log on my Synology. According to Crashplan support, the location should be /usr/local/crashplan/log. But there is no crashplan directory under /usr/local. Can anyone point me in the right direction? Thank you!

    Reply ↓
    1. George October 22, 2015 at 05:07

       /var/packages/CrashPlan/target

       Reply ↓
       1. jbrerhel October 22, 2015 at 06:39

          Thank you very much! Finally was able to confirm that my issue is memory. Which makes sense given I am using a Synology DS212j with 256mb RAM (you read that right!). This is the end of the road for me. I am giving up on running CP headless for now.
38. jerseygirl54 October 23, 2015 at 21:28

    Does anyone have an issue with disconnects from LAN/WAN? When the Crashplan starts, I’m unable to connect and it doesn’t show up on a ping or my network. I have to press the restart to connect. Is there a fix for this?
    Thanks again in advance.

    Reply ↓
39. noot101 October 25, 2015 at 19:30

    I Upgraded to 4.4.1 and cannot connect windows client to backup-engine anymore.
    Changed Guid and IP-address in .ui_info. But still nothing.
    How can I fix this?

    Reply ↓
40. David Llewelyn October 27, 2015 at 08:46

    Hi there. Firstly thanks for developing this! Great tool for us Synology users.

    Crashplan claims to have now backed up 100% of my data from my Synology DS415+ (verified from the Crashplan website). However, noticing some odd behaviour. When I try to connect with the Mac client now, it will begin scanning the entire set again (I am only using the default set). About halfway through this, the Mac client now just quits unexpectedly. No error thrown.

    Looking at the log at the server end, I can see weirdness.

    10/27/15 3:35 AM CrashPIan started, version 4.4.1, GUID xxxxxxxxxxxx
    10/27/15 3:35 AM Backup scheduled to always run
    10/27/15 3:35 AM [Default] Scanning for files to back up
    10/27/15 3:36 AM [Default] Starting backup to CrashPIan Central: 189 files (3.60MB) to back up
    10/27/15 3:37 AM Stopping CrashPIan
    10/27/15 3:38 AM CrashPIan started, version 4.4.1, GUID xxxxxxxxxxxx
    10/27/15 3:38 AM Backup scheduled to always run
    10/27/15 3:38 AM [Default] Scanning for files to back up
    10/27/15 3:39 AM [Default] Starting backup to CrashPIan Central: 189 files (3.60MB) to back up
    10/27/15 3:40 AM Stopping CrashPIan

    And this is repeated every minute or so for the last few days despite ‘verify selection’ being set to every week. Is this just normal behaviour if the backup frequency being set to always? Every minute seems overkill. Also, the Mac client closing all the time seems odd.

    Can you help?

    Reply ↓
    1. David Llewelyn October 28, 2015 at 08:05

       Further to this. When I set the backup to run between specific times and then manually set-off a verify selection, it comes back telling me actually 172gb are not backed up.

       This previously mentioned behaviour of starting and immediately stopping continues ever minute whenever the backup is supposed to be running. The amount remaining to backup never decreases meaning it is failing.

       This is BIG issue as it totally undermines any confidence that Crashplan is 1) Accurately reporting progress. 2) Completing its tasks.

       Any insight here would be greatly appreciated. It’s so frustrating to get all the way to 91% complete and then have it fail at the last minute.

       Reply ↓
       1. GrantYN October 31, 2015 at 13:00

          What is your heap size? This has happened to me when I’ve forgotten to increase the default heap size. Also, if you are backing up a large data set you should consider breaking it up into several smaller sets.
    2. avpman October 30, 2015 at 00:02

       The client closing all the time could be a memory heap issue on the NAS server side. Especially if you’re backing up 1TB or more of data.

       This fix worked for me on my DS416 which has1GB RAM installed. If your NAS doesn’t have at least 1GB of RAM then DO NOT do this.
       1) Stop CrashPlan from the Synology Packages Panel
       2) ssh to the NAS and navigate to the file /volume1/@appstore/CrashPlan/syno_package.vars
       3) make a backup of it i.e. cp syno_package.vars syno_packages.vars.bak
       4) edit the syno_package.vars file with “vi” (sorry, instructions to do that are beyond this scope)
       5) you will see the following line in the file
       #USR_MAX_HEAP=1024M
       6) REMOVE the “#” from the beginning of the line with 1024M so it reads:
       USR_MAX_HEAP=1024M
       7) If the line contains anything other than 1024M then change it to 1024M (i.e. it may originally contain 512M)
       8) save the file
       9) restart CrashPlan from the Synology Packages Panel

       Hope this fixes it for you like it did for me.

       Reply ↓
    3. DaLiNL October 31, 2015 at 22:29

       Did have the exact same issue with scanning, stopping and restarting and rescan the whole every x minutes.
       Did Uninstall the CrashPlan package, reinstalled, started and waited for the log shows it has started. Stopped, started and copied the new key in .ui_info to my Mac.
       Started the client, filling in email and password and until now it is scanning without stopping and restarting.

       Reply ↓
41. aberrixJosh October 27, 2015 at 13:25

    Thank you so much everyone! My backups had been failing for a month now and I hadn’t had the time to diagnose & repair it, took me about 20 minutes this morning reading through some comments and my NAS is now re-syncing and good to go!

    Reply ↓
42. Dale October 27, 2015 at 20:25

    Any ideas about the empty log? Running packages CP_Pro 4.4.1-0034 and Java SE Embedded 7 1.7.0-0034 on the DS214+, and using 4.4.1 – 1435726800441 on my client. Backups and Restores work perfectly, but the log is now useless.

    Reply ↓
    1. stevens420 October 27, 2015 at 20:27

       Sorry, the Java Version is Java SE Embedded 7 1.7.0_75-0031.

       Reply ↓
       1. Per October 28, 2015 at 17:45

          Hi,
          Copy service.log.xml from /var/packages/Crashplan/target/upgrade/1435726800441.1445963748979/service/log.xml to /var/packages/CrashPlan/target/conf

          That worked for me.
       2. stevens420 October 28, 2015 at 19:43

          I attempted to SSH into the Synology and looked for the /var/packages/CrashPlanPRO/target/upgrade directory, but there is no 1435726800441.1445963748979 directory within it (or any other similar numbers), only multiple sh files and a couple bat files. Also, there is only one directory within the upgrade folder, named UpgradeUI, which is empty.

          When I looked in /var/packages/CrashPlanPRO/target/conf the service.log.xml file is already present there, along with my.service.xml, ui.log.xml, upgradeui.log.xml, and default.service.xml.

          The client continues to list a blank history, and when attempting to access the log on the Synology, it only says “No Data”.
       3. stevens420 October 28, 2015 at 19:54

          Thanks anyways. I have no doubt that the problem is on the Synology end, but apparently it’s a different one. I had uninstalled the old CrashPlanPRO syno package before installing the new one, so perhaps that’s why the upgrade folder isn’t populated as expected. Perhaps the new package doesn’t support my Java Version properly, or something else is scrambled within the CP package folders.

          I had forgotten to mention that I had to set my C:\ProgramData\CrashPlan\.ui_info file to read-only to keep it from changing GUID and port numbers all the time. After doing this, Backup functionality was able to survive a reboot of the client. But the log stopped working after this was done, and I cannot figure out why.
       4. stevens420 October 28, 2015 at 20:41

          Updated Java package to 1.7.0_75-0034 but the log remains empty. Clearly it’s not a Java issue.
       5. stevens420 October 28, 2015 at 20:45

          Could this be a DSM issue? I’m still running 5.2-5565.
       6. Per October 30, 2015 at 16:40

          I’m running DSM 5.2-5592 Update 1 and I had to copy the service.log.xml to get it to work.
       7. Stevens420 October 30, 2015 at 16:58

          Thanks for the info. I may try updating DSM to see if it helps. Updating Java didn’t. But the file was already in the correct location, so it must be something else.
       8. stevens420 October 30, 2015 at 16:59

          Thanks for the info. I may try updating DSM next. But the service.log.xml file was already in the right place, so it may be something else. Updating Java didn’t help.
43. Jon October 27, 2015 at 21:39

    My Syno was recently rebooted for the first time in weeks, and after it came back up, the CrashPlan GUI client on my monitoring PC could no longer connect to the service on the NAS. It gave no error message – it just hung at the splash screen.

    Further investigation revealed that both the port number and the GUID on the Syno had changed!

    Updating those two fields in .ui_info on the GUI PC to match the new .ui_info on the Syno got it working again. A simple fix, but a trap for young players. I have no idea whether the port and/or GUID changes had been pending for a while and merely took effect when the Syno was rebooted, or if the reboot itself was the cause, but unless someone can come up with an automated way to synchronize these files, I fear that maintaining a headless CP installation is going to require ongoing manual intervention.

    Perhaps some enterprising hacker could come up with a linux script to copy .ui_info into a shared folder on the Syno on a regular basis (or maybe only on reboot) and a Windows batch file to extract the relevant details from it and build a new .ui_info on the monitoring PC.

    Reply ↓
44. Singularity October 29, 2015 at 18:07

    Code42 is releasing version 5.x with no JVM needed for MAC and soon Windows. I wonder how much longer they’ll keep the 4.x Java version going? Sounds like the writing is on the wall for our nice solution to go bye bye… :(

    Reply ↓
    1. Márcio October 30, 2015 at 13:48

       From the release notes of version 5.0.1, Linux will continue to be supported, so we will still have a Linux based solution.
       Just not Java based.

       Reply ↓
       1. patters Post authorNovember 5, 2015 at 23:42

          For Intel perhaps, but I suspect it’s the end of the road for ARM and PowerPC.
45. jirikafka October 29, 2015 at 18:49

    Continuation of the story of me leaving Crashplan: Chapter 3 – Going full circle

    After increasing problems with CrashPlan running on Synology, I began my journey to new cloud backup service. First adept, iDrive, tried its best to show its better face, but the facade lasted only that long. First problem arose, and the ugly parts have been revealed.

    I went to the big guns then, Amazon Cloud Services. Hell, Synology has its own app for Glacier, if that doesnt work, nothing will. And yes, it worked without hickup. But then the limitations started to fade in. You cannot adapt folder, recovery of the file is not exactly straightforward and quick, there is no file versioning (thats only in more expensive service, S3), … So I started to thing in different ways.

    I knew CrashPlan suited all my needs perfectly. Except that dreaded NAS support I clinged to so much, I forgot there are better, and supported ways.

    Long story short, I bought miniPC (AsRock Beebox). $200 + 5 watts per hour is the price for the ticket to worry-free using of CrashPlan.

    So yes, after I tried different cloud services in order to leave CrashPlan, I ended up using it again, this time in proper way.

    Reply ↓
    1. avpman October 29, 2015 at 19:25

       Hi,
       What exactly did you use the miniPC for? I’m not sure in understand your setup, especially when you said “I ended up using it again, this time in proper way.” Are you not backing up your NAS any longer?

       Reply ↓
    2. B. Goodman October 29, 2015 at 21:56

       Care you elaborate? How much RAM does the Beebox have and what OS? Did you map drives to each Synology share?

       Reply ↓
       1. jirikafka October 30, 2015 at 01:45

          It differs model from model, I´ve bought barebone version with quad core Intel N3150 and installed 8 GB RAM + 60 GB SSD. I had spare parts, so it didn´t cost me anything, otherwise you´d have to buy them. As of operation system, you can buy unit with W8/W10 licence, or cheaper one without OS, and install your preferred choice (linux).

          On this computer, I map Synology share folders as network drives, and mark them for backup in CrashPlan app.
    3. Simon November 5, 2015 at 18:40

       Interesting… makes me realize that since I have a ome computer (a Dell Optiplex) that’s always logged on to the SAN, I could just do what you did – map the drives I want to backup, and back them up from that computer. However I ran into two issues:
       1) The mapped drives don’t show up in CrashPlan when I run the app on that computer (Windows 7)
       2) For some reason, the mapped version of ‘Home’ (where cloudstation stores all its files) doesn’t show the Cloudstation folder, although when I look at it via Filestation under DSM, there it is

       Doubt the two issues are related, but would really appreciate any advice on how to address either

       Reply ↓
       1. Simon November 6, 2015 at 03:20

          Test
46. JimM October 29, 2015 at 20:21

    Update Broken again? The 10/26 update to 4.4.1 fails on my 412+. Here are the release notes from CP:
    “Beginning on October 26, 2015, all CrashPlan apps that connect to the Code42 cloud received additional updates to version 4.4.1:
    -Improvements to the CrashPlan app upgrade process.
    -Corrects issue in which some users experienced problems restoring folders with restricted permissions on Windows devices.
    -Corrects a rare issue in which the CrashPlan app for Windows did not open after upgrading to version 4.4.1 and displayed the error message “Failed to load Java VM library (errno=193).”
    -Additional performance and stability improvements.”

    The update is downloaded and expanded in the Upgrade folder by the app. It re-tries multiple times, with CP eventually going offline. Deleting the update files and re-starting the package makes CP available again for a short time, but the process repeats. Any suggestions welcome.

    Reply ↓
47. OJ October 29, 2015 at 22:42

    Hi there,

    After a recent automatic DSM upgrade I’m now seeing the CrashPlan package failing to start. Here’s what the log looks like:
    —
    I 10/27/15 07:39AM Downloading a new version of CrashPlan.
    I 10/27/15 07:39AM Installing upgrade – version 1435726800441
    I 10/27/15 07:39AM Upgrade failed – version 1435726800441
    I 10/27/15 08:09AM Downloading a new version of CrashPlan.
    I 10/27/15 08:09AM Installing upgrade – version 1435726800441
    I 10/27/15 08:09AM Upgrade failed – version 1435726800441
    I 10/27/15 06:10PM Stopping CrashPlan
    I 10/28/15 02:08PM Synology repairing upgrade in
    I 10/30/15 04:49AM Synology repairing upgrade in
    I 10/30/15 07:43AM Synology repairing upgrade in
    I 10/30/15 07:43AM Synology repairing upgrade in
    —

    On the NAS, the file system contains what appears to be the remnants of a bunch of failed attempts at… something!:

    —
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445893844342
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445895585265
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445897386352
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445899181174
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445900976635
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445902781375
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445904584930
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445906378873
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445908188455
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445909979994
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445911787245
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445913579929
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445915374088
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445917178415
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445918987796
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445920778266
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445922585731
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445924378468
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445926187786
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445927977893
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445929787752
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445931580520
    drwxr-xr-x 4 root root 4096 Oct 29 21:43 1435726800441_59.1445933374382
    -rw-r–r– 1 root root 33859963 Oct 26 19:23 1435726800441_59.jar
    —

    I’ve nosed around a little to see what might be the issue, but the lack of logs is a killer. Patters, could you give me a pointer or two please as to where to look?

    Thanks mate.
    OJ

    Reply ↓
48. Jan Frederik Léger October 30, 2015 at 12:35

    Package was stuck on some upgrades from Code42 for some days.
    Upgrades: 1435726800441_59.1446197341696 and 1435726800441_59.1446197348786.
    (1) start-stop-status.sh seems not to be able to handle multiple upgrades. Could you fix this? I had to manually move the second upgrade folder away, launch CrashPlan (to make the first upgrade to be applied) and put the second upgrade folder back.
    (2) start-stop-status.sh seemed not to be able to handle underscores in the upgrade number.
    (3) start-stop-status.sh was stuck on not finding bin/jna.jar.

    I edited start-stop-status.sh to fix for the problems (2) and (3). Diff below:

    @@ -66,7 +66,7 @@
    echo “I ${TIMESTAMP} Synology repairing upgrade in ${SCRIPT_HOME}” >> ${DLOG}

    mv ${SCRIPT_HOME}/upgrade.log ${SCRIPT_HOME}/upgrade.log.old
    – UPGRADE_VER=`echo ${SCRIPT_HOME} | sed -r “s/^.*\/([0-9_]+)\.[0-9]+/\1/”`
    + UPGRADE_VER=`echo ${SCRIPT_HOME} | sed -r “s/^.*\/([0-9]+)\.[0-9]+/\1/”`
    unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar “*.jar” -d ${OPTDIR}/lib/
    unzip -o ${OPTDIR}/upgrade/${UPGRADE_VER}.jar “lang/*” -d ${OPTDIR}
    mv ${SCRIPT_HOME}/upgrade.sh ${SCRIPT_HOME}/upgrade.sh.old
    @@ -74,10 +74,9 @@
    fi

    #updates may also overwrite our native binaries
    – [ -e ${OPTDIR}/bin/libffi.so.5 ] && cp -f ${SYNOPKG_PKGDEST}/bin/libffi.so.5 ${OPTDIR}/lib/
    + [ -e ${OPTDIR}/bin/libffi.so.5 ] && cp -f ${SYNOPKG_PKGDEST}/bin/libffi.so.5 ${OPTDIR}/lib
    [ -e ${OPTDIR}/bin/libjtux.so ] && cp -f ${OPTDIR}/bin/libjtux.so ${OPTDIR}/
    – [ -e ${OPTDIR}/bin/jna-3.2.5.jar ] && cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib/
    – [ -e ${OPTDIR}/bin/jna.jar ] && cp -f ${OPTDIR}/bin/jna.jar ${OPTDIR}/lib/
    + [ -e ${OPTDIR}/bin/jna-3.2.5.jar ] && cp -f ${OPTDIR}/bin/jna-3.2.5.jar ${OPTDIR}/lib || cp -f ${OPTDIR}/bin/jna.jar ${OPTDIR}/lib/

    #create or repair libffi.so.5 symlink if a DSM upgrade has removed it – PowerPC only
    if [ -e ${OPTDIR}/lib/libffi.so.5 ]; then

    Maybe you could incorporate these fixes in a new release.

    Reply ↓
    1. patters Post authorNovember 5, 2015 at 23:40

       Thanks for the tips. I’ve recently started a new job so I have only just caught up with moderating on here and noticed that my syno has not been backing up in a while.
       1) seems a little involved – and this scenario is only a problem because of the failures caused by 2) and 3)
       2) that’s Code42 changing things
       3) forgot that could result in a failure condition. I’m a little rusty but I can’t see how the package even worked at all on Intel with this issue.

       Reply ↓
49. George October 31, 2015 at 04:17

    Crashplan has pushed an upgrade, 4.4.1_59, to my DS214se. I used the following steps to upgrade (thanks to Yves for documenting during 4.4.0/4.4.1 upgrade)

    Stop CP on NAS
    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800441_59.jar “*.jar” -d /var/packages/CrashPlan/target/lib/
    unzip -o /var/packages/CrashPlan/target/upgrade/1435726800441_59.jar “lang/*” -d /var/packages/CrashPlan/target/

    mv /var/packages/CrashPlan/target/upgrade/1435726800441_59.whatevervalue/upgrade.sh /var/packages/CrashPlan/target/upgrade/1435726800441_59.whatevervalue/upgrade.sh.old

    –> NOTE THERE ARE SEVERAL DIRECTORY’S, YOU HAVE TO RUN THIS COMMAND FOR EVERY DIRECTORY !!!!! – George – you will have a directory for each failed attempt of automatic upgrade, so recommend keeping an eye on NAS CP log to see when your upgrade is downloaded. The sooner you catch it, the fewer directories you will have
    Start CP on NAS

    My upgrade was successful and my clients continued to be able to connect, and backup are running. Note I use CP on NAS as my backup server, I do not use CP Central

    Reply ↓
    1. hal sandick October 31, 2015 at 11:42

       yes, had to do the same. Upgrade successful.

       Thanks for laying them out again.

       Hal

       Reply ↓
    2. Richard October 31, 2015 at 14:03

       Rather than running the commands on some 20 plus directories, I decided to uninstall then re-install the Crashplan package. On the NAS,the package then starts immediately. After making the GUID change again, then connecting from the client and adopting the old backup, everything is working perfectly again.

       Reply ↓
       1. Badbob001 October 31, 2015 at 17:58

          When the usual method didn’t work anymore, I realized I had 50+ upgrade folders, all from the same version. I deleted all but the latest and now it’s OK.
       2. B. Goodman October 31, 2015 at 21:59

          for f in ./*/upgrade.sh; do mv “$f” “$(dirname “$f”)/upgrade.sh.old” ; done

          From:
          http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/
          dSebastien offered up nearly the above, but it didn’t work until I added the
          ;done
          at the end.

          But once I had that part, it went through all the directories doing the move command and CrashPlan started right up.

          **WARNING, per BionicCat, you have to change the smart quotes here for regular quotes
       3. Jon November 4, 2015 at 07:19

          I went down the same path of uninstalling and reinstalling, but after restarting, the CP service kept stopping and restarting when it was trying to back up to CP Central. Eventually I realized that my customized memory setting in /var/packages/CrashPlan/target/syno_package.vars had been overwritten by the reinstall, and after editing that file again and putting it back to 1536M, everything started working correctly again.
    3. Mike October 31, 2015 at 21:24

       Anybody know the equivalent command line using 7z instead of unzip? DSM6 has dropped unzip in favor of 7z and I’m obviously doing something wrong as I can’t get it to extract correctly!

       Reply ↓
    4. B. Goodman October 31, 2015 at 22:02

       Sorry, this is a double-post, but I replied in the wrong place.
       Rather than running the move on every directory, instead use this command to handle them all:

       for f in ./*/upgrade.sh; do mv “$f” “$(dirname “$f”)/upgrade.sh.old” ; done

       From:
       http://chrisnelson.ca/2015/07/02/fixing-crashplan-4-3-0-on-synology/
       dSebastien offered up nearly the above, but it didn’t work until I added the
       ;done
       at the end. But once I had that part, it went through all the directories doing the move command and CrashPlan started right up.

       **WARNING, per BionicCat, you have to change the smart quotes to regular quotes

       Reply ↓
50. David Llewelyn November 2, 2015 at 08:42

    PLEASE HELP!! Can connect to the CrashPlan headless client on my Synology. Mac-side client immediately quits after logging in. Package Manager log just shows the CrashPlan service starting and stopping every minute or so for the last few days. Backups at 91%, so something has worked until now.

    Reply ↓
    1. Jon Etkins November 2, 2015 at 14:48

       I’ve had that happen from time to time. What has worked for me is to pause the backup, then go to Crashplan Central under Destinations and click Compress (or is it Compact, I forget.)

       Reply ↓
       1. David Llewelyn November 3, 2015 at 08:16

          I had been avoiding that to reduce the overhead on the CPU, but at this stage it’s definitely worth a try.

          Thanks!