Leifgg

Unfortunately, I am not using a Mac so it’s a bit difficult for me to help. Using Microsoft RDP and mRemoteNG in Windows and have never seen this behaviour. I believe that this container is using the Libre-Mate container by sparklyballs as a base so it might be worth looking at or posting in that thread as well. The problem is not CrashPlan related, it probably has to do with the Linux desktop and/or Linux xrdp used in that Container. Hope that somebody with a Mac can respond!

Are you using a Browser with Remote Desktop extension? Only thing I could think of is an AdBlocker causing the problem.

CrashPlan 4.5.2 will still works with the current CrashPlan Desktop container. Keep the CrashPlan container running but make sure to wait a while before starting the CrashPlan Desktop container.

I did not understand I had to install CrashPlan also. Thanks man Problem solved! (well at least the first one… )

Have you installed the CrashPlan container also?

I doubt it since it's not the "headless" setup most of people here use. If it was the case, the whole concept of backing up to other computers wouldn't make sense. But who knows. Maybe I should look into a different solution altogether, like SyncBackSE. Wasn’t thinking that you should make any changes like the ones needed for the headless configuration. More like that the Windows client used these files to identity the remote system. Try to have a look on the config files on the Windows client if you find anything related to the backup destination at your unRAID server.

You should have --volumes-from CrashPlan in the Extra Parameters for the CrashPlan Desktop container. Check the guide in my signature.

I wonder if this can be related to the .identity and the .ui_info files on your unRAID server. As soon as you restart unRAID these two files get updated with new keys. If the Windows client is using them to identify unRAID as a backup destination for your Windows backup that could be a possible reason for not connecting. Unfortunately, I am not using same setup as you so I can’t test this so the above is just a guess.

Your screen shots look ok so that should work but every time you reboot unRAID it takes a while before the CrashPlan Desktop container can connect to the CrashPlan container as mentioned in post #591 above. You only need to use the CrashPlan Desktop container to configure your backups and for monitoring so only start it when you need it but set the CrashPlan container to autostart. It will run and do its job regardless of CrashPlan Desktop container is started or not. If you intend to do backups from a Windows client to unRAID (and later to the CrashPlan cloud) I would recommend to use a Windows client like SyncBackSE for that purpose.

Check this post from the support pages at CrashPlan: http://support.code42.com/CrashPlan/4/Backup/Backing_Up_A_Windows_Network_Drive

The CrashPlan Desktop Docker still works after the auto update of the CrashPlan Docker to version 4.5.2 During the actual update I was not able to connect with the CrashPlan Desktop Docker until the update was completed. It did take 15 minutes on my system. Check your latest history.log 01/14/16 09:01PM Downloading a new version of CrashPlan. 01/14/16 09:15PM Download of upgrade complete - version 1435726800452. 01/14/16 09:15PM Installing upgrade - version 1435726800452 01/14/16 09:15PM Upgrade installed - version 1435726800452 01/14/16 09:15PM CrashPlan stopped, version 4.5.0, GUID xxxxxxxxxxxxxxxxxxxx 01/14/16 09:15PM CrashPlan started, version 4.5.2, GUID xxxxxxxxxxxxxxxxxxxx 01/14/16 09:15PM Backup scheduled to always run Release Notes: http://support.code42.com/Release_Notes/CrashPlan_For_Home/4.5.0

Plex has currently turned off the update notifications for the Plex pass version. As soon they turn it on again for new releases you will see the notification in the PMS GUI.

Haven’t really any good suggestions however the CrashPlan Docker is on version 4.4.1 but gets updated to 4.5.0 as soon as you start the CrashPlan Docker and connects to CrashPlan. The CrashPlan Desktop Docker is still on version 4.4.1 (it doesn’t update itself) and should work with CrashPlan Docker 4.5.0 The reason to wait before starting the CrashPlan Desktop Docker is that every time you restart the CrashPlan Docker you will get a new unique key so the idea is that CrashPlan Desktop Docker shouldn’t be started until the new key is received from CrashPlan. You should be able to see some info in the latest history.log on what’s going on.

The CrashPlan Desktop container is only needed to do the setup and for monitoring so you can turn it off when you don’t need it.

