Ahhh ok!  Thank you for that information

Hello!

 

I just upgraded from unRaid 4.x to the latest 6.1.3 release, got Docker setup with the Crashplan docker, got my identity file and such copied over.

 

It is successfully backing up to other destinations but computers are not able to backup to unRaid. The error they are getting (and I'm seeing on the server) is "Backup disabled -- backup location is not accessible".

 

I have the backup destination configured to an accessible location, I can access the share with that destination just fine. I've run the permissions script to fix the permissions for updating from unRaid 4.x to 6.1.3. I can access the Backup directory from the shell without issue.

 

I have no idea why Crashplan thinks it can't access the location but I need to get this working. Any ideas? I checked using docker that the directory is accessible.

 

 

 

 

You've checked the permissions for the content of /data/backup. What about the permissions of that directory?

 

ls -l /data

It's accessible as well. I should also point out that in the first screenshot I took, you can see the unRaid crashplan client backing up to "Clint's nimbus", a remote linux server with Crashplan installed that accepts my backups from my server. It's backing up data from /data/Documents and /data/Arrange a Memory just fine, so obviously Crashplan CAN access those folders.

 

 

 

Adding this as a new reply so it doesn't get lost.

 

I fixed the above issue. The specific issue was located in the conf/my.service.xml file, down at the very bottom is a configuration section titled <socialNetworkConfig> under which each of the inbound backup computers were configured AND for some reason the manifestPath was configured separately for each one and had the old path under my old unRaid install (/mnt/user/Backups/).

 

I shutdown the Crashplan docker, edited the paths on each (I'm sure there's an option to use the system default but I'm not going to tweak it right now as it's now working), restarted Crashplan and everything just worked.

 

Is Crashplan-Desktop currently broken? I'm getting the 'disconnected from backup engine' message from the GUI. I want to make sure it's nothing wrong on my end. Thanks

I get that too. The engine still runs, I have other pcs backuping to the unraid server but the desktop used to work and now gets this message

I believe that the Desktop Container isn’t updated yet to the latest version of CrashPlan.

I believe that the Desktop Container isn’t updated yet to the latest version of CrashPlan.

 

I thought crashplan clients auto updated?

 

Just installed crashplan desktop and I'm getting the "disconnected from backup engine" error.  Damn.  Really wanted this to work...  Any other quick and easy alternatives?

I believe that the Desktop Container isn’t updated yet to the latest version of CrashPlan.

 

I thought crashplan clients auto updated?

 

Just installed crashplan desktop and I'm getting the "disconnected from backup engine" error.  Damn.  Really wanted this to work.

Only the CrashPlan engine container, not the CrashPlan Desktop container. Still possible to get the Windows client to connect to the CrashPlan engine container.

Still possible to get the Windows client to connect to the CrashPlan engine container.

 

Though no way to backup data to your crashplan account...

Why not? Mine still does and if you want to make change use the windows client

Does anyone think its a good idea to back up the flash drive and the apps folder on the cache drive (and maybe even the docker.img) using crashplan? If yes, what would need to be done? And how would one go about restoring this? I ask this since recently I had a cache drive go bad and it turned out quite painful restoring all the dockers and setting them up again.

I am using rsync to make a backup once a week of the appdata folder on my cache drive to a folder on my array and let CrashPlan backup that folder. Here is a script that I run manually but it can be automated using a cron job.

 

You could do the same with the flash drive but I believe that the array should be stopped before running the backup. I think I have read somewhere that unless you haven’t done that and do a restore unRIAD will run a parity check when you start the server.

#!/bin/bash
#
# 		--- Syntax - rsync ---
# -a							archive
# -v							verbose
# -r							recursive (copies directories)
# -t							preserve modification times
# -O							omit directories from -t
# -J							omit symlinks from -t
# -H							preserve hard links
# --delete						delete at destination if missing at source
# >								Output to log file 
# >>							Append output to log file
#
# 		--- Syntax - tar ---
# -cf archive.tar file1 dir1	Create File (archive) with list of files or directories to include (path if needed) 
# -cvf							Verbose
# -cjvf	archive.tar.bz2			Compress with bzip2
# -czvf	archive.tar.gz			Compress with gzip
#
#		--- Syntax - docker ---
# docker stop CouchPotato		Stop a specific container
# docker stop $(docker ps -a -q)	Stop all containers
# etc/rc.d/rc.docker stop		Stop all containers and Docker service
# docker start CouchPotato		Start a specific container
# /etc/rc.d/rc.docker start		Start all containers set to autostart
#
clear
# Set start time
START=$(date +"%Y-%m-%d %T")
echo --- Stop Dockers
/etc/rc.d/rc.docker stop
echo --- Start job: AppdataLocalBackup.sh
echo --------------------------------------------------------------------------
echo --- Begin backup: appdata folder on cache drive to Backup share
rsync -avrtOJH --delete --exclude-from 'exclude.txt' //mnt/user/appdata/ //mnt/user/Backup/appdata/ >/boot/logs/Appdata_local_backup.log
tar -czf /mnt/user/Backup/appdata/Plex.tar.gz /mnt/user/appdata/Plex
echo --- End backup:  appdata folder on cache drive
echo --------------------------------------------------------------------------
echo --- End job: AppdataLocalBackup.sh
echo --- Start Dockers
/etc/rc.d/rc.docker start
# Set finish time
END=$(date +"%Y-%m-%d %T")
echo --- Start: "$START"
echo --- Finish: "$END"

Why not? Mine still does and if you want to make change use the windows client

 

This assumes I have a windows client.

Err, crashplan is not working right now. It shows my server as offline from my windows pc which I need to back up. What do I check?

The autoupdate froze my engine container once. A container restart or two was all it needed

As of Nov 8, this workaround is no longer needed.  Just update to the latest versions of the CrashPlan and CrashPlan-desktop dockers. See this.

 

Here's a quick fix to solve the "disconnected from backup engine" error in CrashPlan Desktop.  This updates it to CP 4.4.1 and tweaks the .ui_info file

Note: these instructions assume that you have already installed the latest CrashPlan and CrashPlan-Desktop dockers per the instructions in Leifgg's guide (the link is in his signature).  They also assume that you kept the default container names.

 

Modifying a docker in this way is typically frowned upon, but it is our only option until the docker itself is updated.

 

SSH to your server and type:

• docker exec -it CrashPlan-Desktop bash
  
  • Note: If you see a message that says "Error response from daemon: no such id", then either you made a typo, or you haven't installed the CrashPlan-Desktop container, or you gave the container a different name.  Do not continue until you have successfully exec'd into the container.
    

   

  [*]wget -nv https://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.4.1_Linux.tgz -O - | tar -zx -C /tmp

  [*]cd /usr/local/crashplan

  [*]cat /tmp/crashplan-install/CrashPlan_4.4.1.cpi | gzip -d -c - | cpio -i --no-preserve-owner

  [*]exit

  [*]exit

* Full disclosure, all I did here was pull the relevant bits out of gfjardim's docker and update for 4.4.1:

  https://github.com/gfjardim/docker-containers/blob/master/crashplan-desktop/install.sh

 

 

 

Now modify \\tower\appdata\crashplan\id\.ui_info, changing 0.0.0.0 to 172.17.42.1.  It should look something like this when you're done:

 

4243,aaa-bbb-ccc-ddd,172.17.42.1

 

Note... In this example,

* "tower" is the default name of an unraid server, although yours could be different.

* "appdata" is what most people call the share that stores their docker data, although yours could be different.

* "crashplan" is a reasonable name for the directory that holds CrashPlan data, although yours could be different.

 

For me, the easiest way to edit this file is from a Windows box.  I would choose Start -> Run and type \\tower, then navigate to the appdata\crashplan\id folder and drag and drop the .ui_info file into a good editor like Notepad++

 

Another option would be to SSH to tower and then

* cd /mnt/user/appdata/crashplan/id

* nano .ui_info

Thanks brainbone for the reminder on nano, I really didn't want to talk about vi

 

At this point the CrashPlan-Desktop should be able to connect to CrashPlan.

 

If you reboot your server (or otherwise restart the main Crashplan docker), you'll need to modify the .ui_info file again.  I believe the other changes will remain intact.

Here's a quick fix to solve the "disconnected from backup engine" error in CrashPlan Desktop.  This updates it to CP 4.4.1 and tweaks the .ui_info file

 

Thanks for that.  Will these changes complicate application of the "real" docker update when/if that comes?

 

I'd like to change the password for CrashPlan-Desktop from PASSWD to something else.  Will this change stick?  Any issues with doing this?

Here's a quick fix to solve the "disconnected from backup engine" error in CrashPlan Desktop.  This updates it to CP 4.4.1 and tweaks the .ui_info file

 

Thanks for that.  Will these changes complicate application of the "real" docker update when/if that comes?

 

It won't cause any problems, updating the Docker will wipe out all the manual customizations we made to the container.  If you are really concerned about it, you could delete the docker and reinstall it.

 

The .ui_info file is the only modification that happens outside of the docker container.  Normally that means it would "stick", but in this case that file is recreated every time you restart the main CrashPlan docker.

 

I'd like to change the password for CrashPlan-Desktop from PASSWD to something else.  Will this change stick?  Any issues with doing this?

 

Same as above, all manual customizations will be wiped out when you update the container.

Here's a quick fix to solve the "disconnected from backup engine" error in CrashPlan Desktop.  This updates it to CP 4.4.1 and tweaks the .ui_info file

 

I followed your steps but no luck. 

Here's a quick fix to solve the "disconnected from backup engine" error in CrashPlan Desktop.  This updates it to CP 4.4.1 and tweaks the .ui_info file

 

I followed your steps but no luck. 

 

When you connect to the desktop docker and see the CrashPlan splashscreen, what version does it say it is loading?  If it says 4.4.1, then the manual upgrade worked and there is likely a problem with your .ui_info file.

 

Note - I'm assuming that CP worked for you before?  If CP has never worked then this is not a good time to get started with it It would probably be best to wait for an official update.

 

 

If the splashscreen still says 4.3, then something went wrong with the manual upgrade.  You can try SSH'ing to your server and running those commands again, or we can wait and see how it works for other people.  I've done this on two servers and it worked fine, but if other people have problems I'll revert one of mine and do the manual upgrade again to check for typos or whatever.

It does show 4.4.1

 

But no green ball next to the server destination.

 

172.17.42.1 is what I can see in the server\apps\crashplan\id\.ui.info file as well.

 

Thanks for the help. I really wish crashplan worked more reliably. Its a must-have tool.

It does show 4.4.1

 

But no green ball next to the server destination.

 

OK, so it sounds like my fix eliminated the "disconnected from backup engine" error and allowed the desktop docker to manage the main CrashPlan docker, right?  That is all this fix was trying to do.

 

For help with general setup, see the awesome document that Leifgg posted.  But this is still probably not a good time to get started with CrashPlan, too many potential problems right now.