Hoopster

I am running unRAID 6.1.9 on my server and Docker page shows no updates available for CrashPlan. My CrashPlan client is still at 4.4.1. It works fine and CrashPlan continues to backup my media files to CrashPlan Central. It appears from reading this forum that CrashPlan updates are only available when running the unRAID 6.2 beta. Any issues to be aware of if CrashPlan is not updated to latest?

My only "cure" when the VNC client would black screen was to connect with the Windows client. I was able to get the VNC client connecting after a couple of reinstalls of the docker, but, it still takes 30-40 seconds to connect. The biggest pain with the Windows headless config is the need for a manual file copy (.ui.info) from Windows client to CrashPlan docker after every server reboot, docker update or CrashPlan engine restart. The joys of Code 42 not officially supporting headless installations.

Thanks for this Crashplan docker update. Everything works very well after following the update instructions in this thread. I also do not see the high CPU usage with this docker that I saw with the separate Crashplan-Desktop docker. I do have a question however. When I start the WebUI it takes from 30 seconds to a minute after initiating the VNC handshake before the Crashplan desktop appears. Just want to make sure this is the "normal" behavior and I do not have a configuration or network issue. Thanks again.

Welcome to the world of headless CrashPlan. This is the way it is currently designed to work. If you restart the CrashPlan engine in any way (server reboot, docker restart, manual engine restart, etc.) the .ui_info file is regenerated and will have to be edited (or copied from client) again. To my knowledge there is no workaround. When I contacted Code42 about this their response was basically, "well, we don't support headless CrashPlan officially and we do not test these configurations when releasing new versions, so, if it breaks, it breaks and you will have to deal with it. We recommend you use CrashPlan in a supported configuration."

Upgrades to the CrashPlan engine are automatic and CrashPlan does not ask for user input. Your CrashPlan docker just phoned home, was told there was an upgrade and CrashPlan was automatically upgraded from the Code42 servers. It's worse than Windows Update as you have no control over the process at all. If there is an update, CrashPlan will be updated.

Gfjardim has not yet updated the CrashPlan Desktop to version 4.4.1 (it is still running version 4.3.0). The CrashPlan backup engine on the server automatically updated itself to version 4.4.1 and the 4.3.0 client cannot connect to the newer engine. CrashPlan Desktop will not work until it is upgraded by its author to the latest version. Those who need client access to make changes or monitor progress (raises hand) are using the Windows client temporarily as it has been updated to 4.4.1. Just make sure you follow Leifgg's setup guide because there are some gotchas between client and server in version 4.4.1 with keeping necessary files in sync.

All working here. It appears the Windows client is now updated to 4.4.1 as well and it connects no problem to my version 4.4.1 backup engine in unRAID docker. My issues in getting it going were related to the new format of the .ui_info file and the fact that it was getting recreated frequently on the client side. Setting it to read-only appears to have stopped that. You might also want to check your my.services.xml file and make sure the service host is still set to 0.0.0.0 and not 127.0.0.1. Also make sure that in ui.properties the service host is properly set to the IP address of your unRAID server. Updates tend to overwrite these files and changes are lost as they return to defaults As mentioned in the post above, follow Leifgg's guide to setting up CrashPlan. He has a link to it in his signature. It is very detailed and he was very thorough in what is needed to get a Windows or Linux desktop connected to the CrashPlan backup engine docker. Lately there seems to be a new round of discovery with every CrashPlan version update. They keep tweaking things that temporarily break headless installs until someone discovers the changes and shares them with us. There are a lot of little "gotchas" in running CrashPlan headless

Updated Crashplan Windows client to 4.4.0 (CP engine in docker has been automatically updated to version 4.4.1). The format of the .ui_info file has changed (as noted in a prior post in this thread). It is now 4243,[GUID],[iP address of unRAID server]. I copied .ui_info from the cache drive \appdata\crashplan\id folder to C:\ProgramData\CrashPlan and the client connected to the backup engine. The problem is that the CrashPlan Windows client (or tray service) seems to now recreate the .ui_info file every time the Windows PC is restarted. At least, that's what appears to trigger it. After being connected to the CrashPlan engine without problem, a subsequent reboot of the PC resulted in a grayed out CrashPlan tray icon with a "cannot connect to backup service" message. This happens because .ui_info is recreated with a new GUID that does not match the server-side GUID and an IP address of 0.0.0.0. I set the C:\ProgramData\CrashPlan\.ui_info file to read-only and it has survived a couple of reboots without being recreated and the client has remained connected to the backup engine. I am not 100% certain the PC restart is what triggered a new .ui_info file being created, but, if that is the cause, setting it to read only has prevented it through a couple of PC and CrashPlan client restarts.

Here is a space themed banner (a crop from a space telescope photo) that looks very nice with the Limetech logo.

CrashPlan engine is "set it and forget it." Backup, once configured, is automatically happening in the background without the client running. You never have to connect to the backup engine on unRAID unless you want to make a configuration change.