According to several statements made by CrashPlan there is no bandwidth limits in their backup service and there isn’t anything within the CrashPlan Docker that should cause this either. However, there are several factors that can influence the backup speed. Firstly, all data is compressed and encrypted. CrashPlan also uses data deduplication to reduce the amount of data that is transferred. The data deduplication compares all data blocks in your backup with all data you already backed up to CrashPlan and only backups new data blocks. Compression and encryption doesn’t use much resources but data deduplication can actually use a lot of CPU and can be a limiting factor on a low powered system. Some data, like media files, usually only contains unique data blocks so data deduplication and compression doesn’t really reduce the amount of data to be backed up. Since data deduplication compares all data with previously backed up data this process takes longer time the more data that you already backed up. There are also other users backing up data to the same CrashPlan server at the same time so there are limitations depending on the resource usage for that server as well as general limitations depending on bandwidth usage. Your geographical location as well as the location of the actual data centre you are connected to could also influence this. I can see large differences in the backup speed but in general it’s a bit less than 10 Mbit but on rare occasions I have reached around 80 Mbit making me believe that CrashPlan doesn’t limit bandwidth usage on purpose and limitations are depending on other factors.

Which one do you like better SyncBackSE or GoodSync? I like SyncBackSE mainly because I used it for a long time and I can use the free version…

I am using SyncBackSE (free version) to backup Windows clients to unRAID. GoodSync is another Windows client that you should have a look at. Also have a look on the Syncthing Docker Container in combination with the Syncthing Windows client.

Suggest stopping both containers and then start the CrashPlan container and wait a few minutes and then start the CrashPlan Desktop container. That usually fixes this problem. I have same versions as you and that works fine.

Since you have linked back to this post from a few other threads, you should provide a link to the source of your information in this post. Link added to original post.

After reading a bit on the Plex forum I understand that Plex Media Server (from 0.9.14.x) now checks available space on the location where transcoding is done before it starts transcoding. It looks like that minimum required space is the size of the largest movie file plus 100 MB. If I have understood this correctly, it would probably mean that transcoding needs to be set to the cache drive (unless you only have small files or a huge amount of memory). When using “Optimized Versions” (making transcoded versions of media for different devices) the transcoding is already done to the cache drive since the location used is /Library/Application Support/Plex Media Server/Cache/Transcode/Sync/ Edit: There are several posts about this on the Plex forum but here is one of them: http://forums.plex.tv/discussion/198012/pms-0-9-14-4-ignoring-transcoder-temporary-directory-setting#latest Edit: Looks like the free space needed for transcoding now has changed to be the size of the actual movie plus 200 MB.

I have done this procedure and it’s a bit scary… First go to CrashPlan support pages and look for adopting another computer: https://support.code42.com/CrashPlan/4/Configuring/Replacing_Your_Device Read this very carefully! CrashPlan will notice that your data now is at a new location and will need to scan all your files and compare them with what they have on their server. This will take time, for me a several days with 6 TB of data. Make sure to map your backup so that all previous shares/folders are included in the backup.

Suggest you stop both containers. Then start the CrashPlan container and wait a few minutes and then start the CrashPlan Desktop container. If you check the latest history.log you will probably find that it actually has updated the CrashPlan container to 4.5.0 The CrashPlan Desktop container doesn’t update itself but should work with this version.

The CrashPlan Docker container is primarily intended to backup files on your unRAID server to the CrashPlan cloud. It can also backup between folders and to/from external drives and other servers using the plugin Unasigned Devices. The CrashPlan Desktop Docker container is used to configure the backups and to monitoring them. Docker containers requires unRAID 6. If you are backing up your unRAID server today using CrashPlan on Windows, you can adopt CrashPlan to use your new configuration meaning that you keep your current backup so you don’t need to start all over again. If you have used Docker containers before its relatively easy to setup, in not it will take some effort to understand the concept. There is a guide in my signature that might be useful to have a look at.

Plex has been updated and should work. Latest PlexPass version is 0.9.14.4. Regarding transcoding to RAM I haven’t enough experience to give any advice since I mostly can use Direct play.

The easiest way to use CrashPlan is by using the CrashPlan Docker container and the CrashPlan Desktop Docker container. When I tested this two days ago it was still working after the update to version 4.5.0 but after checking this one more time today it doesn’t. Basically it worked as long as I didn’t restart the CrashPlan Desktop Docker container but after I did that that, the CrashPlan Desktop Docker doesn’t start. I believe that the update did brake the CrashPlan Desktop Docker container and that the maintainer of these containers need to look into this and hopefully make an update to the latest release. Edit: Some more testing done, after restarting the CrashPlan Desktop Docker container a few times its up and running again and everything looks ok.