CrashPlan lets you backup free between computers. You only have to pay to backup to CrashPlan Central (cloud backup). In my case, I backup unRAID shares to Crashplan Central, so, I needed to purchase a license. Even though I run a Windows client (or RDP through MATE CrashPlan-Desktop docker) only one license is required since I am only backing up unRAID to the cloud. The Windows or MATE client is just for management purposes. If I wanted to backup my Windows machine to CrashPlan Central, that would require another license. You can backup a Windows, Mac, or Linux computer to unRAID or an external drive without a CrashPlan license. You can also backup to a friend's computer or a friend to you without a license. Only cloud backup requires a license. See https://www.code42.com/store/.

Are the following settings the same in my.service.xml in both C:\ProgramData\CrashPlan\conf and <path to your Crashplan docker setup files>\conf? <serviceUIConfig> <serviceHost>0.0.0.0</serviceHost> <servicePort>4243</servicePort> I found that if the settings were different, it didn't matter what was defined in the my.service.xml in the docker conf folder; the settings in C:\ProgramData\CrashPlan\conf\my.service.xml overrode the server side settings.

Yes, you can use the CrashPlan Windows client to access the CrashPlan engine on unRAID. I use both the Windows client (with or without SSH tunnel) and the MATE CrashPlan-Desktop and both work equally well. See http://support.code42.com/CrashPlan/Latest/Configuring/Using_CrashPlan_On_A_Headless_Computer for configuring Windows client to work with CrashPlan on unRAID. This procedure documents the SSH tunnel method with PuTTY, but, it can be setup to work without the SSH tunnel as documented in the first posts on page 1 of this discussion topic. I originally had trouble getting the Windows client to connect without the PuTTY SSH tunnel, but, thanks to this forum, I eventually got it all sorted out properly.

You do not need the 3389 port mapping for the CrashPlan Engine, just the desktop docker. Get rid of that mapping as it is causing you problems. You should also get rid of the /config mapping on the CrashPlan-Desktop as --volumes-from CrashPlan (looks like you may have something extra there as well) is all you need. See my examples below:

I don't know if my experience will be much help to you but, in summary, here is what I had to do to get both the Windows 4.3 client and the MATE desktop connected to the CP 4.3 engine on my unRAID server: Windows Client - I have never been able to get it to connect without the Putty/SSH tunnel. If I uncomment the serviceHost=[unRAID IP] line in ui.properties and set servicePort to 4243, the client just hangs. - Because of SSH tunnel, the servicePort=4200 in my ui.properties - The .ui_info file must be copied to C:\ProgramData\CrashPlan not C:\Program Files\CrashPlan as you said you had done. I initially made the same mistake. MATE Desktop - copied .ui_info from CrashPlan docker "id" folder in my appdata share to CrashPlan-Desktop docker "id" folder (it will be empty) - the .ui_info with the "4243, unRAID" content would not allow the client to connect. I had to copy over the a renamed .ui_info file I had renamed from a prior docker instance which contained the proper key hash and looks something like "4243,c03bafd8-3f83-40ae-8856-836d6b9d5edf" - This file copy may not be necessary unless you have a /config volume mapping, supposedly the --volumes-from CrashPlan setting in Extra Parameters takes care of this for you. In both cases, client connects to engine with the following my.service.xml settings (serviceHost does not need to be 127.0.0.1 for my Windows client to connect in my case): <serviceUIConfig> <serviceHost>0.0.0.0</serviceHost> <servicePort>4243</servicePort> I have recently added files to shares set to backup to CrashPlan Central and monitored backup progress through both Windows client and MATE desktop. So, until Code 42 messes with something again, it appears to be working although, as I said, only through Putty/SSH on Windows in my case.

Just habit as all my dockers have /config mappings; however, CrashPlan-Desktop was working fine for me even with that mapping after Kryspy pointed out how to make the .ui_info copy on CrashPlan-Desktop. It seems to work for me fine with or without the /config mapping which I was unaware was not needed. I definitely did not need the /home/ubuntu/disks mapping either as a backup is running right now with seemingly no problems.

I don't think there is a one-size-fits-all configuration for CrashPlan server or desktop. I guess that is what makes troubleshooting the problem a bit different for everyone. Some combination of the solutions mentioned is this thread will likely help most, but, there does not seem to be one config to rule them all. My config is working fine without the disks mapping but needed the .ui_info fix:

Duh!! I had thought of that as well, but, for some reason, I could not see the ID folder in the CrashPlan-Desktop docker and I was trying to figure out what the equivalent is in the CrashPlan MATE docker of copying .ui_info to C:\ProgramData\CrashPlan in Windows. I could see the ID folder in MC in a Putty session and got it copied over fine and the MATE CrashPlan docker now works!!! After latest CrashPlan-Desktop update I now see the ID folder through other methods as well, so, it must have been some permissions issue. I still cannot copy to it via Windows, but, MC did the trick. Thanks for getting me pointed in the right direction. It has to be a pain for gfjardim to keep up with Code 42's undocumented tricks. They don't officially support headless installations, but, at least they ought to have the decency of not breaking them (or documenting the changes) for those who are trying to support them.

Back to the drawing board for me. The latest CrashPlan docker update has now broken my windows client connectivity as well. Looks like .ui_info in the docker Id folder has changed to "4243, unRAID". Copying this to C:\ProgramData\CrashPlan does not work as before. I am back to square one on the tweaks to try and figure out what will allow client to connect after Code 42 latest changes in version 4.3 EDIT: I got it working again. Fortunately, I renamed the .ui_info file on the Windows PC before copying the new one from the docker ID folder. This time the fix was to go the other way; copy the "old" .ui_info file from the C:\ProgramData\Crashplan folder to the CrashPlan docker ID folder. It did not like the .ui_info file with "4243, unRAID"

Every time I start the Guacamole CrashPlan connection this is what I see on the MATE Desktop; the CrashPlan splash screen frozen on the desktop. It never times out or connects. Same thing is true if I RDP in from Windows. I have deleted and recreated the CrashPlan-desktop docker several times (each time deleting docker and image and making sure no files remain in the appdata confing folder). I removed and recreated the Guacamole CrashPlan connection. I have tried the server side edits to my.service.xml discussed in this thread. Not critical as I can still connect via putty/SSH from Windows, but I would rather use the MATE desktop if I can get it working.

I'm in the same boat. Accessing CrashPlan Desktop through Guacamole. Loads CrashPlan desktop, the CrashPlan splash screen appears when I run CrashPlan from MATE desktop and then it just hangs; not even a "cannot connect to backup engine" message. I have pulled the latest docker and added --volumes-from CrashPlan to the Extra Parameters section. Both engine and client are version 4.3. I can connect to backup engine fine through Windows 4.3 client and putty/SSH.

I finally got CrashPlan working after the 4.3 upgrade. Here is what I had to do to get Windows 4.3 client to connect to the CrashPlan engine running on unRAID: - set service port to 4200 in ui.properties in Crashplan folder on Windows client - copy .ui_info from CrashPlan docker ID folder to C:\ProgramData\CrashPlan (renaming existing .ui_info) Now, here is the additional step that got it to work for me: For CrashPlan on Windows, there is a file named ui_<account name>.properties in C:\ProgramData\CrashPlan\conf It contains the line servicePort=4243 which apparently overrides the <path to CrashPlan>\conf\ui.properties setting of servicePort=4200 Changing servicePort=4243 to servicePort=4200 in C:\ProgramData\CrashPlan\conf\ui_<account name>.properties made the connection work for me.

My bad, I read c:\ProgramData\Crashplan and my brain saw c:\ProgramFiles\Crashplan. I have Crashplan installed in a different path so I put the .ui_info file in {path to Crashplan} directory. I have now copied it to c:\ProgramData\Crashplan. There was another .ui_info file there which I renamed. However, I still cannot get the client connected to the backup engine with the other ui.properties settings. The only way I can get it to connect is to comment out the "serviceHost [iP address of unRAID server]" line in ui.properties and set service port to 4243 (not 4200). This is what this file looked like prior to upgrade to 4.3 and all was working well. However, when the client connects it does not recognize any of the backup sets defined on my unRAID server and acts like I have no Crashplan subscription. It is like it is starting over with no Crashplan license. If I enter the license key in the Windows client it warns me the license is in use by my unRAID instance and that all backup data will be erased if I transfer the license to the Windows instance. ??

My Windows Crashplan client (version 4.3) will not connect to the Crashplan engine through a Putty SSH session. Like everyone else, it was working fine until this 4.3 update. I have done the following per suggestions in this thread: -Manually updated Windows client to 4.3 64-bit version (prior 4.2 version was also not connecting) -Copied .ui.info from the Crashplan docker ID directory to the Crashplan directory on the Windows desktop -Changed the Crashplan\conf\ui.properties as follows (yes, I uncommented the lines): serviceHost=192.168.1.10 (My unRAID IP) servicePort=4200 -Edited my.service.xml in Crashplan docker to set <serviceHost> field to 0.0.0.0 (It was 127.0.0.1) I did this one at time and tried to connect after each step. Connection to engine still fails. Any ideas? What is the best way to verify that the Crashplan docker engine is also at version 4.3? I did run a check for updates a couple of times from the Docker tab and it reports up-to-date on all dockers including Crashplan. EDIT: Found in the app.log in the Crashplan Log directory that it says the engine version is 4.3. So, I now have a 4.3 client that cannot connect to the 4.3 backup engine.

I am running unRAID v6.01 and the latest version of unMENU works with it just fine. I rarely use anything in unMENU anymore since the new Web GUI is so complete; however, like many I have it installed for emergency situations which, fortunately for me, have not yet occurred in unRAID 6. I used to see frequent web GUI hangs in unRAID 5, but, since moving over to v6 beginning with beta10, I have experienced a GUI hang just once. I have no idea what is causing yours to hang, but, there are several mentions in these forums of the Unassigned Devices plugin being a suspect. Are you running that?